By default the zoo kernel fills all optional literal data inputs with default values. Thats fine in case default literal values are provided.

But here is the issue: optional literal data inputs are also attached in case no default values are available.

This results in something like "distance=NULL", which will in case of gis grass modules, abort the processing with an error.

There may be two solutions:

1. The zoo kernel do not fill optional literal inputs when no default values are supported
2. The zoo kernel uses the language specific way (None in case of Python) to specify missing default literal input values and the GIS GRASS integration framework will take care of parameter with attached NULL/None values

Both solutions are ok in case of literal data for me. The second one has the advantage, that the input map structure are fully available with literal data for service modules. So no new memory must be allocated/modified in case the developer decides to modify literal data in the input map.

Optional complex data inputs should IMHO not be filled. GIS GRASS has many modules with optional complex data inputs.

Following the instructions on the page "Zoo Kernel" - "Installation" for the svn installation, configured with

./configure --with-python=/usr/ --without-php --without-java 

(and optionally --without-js for the version 1.0) I ended up with a binary that segfaults in the first line of cgiMain() (line no. 140) calling dup2. The two file handles are equal, even before the call to dup2.

Calling it as cgi results in a segfault as well, I assume for the same reason.

main.cfg does not currently allow to configure unicode strings

e.g.

addressCity=Hønefoss

is rendered as

<ows:City>H</ows:City>

despite the setting

encoding = utf-8