= ZOO Configuration File Reference =

The ZOO Service configuration file (.zcfg) describes the service and will be parsed by ZOO Kernel to know how to handle it. You can use the generic example bellow to compose your own .zcfg files, and take a look at working examples on the ZOO-Project SVN source tree.

A ZOO Configuration file is divided in three distinct sections :

   * Main metadata informations
   * List of Inputs metadata informations
   * List of Outputs metadata informations

'''The ZOO Configuration File is case sensitive.'''

== Main metadata informations ==

The fist part in a ZOO Configuration contains the metadata informations relatives to the service. Note that the "name of your service", between bracket on the first line, have to be the exact same name as the function you defined in you service code.

You can see bellow a description of the main metadata informations:
{{{
#!Lineno
[Name of your service]
Title = Title of your service
Abstract = Description of your service
processVersion = Version number of your service
storeSupported = true/false
statusSupported = true/false
serviceType = the programming language used to implement the service (C/Fortran/Python/Java/PHP/Javascript)
serviceProvider = name of your services provider (shared library/Python Module/Java Class/PHP Script/JavaScript script)
<MetaData>
  title = Metadata title of your service
</MetaData>
}}}

== List of Inputs ==

The list of inputs contains metadata information of each defined input and it is a {{{<DataInputs>}}} node.

A typical list of inputs ({{{<DataInputs>}}}) look like the following:
{{{
#!Lineno
<DataInputs>
  [Name of the first input]
    Title = Title of the first input
    Abstract = Abstract describing the first input
    minOccurs = Minimum occurence of the first input
    maxOccurs = Maximum occurence of the first input
    <Type Of Data Node />
  [Name of the second input]
    Title = Title of the second input
    Abstract = Abstract describing the second input
    minOccurs = Minimum occurence of the second input
    maxOccurs = Maximum occurence of the second input
    <Type Of Data Node />
</DataInputs>
}}}

Note that you can add {{{<MetaData>}}} node as in the main metadata information.

== List of Outputs ==

The list of outputs is similar to a list of inputs except it is designed as a {{{<DataOutputs>}}} node.

A typical {{{<DataOutputs>}}} node look like the following:
{{{
#!Lineno
<DataOutputs>
  [Name of the output]
    Title = Title of the output
    Abstract = Description of the output
    <Type Of Data Node />
</DataOutputs>
}}}

== Type Of Data Nodes ==

From the begining we spoke about Type Of Data Nodes to describe data type of inputs and outputs.

You can define your data as:
  * [#LiteralDatanode LiteralData] 
  * [#BoundingBoxDatanode BoundingBoxData]
  * [#ComplexDatanode ComplexData]

Each Type Of Data node have at least one {{{<Default>}}} and one {{{<Supported>}}} node. Even if one of those are empty it has to be present as an opening and closing tag.

=== !LiteralData node ===

A {{{<LiteralData>}}} node get one {{{<Default>}}}, one or more {{{<Supported>}}} node depending on the number of Unity Of Mesures (UOM) and a {{{dataType}}} property. The {{{dataType}}} property define the type of literal data, a string, an interger and so on ([http://www.w3.org/TR/xmlschema-2/#built-in-datatypes complete list] of supported data types).

For input {{{<LiteralData>}}} nodes, you can add value to the {{{<Default>}}} properties to define a default value for this input. This means that when your Service will be run even if the input wasn't defined, this default value will be set as the current value for this input.

A typical {{{<LiteralData>}}} node look like the following:
{{{
#!Lineno
<LiteralData>
  dataType = float
  <Default>
    uom = meters
  </Default>
  <Supported>
    uom = feet
  </Supported>
</LiteralData>
}}}

=== !BoundingBoxData node ===

A {{{<BoundingBoxData>}}} node contains one {{{<Defautl>}}} node getting a CRS property defining the default Coordinate Reference Systems (CRS) and one or more {{{<Supported>}}} nodes depending on the number of CRS your service support (note that you can also use a list of supported CRS separated them by coma in only one {{{<Supported>}}} node).

A tipical {{{<BoundingBoxData>}}} node, for two supported CRM ([http://www.epsg-registry.org/indicio/query?request=GetRepositoryItem&id=urn:ogc:def:crs:EPSG::4326 EPSG:4326] and [http://www.epsg-registry.org/indicio/query?request=GetRepositoryItem&id=urn:ogc:def:crs:EPSG::3785 EPSG:3785] ), look like the following:

{{{
#!Lineno
<BoundingBoxData>
  <Default>
    CRS = urn:ogc:def:crs:EPSG:6.6:4326
  </Default>
  <Supported>
    CRS = urn:ogc:def:crs:EPSG:6.6:4326
  </Supported>
  <Supported>
    CRS = urn:ogc:def:crs:EPSG:6.6:3785
  </Supported>
</BoundingBoxData>
}}}

=== !ComplexData node ===

A ComplexData node get a {{{<Default>}}} and one or more {{{<Supported>}}} nodes depending on the number of supported format. A format is this set of properties : {{{mimeType}}}, {{{encoding}}} and optionaly {{{schema}}}.

For output ComplexData nodes, you can add the {{{extension}}} property to define what extension to use to name the file when storing the result is required. Obviously, you'll have to add the extension to each supported format. You can also add the {{{asReference}}} property for each input to define if the output should be stored on server side per default. Note, that the client can always modify this behavior setting {{{asReference}}} attribute to {{{true}}} or {{{false}}} for this output in the {{{ResponseDocument}}}.

You can see above a sample ComplexData node for default {{{application/json}}} and {{{text/xml}}} mimeTypes support:
{{{
#!Lineno
<ComplexData>
  <Default>
    mimeType = application/json
    encoding = UTF-8
  </Default>
  <Supported>
    mimeType = text/xml
    encoding = base64
    schema = http://fooa/gml/3.1.0/polygon.xsd
  </Supported>
  <Supported>
    mimeType = text/xml
    encoding = UTF-8
    schema = http://fooa/gml/3.1.0/polygon.xsd
  </Supported>
</ComplexData>
}}}