--- a/Symbian3/SDK/Source/GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita Fri Jun 11 12:39:03 2010 +0100
@@ -1,166 +1,166 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License
-"Eclipse Public License v1.0" which accompanies this distribution,
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
- Nokia Corporation - initial contribution.
-Contributors:
--->
-<!DOCTYPE concept
- PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C" xml:lang="en"><title>The
-ScreenPlay Graphics Architecture</title><shortdesc>This topic provides an introduction to ScreenPlay and its architecture.
-ScreenPlay is a new graphics architecture, introduced in Symbian^3 (S^3).
-ScreenPlay enables device creators to take advantage of improved software
-performance, hardware acceleration and third party graphics engines. ScreenPlay
-is sometimes known as the <b>New Graphics Architecture (NGA)</b>. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>ScreenPlay is a response to new requirements and developments in device
-hardware models. For example, ScreenPlay can support graphics accelerators
-and graphics processing units (GPUs) and non-uniform memory models as well
-as uniform memory models. A non-uniform memory model is an architecture in
-which a GPU has a completely different processing area from the CPU such that
-the GPU memory is not available to the CPU and vice versa. ScreenPlay can
-handle non-uniform memory models without the need to copy buffers between
-the different processing areas. </p>
-<section id="GUID-D4071308-2FA1-4B04-9AC2-926E1D619D08"><title>Key features</title><ul>
-<li id="GUID-0325A4C9-BAA3-5FA3-8389-BB406C020F36"><p>Asynchronous hardware-accelerated
-rendering and composition on devices on which dedicated graphics acceleration
-hardware is available. This is achieved through a Hardware Adaptation Layer
-(HAL). </p> </li>
-<li id="GUID-7CE7127E-873E-5284-A8DE-B2FF058E1107"><p>The ability to composit
-a semi-transparent UI buffer over highly dynamic content, such as OpenGL ES
-games, video and the camera viewfinder. </p> </li>
-<li id="GUID-3DAD6DFE-D2BE-5B7C-9253-38B7B30738D5"><p>The separation of control
-and data flow. This has advantages when running on non-uniform memory architectures
-and means that video decoding, UI rendering, and so on can take place and
-remain in the GPU memory domain. </p> </li>
-<li id="GUID-451CAB9D-DBB9-57FE-85C2-A8DE8C9D9436"><p>A foundation for secure
-screen content and Digital Rights Management (DRM). Applications no longer
-have direct access to the screen. Read and write access to the screen is controlled
-by the Window Server. </p> </li>
-<li id="GUID-060D7439-04FC-506A-B1B1-802C97F8931C"><p>Direct Screen Access
-(DSA) is supported in order to provide backwards compatibility. However, because
-in ScreenPlay the screen is no longer controlled by the Screen Driver, the
-DSA frame buffer is just another buffer that can be allocated dynamically
-on demand. ScreenPlay provides alternatives to DSA. </p> </li>
-</ul></section>
-<section id="GUID-D8BB0841-1E27-45A0-99AF-0F0A2D0A7362"><title>Architecture</title> <p>The
-following diagram shows the key components in the Symbian Foundation Graphics
-package and some closely related components in other packages. </p> <fig id="GUID-3300E986-4B93-5122-88C4-D7CC231F3BA3">
-<title> Symbian^3 component architecture </title>
-<image href="GUID-DD22D66C-C303-5432-9C24-71F26190FCA0_d0e191110_href.png" placement="inline"/>
-</fig> <p>The key ScreenPlay components are introduced below under separate
-subheadings. </p> </section>
-<section id="GUID-AB1E3E20-01A9-4090-A404-0D1FF978AF53"><title>Graphics Composition </title><p>The
-composition engine composes content, possibly from several different sources,
-before it is displayed on the screen. Composition involves the important concepts
-of scene elements (or layers) and surfaces. Scene elements describe the geometric
-position, size and orientation of items to be displayed on the screen; whereas
-surfaces are pixel buffers for holding an image or part of a scene. </p> <p>The
-composition engine maintains the stack of scene elements and computes what
-is visible. For example, it culls invisible areas and maintains a list of
-dirty rectangles. It blends the pixels if necessary and can perform limited
-transformations, such as scaling and rotation (in 90° increments). The composition
-engine is an <b>adaptation component</b>, which means that device creators
-can adapt or replace it to suit the exact hardware on the device. The composition
-engine can utilize GPU hardware composition and LCD hardware rotation if they
-are available. </p> <p>The composition components are specific to ScreenPlay.
-For more information, see <xref href="GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita">Graphics
-Composition</xref>. </p></section>
-<section id="GUID-04973DCA-9DCA-40E8-AC4D-5FB244F23293"><title>Surface Manager
-and Surface Update Server</title><p>The Surface Manager component creates
-and manages graphics composition surfaces. The Surface Manager reference implementation
-implements surfaces as shared chunks because they must be accessible by user-side
-processes and the kernel and composition hardware. Surfaces can be multi-buffered
-and are identified by a 128 bit identifier (called the surface ID). This gets
-resolved to an actual memory address by calling the Surface Manager Map Surface
-API. Surfaces can be used by other Symbian components such as the <xref href="GUID-DDE1A8A9-1D67-53BF-8A65-340F139AD4AB.dita">Multimedia
-Framework (MMF)</xref> and <xref href="GUID-FC735256-6CB5-5EED-8E7D-42EFA039E6FD.dita">ECam
-viewfinder</xref> and by applications such as OpenGL ES games. The Surface
-Manager is an adaptation component and so can be adapted or replaced to suit
-the hardware. </p><p>The Surface Update component provides a communication
-mechanism between the composition engine and clients. This is particularly
-useful for clients (such as video) that produce fast updates and use multi-buffered
-surfaces. </p></section>
-<section id="GUID-92C609E2-EF56-460E-B4BD-B935AB8ECFFB"><title>Window Server</title><p>The
-Window Server has been extended with a render stage framework, which enables
-the last stage of the Window Server rendering to be customizable through render
-stage plug-ins. This process, known as "deferred rendering" is achieved by
-intercepting the output of the Window Server and then deciding how that output
-should be rendered. For example, the output can be hardware accelerated or
-it can be sent to a third party graphics engine. The render stage framework
-enables device creators to integrate different UIs and runtime environments
-(such as Flash or Silverlight) and to achieve transition effects such as slide,
-zoom and fade. </p><p>Symbian provides more than one render stage solution.
-The following diagram provides a simplified representation of one possible
-solution (called <i>solution A</i> in this topic). This solution is full featured.
-The diagram focuses on the more relevant components and does not attempt to
-show all components in the complete solution. This solution has a dependency
-on the S60 middleware layer, in particular on the Hitchcock component (which
-is in the UI Accelerator package). </p><fig id="GUID-0D91F9A6-68FC-5316-A16D-A3238F8452AD">
-<title> Render stage solution A </title>
-<image href="GUID-643AFF2D-3EDB-5FAB-9631-7B93FABC56B6_d0e191164_href.png" placement="inline"/>
-</fig><p>Another possible solution (called <i>solution B</i>) is based on
-the DirectGDI and Graphics Resource components (which are described next),
-both of which have interface and adaptation layers. This solution is not full
-featured. Like the previous diagram, this diagram focuses on the more relevant
-components and does not attempt to show everything. </p><fig id="GUID-6A761DC5-1141-5515-BD03-09FBFE56F2D7">
-<title>Render stage solution B</title>
-<image href="GUID-3DD37A41-E822-5CB6-A59E-0B309B5627D9_d0e191176_href.png" placement="inline"/>
-</fig><p>Both of these render stage solutions mean that existing Window Server
-applications can take advantage of hardware acceleration if it is available
-(and therefore run faster) without recompiling the code. </p><p>ScreenPlay
-provides extensions to the Window Server client-side API, which enable mobile
-devices to respond to events from a number of pointers, including their proximity
-and pressure. This feature is known as <xref href="GUID-A12A66ED-2C8F-5CE6-8F3E-332B045A35B4.dita">advanced
-pointers</xref>. </p><p>A new API, <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita#GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9/GUID-B431DC60-D11F-3239-8F52-4257B9B0E0C9"><apiname>RWsSession::Finish()</apiname></xref>,
-has been added to allow Window Server client applications to synchronize with
-the completion of Window Server rendering. The existing API, <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita#GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9/GUID-B83C6F44-1A3E-3959-910C-CBBF66C4A3D4"><apiname>RWsSession::Flush()</apiname></xref>,
-is redefined to simply flush the client-side command buffer, whereas previously
-it also provided a guarantee that Window Server had completed the command
-buffer’s operations. This behavioral change allows legacy clients to benefit
-from the asynchronous hardware rendering when supported by the render stage
-plug-in(s) that are in use. </p><p>For more information, see <xref href="GUID-57A777A3-5D67-5CBB-B224-B7AD422A451B.dita">Windowing
-Collection</xref>. </p></section>
-<section id="GUID-D67558F6-7841-487F-8F73-7580C2EFC026"><title>DirectGDI</title><p>DirectGDI
-provides a graphics context that can be hardware accelerated and allows an
-asynchronous interface. DirectGDI has two parts: a generic layer, which provides
-a client API and an adaptation layer. Device creators can replace the adaptation
-layer with an implementation that takes advantage of graphics accelerated
-hardware, if it is available, or a software implementation, if it is not available. </p><p>DirectGDI
-was introduced as a prototype in the development of ScreenPlay. It is deprecated
-in Symbian^3.</p></section>
-<section id="GUID-DF3BDD08-1C11-4FC6-BA4C-30CC13BE6005"><title>Graphics Resource</title><p>The
-Graphics Resource component provides an abstraction layer for the memory management
-of pixel and non-pixel data (such as OpenVG command lists). Like DirectGDI,
-it has a generic part, which provides a client API and an adaptation part,
-which device creators can adapt to take advantage of graphics hardware when
-it is available. </p><p>The Graphics Resource component was introduced as
-a prototype in the development of ScreenPlay. It is deprecated in Symbian^3
-and will be removed in Symbian^4. However, a new Graphics Resource Interface
-component is planned for S^4. This new component will provide a similar but
-reduced API that is optimized for sharing images across processes.</p></section>
-<section id="GUID-35870066-DB83-477E-8532-002E1F91E9CF"><title>OpenVG, OpenGL
-ES and EGL</title><p>Symbian provides support for OpenVG, OpenGL ES and EGL.
-The main advantage of ScreenPlay with regard to EGL is that EGL can render
-into composition surfaces. For application developers this offers the ability
-to have semi-transparent GDI content on top of EGL content. The EGL client
-can query whether these new features are supported on the particular device. </p> <p>For
-more information, see <xref href="GUID-50254C2F-57B6-58C4-911F-294EF2B79C04.dita">Khronos
-API Support</xref>. </p></section>
-<section id="GUID-3B11D2F8-F3A4-4A2F-938A-B8EA0F64134A"><title>Screen Driver</title><p>In
-ScreenPlay, the implementation of the Screen Driver has been changed so that
-DSA content can be passed into the composition engine. </p></section>
-</conbody><related-links>
-<link href="GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita"><linktext>Graphics
-Composition</linktext></link>
-<link href="GUID-EF62BF88-3687-505D-8BD7-EEDF36246E56.dita"><linktext>Graphics
-Hardware Acceleration</linktext></link>
-<link href="GUID-99BC101A-9466-59EE-B5C9-7622BAF6E6FF.dita"><linktext>Graphics
-Concepts</linktext></link>
-
-
-
-
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C" xml:lang="en"><title>The
+ScreenPlay Graphics Architecture</title><shortdesc>This topic provides an introduction to ScreenPlay and its architecture.
+ScreenPlay is a new graphics architecture, introduced in Symbian^3 (S^3).
+ScreenPlay enables device creators to take advantage of improved software
+performance, hardware acceleration and third party graphics engines. ScreenPlay
+is sometimes known as the <b>New Graphics Architecture (NGA)</b>. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>ScreenPlay is a response to new requirements and developments in device
+hardware models. For example, ScreenPlay can support graphics accelerators
+and graphics processing units (GPUs) and non-uniform memory models as well
+as uniform memory models. A non-uniform memory model is an architecture in
+which a GPU has a completely different processing area from the CPU such that
+the GPU memory is not available to the CPU and vice versa. ScreenPlay can
+handle non-uniform memory models without the need to copy buffers between
+the different processing areas. </p>
+<section id="GUID-D4071308-2FA1-4B04-9AC2-926E1D619D08"><title>Key features</title><ul>
+<li id="GUID-0325A4C9-BAA3-5FA3-8389-BB406C020F36"><p>Asynchronous hardware-accelerated
+rendering and composition on devices on which dedicated graphics acceleration
+hardware is available. This is achieved through a Hardware Adaptation Layer
+(HAL). </p> </li>
+<li id="GUID-7CE7127E-873E-5284-A8DE-B2FF058E1107"><p>The ability to composit
+a semi-transparent UI buffer over highly dynamic content, such as OpenGL ES
+games, video and the camera viewfinder. </p> </li>
+<li id="GUID-3DAD6DFE-D2BE-5B7C-9253-38B7B30738D5"><p>The separation of control
+and data flow. This has advantages when running on non-uniform memory architectures
+and means that video decoding, UI rendering, and so on can take place and
+remain in the GPU memory domain. </p> </li>
+<li id="GUID-451CAB9D-DBB9-57FE-85C2-A8DE8C9D9436"><p>A foundation for secure
+screen content and Digital Rights Management (DRM). Applications no longer
+have direct access to the screen. Read and write access to the screen is controlled
+by the Window Server. </p> </li>
+<li id="GUID-060D7439-04FC-506A-B1B1-802C97F8931C"><p>Direct Screen Access
+(DSA) is supported in order to provide backwards compatibility. However, because
+in ScreenPlay the screen is no longer controlled by the Screen Driver, the
+DSA frame buffer is just another buffer that can be allocated dynamically
+on demand. ScreenPlay provides alternatives to DSA. </p> </li>
+</ul></section>
+<section id="GUID-D8BB0841-1E27-45A0-99AF-0F0A2D0A7362"><title>Architecture</title> <p>The
+following diagram shows the key components in the Symbian Foundation Graphics
+package and some closely related components in other packages. </p> <fig id="GUID-3300E986-4B93-5122-88C4-D7CC231F3BA3">
+<title> Symbian^3 component architecture </title>
+<image href="GUID-DD22D66C-C303-5432-9C24-71F26190FCA0_d0e184514_href.png" placement="inline"/>
+</fig> <p>The key ScreenPlay components are introduced below under separate
+subheadings. </p> </section>
+<section id="GUID-AB1E3E20-01A9-4090-A404-0D1FF978AF53"><title>Graphics Composition </title><p>The
+composition engine composes content, possibly from several different sources,
+before it is displayed on the screen. Composition involves the important concepts
+of scene elements (or layers) and surfaces. Scene elements describe the geometric
+position, size and orientation of items to be displayed on the screen; whereas
+surfaces are pixel buffers for holding an image or part of a scene. </p> <p>The
+composition engine maintains the stack of scene elements and computes what
+is visible. For example, it culls invisible areas and maintains a list of
+dirty rectangles. It blends the pixels if necessary and can perform limited
+transformations, such as scaling and rotation (in 90° increments). The composition
+engine is an <b>adaptation component</b>, which means that device creators
+can adapt or replace it to suit the exact hardware on the device. The composition
+engine can utilize GPU hardware composition and LCD hardware rotation if they
+are available. </p> <p>The composition components are specific to ScreenPlay.
+For more information, see <xref href="GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita">Graphics
+Composition</xref>. </p></section>
+<section id="GUID-04973DCA-9DCA-40E8-AC4D-5FB244F23293"><title>Surface Manager
+and Surface Update Server</title><p>The Surface Manager component creates
+and manages graphics composition surfaces. The Surface Manager reference implementation
+implements surfaces as shared chunks because they must be accessible by user-side
+processes and the kernel and composition hardware. Surfaces can be multi-buffered
+and are identified by a 128 bit identifier (called the surface ID). This gets
+resolved to an actual memory address by calling the Surface Manager Map Surface
+API. Surfaces can be used by other Symbian components such as the <xref href="GUID-DDE1A8A9-1D67-53BF-8A65-340F139AD4AB.dita">Multimedia
+Framework (MMF)</xref> and <xref href="GUID-FC735256-6CB5-5EED-8E7D-42EFA039E6FD.dita">ECam
+viewfinder</xref> and by applications such as OpenGL ES games. The Surface
+Manager is an adaptation component and so can be adapted or replaced to suit
+the hardware. </p><p>The Surface Update component provides a communication
+mechanism between the composition engine and clients. This is particularly
+useful for clients (such as video) that produce fast updates and use multi-buffered
+surfaces. </p></section>
+<section id="GUID-92C609E2-EF56-460E-B4BD-B935AB8ECFFB"><title>Window Server</title><p>The
+Window Server has been extended with a render stage framework, which enables
+the last stage of the Window Server rendering to be customizable through render
+stage plug-ins. This process, known as "deferred rendering" is achieved by
+intercepting the output of the Window Server and then deciding how that output
+should be rendered. For example, the output can be hardware accelerated or
+it can be sent to a third party graphics engine. The render stage framework
+enables device creators to integrate different UIs and runtime environments
+(such as Flash or Silverlight) and to achieve transition effects such as slide,
+zoom and fade. </p><p>Symbian provides more than one render stage solution.
+The following diagram provides a simplified representation of one possible
+solution (called <i>solution A</i> in this topic). This solution is full featured.
+The diagram focuses on the more relevant components and does not attempt to
+show all components in the complete solution. This solution has a dependency
+on the S60 middleware layer, in particular on the Hitchcock component (which
+is in the UI Accelerator package). </p><fig id="GUID-0D91F9A6-68FC-5316-A16D-A3238F8452AD">
+<title> Render stage solution A </title>
+<image href="GUID-643AFF2D-3EDB-5FAB-9631-7B93FABC56B6_d0e184568_href.png" placement="inline"/>
+</fig><p>Another possible solution (called <i>solution B</i>) is based on
+the DirectGDI and Graphics Resource components (which are described next),
+both of which have interface and adaptation layers. This solution is not full
+featured. Like the previous diagram, this diagram focuses on the more relevant
+components and does not attempt to show everything. </p><fig id="GUID-6A761DC5-1141-5515-BD03-09FBFE56F2D7">
+<title>Render stage solution B</title>
+<image href="GUID-3DD37A41-E822-5CB6-A59E-0B309B5627D9_d0e184580_href.png" placement="inline"/>
+</fig><p>Both of these render stage solutions mean that existing Window Server
+applications can take advantage of hardware acceleration if it is available
+(and therefore run faster) without recompiling the code. </p><p>ScreenPlay
+provides extensions to the Window Server client-side API, which enable mobile
+devices to respond to events from a number of pointers, including their proximity
+and pressure. This feature is known as <xref href="GUID-A12A66ED-2C8F-5CE6-8F3E-332B045A35B4.dita">advanced
+pointers</xref>. </p><p>A new API, <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita#GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9/GUID-B431DC60-D11F-3239-8F52-4257B9B0E0C9"><apiname>RWsSession::Finish()</apiname></xref>,
+has been added to allow Window Server client applications to synchronize with
+the completion of Window Server rendering. The existing API, <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita#GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9/GUID-B83C6F44-1A3E-3959-910C-CBBF66C4A3D4"><apiname>RWsSession::Flush()</apiname></xref>,
+is redefined to simply flush the client-side command buffer, whereas previously
+it also provided a guarantee that Window Server had completed the command
+buffer’s operations. This behavioral change allows legacy clients to benefit
+from the asynchronous hardware rendering when supported by the render stage
+plug-in(s) that are in use. </p><p>For more information, see <xref href="GUID-57A777A3-5D67-5CBB-B224-B7AD422A451B.dita">Windowing
+Collection</xref>. </p></section>
+<section id="GUID-D67558F6-7841-487F-8F73-7580C2EFC026"><title>DirectGDI</title><p>DirectGDI
+provides a graphics context that can be hardware accelerated and allows an
+asynchronous interface. DirectGDI has two parts: a generic layer, which provides
+a client API and an adaptation layer. Device creators can replace the adaptation
+layer with an implementation that takes advantage of graphics accelerated
+hardware, if it is available, or a software implementation, if it is not available. </p><p>DirectGDI
+was introduced as a prototype in the development of ScreenPlay. It is deprecated
+in Symbian^3.</p></section>
+<section id="GUID-DF3BDD08-1C11-4FC6-BA4C-30CC13BE6005"><title>Graphics Resource</title><p>The
+Graphics Resource component provides an abstraction layer for the memory management
+of pixel and non-pixel data (such as OpenVG command lists). Like DirectGDI,
+it has a generic part, which provides a client API and an adaptation part,
+which device creators can adapt to take advantage of graphics hardware when
+it is available. </p><p>The Graphics Resource component was introduced as
+a prototype in the development of ScreenPlay. It is deprecated in Symbian^3
+and will be removed in Symbian^4. However, a new Graphics Resource Interface
+component is planned for S^4. This new component will provide a similar but
+reduced API that is optimized for sharing images across processes.</p></section>
+<section id="GUID-35870066-DB83-477E-8532-002E1F91E9CF"><title>OpenVG, OpenGL
+ES and EGL</title><p>Symbian provides support for OpenVG, OpenGL ES and EGL.
+The main advantage of ScreenPlay with regard to EGL is that EGL can render
+into composition surfaces. For application developers this offers the ability
+to have semi-transparent GDI content on top of EGL content. The EGL client
+can query whether these new features are supported on the particular device. </p> <p>For
+more information, see <xref href="GUID-50254C2F-57B6-58C4-911F-294EF2B79C04.dita">Khronos
+API Support</xref>. </p></section>
+<section id="GUID-3B11D2F8-F3A4-4A2F-938A-B8EA0F64134A"><title>Screen Driver</title><p>In
+ScreenPlay, the implementation of the Screen Driver has been changed so that
+DSA content can be passed into the composition engine. </p></section>
+</conbody><related-links>
+<link href="GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita"><linktext>Graphics
+Composition</linktext></link>
+<link href="GUID-EF62BF88-3687-505D-8BD7-EEDF36246E56.dita"><linktext>Graphics
+Hardware Acceleration</linktext></link>
+<link href="GUID-99BC101A-9466-59EE-B5C9-7622BAF6E6FF.dita"><linktext>Graphics
+Concepts</linktext></link>
+
+
+
+
</related-links></concept>
\ No newline at end of file