Index: trunk/docs/services/index.txt
===================================================================
--- trunk/docs/services/index.txt	(revision 600)
+++ trunk/docs/services/index.txt	(revision 607)
@@ -11,4 +11,5 @@
    introduction
    zcfg-reference
+   process-profiles
    howtos
    status
Index: trunk/docs/services/process-profiles.txt
===================================================================
--- trunk/docs/services/process-profiles.txt	(revision 607)
+++ trunk/docs/services/process-profiles.txt	(revision 607)
@@ -0,0 +1,188 @@
+.. _process-profiles:
+    
+Process Profiles Registry
+=========================================  
+
+:Authors: Nicolas Bozon, Gérald Fenoy, Jeff McKenna
+:Last Updated: $Date:$
+
+.. contents:: Table of Contents
+    :depth: 3
+    :backlinks: top
+
+Many times, services from the same ServicesProvider share inputs and
+outputs. In such a casse, defining the ZCFG files for each service
+from the same provider may lead to rewrite the same metadata
+informations in different files. 
+
+From `rev. 607 <http://www.zoo-project.org/trac/changeset/607>`__, the
+ZOO-Kernel is able to handle metadata inheritance, it create a
+Registry (before loading any other ZCFG files) containing a set of
+Process Profiles organized in levels depending on their position in
+the hierarchy:
+
+:Concept: the higher level in the hierarchy, concepts are basically
+   txt files containing an abstract description of a service,
+:Generic: a generic profile can make reference to concepts, it defines
+   inputs and outputs but nor the data format nor the maximum size
+   limitation,
+:Implementation: an implementation profile can inherit from a generic
+   profile and make reference to concepts, it contains all the
+   metadata informations about a service (see
+   `ref. <cfg-reference.html#main-metadata-information>`__).
+
+Both Generic Process Profiles and Process Implementation Profiles are
+created  from ZCFG files, stored in the registry sub-directories
+depending on their level: ``concept``, ``generic`` and
+``implementation``.
+
+To activate the registry, you have to add a ``registry`` key to the
+``[main]`` section of your ``main.cfg`` file, and set its value to the
+directory path used to store the profile ZCFG files.
+
+
+Generic Process Profile
+-----------------------
+
+A Generic Process Profile is a ZCFG file located in the ``generic``
+sub-directory, it defines `main metadata information
+<zcfg-reference.html#main-metadata-information>`__, inputs and outputs
+name, basic metadata and multiplicity. It can make reference to a
+concept by defining a ``concept`` key in the `main metadata
+information <zcfg-reference.html#main-metadata-information>`__ part.
+
+You can find below the `GO.zcfg` file, a typical Generic Process
+Profile for Generic Geographic Operation, taking one InputPolygon
+input parameter and returning a result named Result, it make reference
+to the ``GOC`` concept:
+
+.. code-block:: none
+   :linenos:
+   
+   [GO]
+    Title = Geographic Operation
+    Abstract = Geographic Operation on exactly one input, returning one output
+    concept = GOC
+    level = generic
+    statusSupported = true
+    storeSupported = true
+    <DataInputs>
+     [InputPolygon]
+      Title = the geographic data
+      Abstract = the geographic data to run geographipc operation
+      minOccurs = 1
+      maxOccurs = 1
+    </DataInputs>
+    <DataOutputs>
+     [Result]
+      Title = the resulting data
+      Abstract = the resulting data after processing the operation
+    </DataOutputs>  
+
+
+.. Note:: if you need to reference more than one concept, you should
+    separate their names with a comma (ie. concept = GO,GB),
+
+Process Implementation Profile
+------------------------------
+
+A Process Implementation Profile is similar to a `ZCFG file
+<zcfg-reference.html>`__ located in the `implementation`
+sub-directory, it defines (or inherit from its parent) all the
+properties of a `Generic Process Profile <#generic-process-profile>`__
+and specify `Data Format <zcfg-reference.html#type-of-data-nodes>`__
+for both inputs and outputs. It can make reference to a concept by
+defining a ``concept`` key in the `main metadata information
+<zcfg-reference.html#main-metadata-information>`__ part.
+
+You can find below the `VectorOperation.zcfg` file, a typical Process
+Implementation Profile for Vector Geographic Operation, it inherit
+from the `GP generic profile <#generic-process-profile>`__:
+
+.. code-block:: none
+   :linenos:
+   
+   [VectorOperation]
+    Title = Vector Geographic Operation
+    Abstract = Apply a Vector Geographic Operation on a features collection and return the resulting features collection
+    extend = GO
+    level = profile
+    <DataInputs>
+     [InputPolygon]
+      Title = the vector data
+      Abstract = the vector data to run geographic operation
+      <ComplexData>
+       <Default>
+        mimeType = text/xml
+        encoding = UTF-8
+        schema = http://fooa/gml/3.1.0/polygon.xsd
+       </Default>
+       <Supported>
+        mimeType = application/json
+        encoding = UTF-8
+        extension = js
+       </Supported>
+    </DataInputs>
+    <DataOutputs>
+     [Result]
+      Title = the resulting data
+      Abstract = the resulting geographic data after processing the operation
+      <ComplexData>
+       <Default>
+        mimeType = text/xml
+        encoding = UTF-8
+        schema = http://fooa/gml/3.1.0/polygon.xsd
+       </Default>
+       <Supported>
+        mimeType = application/json
+        encoding = UTF-8
+        extension = js
+       </Supported>
+      </ComplexData>
+    </DataOutputs>  
+
+
+ZCFG inheritance
+----------------------------------
+
+For the ZCFG files at the service level, you can inherit the metadata
+from a profile available in the registry. As before, you simply need
+to add a ``extend`` key refering the ZCFG you want to inherit from
+and a ``level`` key taking the `ìmplementation`` value to your main
+metadata informations.
+
+So, for example, the original `ConvexHull.zcfg
+<http://www.zoo-project.org/trac/browser/trunk/zoo-project/zoo-services/ogr/base-vect-ops/cgi-env/ConvexHull.zcfg?rev=491>`__
+may be rewritten as:
+
+.. code-block:: none
+   :linenos:
+   
+   [ConvexHull]
+    Title = Compute convex hull.
+    Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection.
+    serviceProvider = ogr_service.zo
+    serviceType = C
+    extend = VectorOperation
+    level = implementation
+
+Now, suppose that your service is able to return the result in KML
+format, then you may write the following:
+
+.. code-block:: none
+   :linenos:
+   
+   [ConvexHull]
+    Title = Compute convex hull.
+    Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection.
+    serviceProvider = ogr_service.zo
+    serviceType = C
+    extend = VectorOperation
+    level = implementation
+    <DataOutputs>
+     [Result]
+        <Supported>
+         mimeType = application/vnd.google-earth.kml+xml
+         encoding = utf-8
+        </Supported>
+    </DataOutputs>
Index: trunk/docs/services/zcfg-reference.txt
===================================================================
--- trunk/docs/services/zcfg-reference.txt	(revision 600)
+++ trunk/docs/services/zcfg-reference.txt	(revision 607)
@@ -48,4 +48,7 @@
      title = Metadata title of your service
    </MetaData>
+
+.. Note:: you may add an ``extend`` key in case you use the `Process
+   Profile Registry <process-profiles.html>`__.
 
 List of Inputs
