ZooWebSite/ZooServices/ZCFGReference

ZCFG : the ZOO Service Configuration File

The ZOO Service configuration file (.zcfg) describes the service and will be parsed by the ZOO Kernel to know how to handle it. We will describe here what such a file contains. You can also take a look at the existing examples of ZCFG file in the cgi-env directory of each services available 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 Service 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 your services provider code. In most case, this name is also the name of the ZCFG file without the ".zcfg" extension.

You can see bellow a description of the main metadata informations:

Line 
1[Name of your service]
2Title = Title of your service
3Abstract = Description of your service
4processVersion = Version number of your service
5storeSupported = true/false
6statusSupported = true/false
7serviceType = the programming language used to implement the service (C/Fortran/Python/Java/PHP/Javascript)
8serviceProvider = name of your services provider (shared library/Python Module/Java Class/PHP Script/JavaScript script)
9<MetaData>
10  title = Metadata title of your service
11</MetaData>

List of Inputs

The list of inputs contains metadata information of each supported input and they are grouped using a <DataInputs> node.

Each input is defined as :

  • a name (between brackets as for the name of the service before)
  • various medata properties (Title, Abstract, minOccurs and maxOccurs)
  • a Type Of Data node (description)

A typical list of inputs (<DataInputs>) look like the following:

Line 
1<DataInputs>
2  [Name of the first input]
3    Title = Title of the first input
4    Abstract = Abstract describing the first input
5    minOccurs = Minimum occurence of the first input
6    maxOccurs = Maximum occurence of the first input
7    <Type Of Data Node />
8  [Name of the second input]
9    Title = Title of the second input
10    Abstract = Abstract describing the second input
11    minOccurs = Minimum occurence of the second input
12    maxOccurs = Maximum occurence of the second input
13    <Type Of Data Node />
14</DataInputs>

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

List of Outputs

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

A typical <DataOutputs> node look like the following:

Line 
1<DataOutputs>
2  [Name of the output]
3    Title = Title of the output
4    Abstract = Description of the output
5    <Type Of Data Node />
6</DataOutputs>

Type Of Data Nodes

From the begining of this ZCFG presentation, we spoke about "Type Of Data Nodes" to describe data type of inputs and outputs.

You can define your data as:

Except for LiteralData, 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 on two different line. So, something like the following:

Line 
1<Default>
2</Default>

In other case, ZOO-Kernel won't be able to parse your ZCFG and will fail to process requests.

LiteralData node

A <LiteralData> node get one <Default>, zero or more <Supported> node depending on the existence or the number of supported Unity Of Mesures (UOM) and a dataType property. The dataType property define the type of literal data, a string, an interger and so on (consult  the complete list of supported data types). <Default> and <Supported> nodes can get the uom property to define which UOM have to be used for this input value.

For input <LiteralData> nodes, you can add the value property to the <Default> node 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, defining a float data type using meters or degree UOM, look like the following:

Line 
1<LiteralData>
2  dataType = float
3  <Default>
4    uom = meters
5  </Default>
6  <Supported>
7    uom = feet
8  </Supported>
9</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 ( EPSG:4326 and  EPSG:3785 ), look like the following:

Line 
1<BoundingBoxData>
2  <Default>
3    CRS = urn:ogc:def:crs:EPSG:6.6:4326
4  </Default>
5  <Supported>
6    CRS = urn:ogc:def:crs:EPSG:6.6:4326
7  </Supported>
8  <Supported>
9    CRS = urn:ogc:def:crs:EPSG:6.6:3785
10  </Supported>
11</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 property to each supported format ( <Default> and <Supported> nodes). You can also add the asReference property to the <Default> node to define if the output should be stored on server side per default. Note, that the client can always modify this behavior by setting asReference attribute to true or false for this output in the request ResponseDocument parameter.

You can see above a sample ComplexData node for default application/json and text/xml (encoded in UTF-8 or base64) mimeTypes support:

Line 
1<ComplexData>
2  <Default>
3    mimeType = application/json
4    encoding = UTF-8
5  </Default>
6  <Supported>
7    mimeType = text/xml
8    encoding = base64
9    schema = http://fooa/gml/3.1.0/polygon.xsd
10  </Supported>
11  <Supported>
12    mimeType = text/xml
13    encoding = UTF-8
14    schema = http://fooa/gml/3.1.0/polygon.xsd
15  </Supported>
16</ComplexData>

Search

Context Navigation

ZOO Sponsors

http://www.zoo-project.org/trac/chrome/site/img/geolabs-logo.pnghttp://www.zoo-project.org/trac/chrome/site/img/neogeo-logo.png http://www.zoo-project.org/trac/chrome/site/img/apptech-logo.png http://www.zoo-project.org/trac/chrome/site/img/3liz-logo.png http://www.zoo-project.org/trac/chrome/site/img/gateway-logo.png

Become a sponsor !

Knowledge partners

http://www.zoo-project.org/trac/chrome/site/img/ocu-logo.png http://www.zoo-project.org/trac/chrome/site/img/gucas-logo.png http://www.zoo-project.org/trac/chrome/site/img/polimi-logo.png http://www.zoo-project.org/trac/chrome/site/img/fem-logo.png http://www.zoo-project.org/trac/chrome/site/img/supsi-logo.png http://www.zoo-project.org/trac/chrome/site/img/cumtb-logo.png

Become a knowledge partner

Related links

http://zoo-project.org/img/ogclogo.png http://zoo-project.org/img/osgeologo.png