[Geoserver-users] Questions about app-schema extension

GeoServer GeoServer User
1

Hi Geoserver users/developers,

I’m actually testing the app-schema extension (nightlybuild from :04/08/09) ,
and I have two questions about its behavior:

  1. I have in my Xsd application schema some feature’s properties that
    are required. They are defined in my xsd with the minoccur=1 and
    maxoccur=1 attributes. But, if I forget in the app-schema Mapping File
    one of these properties, I can still display data without any warning or
    error message (my output GML is not compliant anymore with its xsd). I
    don’t know if this behavior is wished ?

  2. When I read the file “AppSchemaDataAccess.xsd”, the element
    is set as unbounded, I don’t understand why.
    Because after several tests, it seems to me that Geoserver expects one
    Mapping File for each Feature Type (and, thus, one Store for each
    Feature Type) thus preventing me from having two
    elements under the element.

Regards, Dorian.

2

Dorian GINANE wrote:

Hi Geoserver users/developers,
I'm actually testing the app-schema extension (nightlybuild from :04/08/09) ,
and I have two questions about its behavior:
1) I have in my Xsd application schema some feature's properties that
are required. They are defined in my xsd with the minoccur=1 and
maxoccur=1 attributes. But, if I forget in the app-schema Mapping File
one of these properties, I can still display data without any warning or
error message (my output GML is not compliant anymore with its xsd). I
don't know if this behavior is wished ?

At this time GeoServer app-schema is rather forgiving about what it will encode. It will not complain if you leave out required properties. It will also happily encode ClientProperty (XML attributes) that are not in the target schema.

In the future, we plan to have a graphical user interface that will guide configuration and advise users when required properties are omitted. This should reduce the risk of producing schema-invalid XML.

While forgiving behaviour is useful while building a mapping, optional validation would improve interoperability, and may also be added.

2) When I read the file "AppSchemaDataAccess.xsd", the element
<FeatureTypeMapping> is set as unbounded, I don't understand why.
Because after several tests, it seems to me that Geoserver expects one
Mapping File for each Feature Type (and, thus, one Store for each
Feature Type) thus preventing me from having two <FeatureTypeMapping>
elements under the <typeMappings> element.

You can have multiple <FeatureTypeMapping> elements. If these are used internally (e.g. for feature chaining), you need do nothing more. If you wish these types to be published via top-level WFS requests, you probably need to add a subdirectory containing a featuretype.xml to provide the metadata so the internal GeoServer catalog recognises the types (I have not tried this but it should work). This is likely what is stopping them from working in your configuration. They will also need to be in the same namespace (the GeoServer workspace name limitation).

There are examples of multiple <FeatureTypeMapping> elements in the PIRSA EarthResource configuration:
https://twiki.auscope.org/twiki/bin/view/Grid/PirsaEarthResourceGeoserver#Implementation_notes

For example, the mapping file for er:MineralOccurrence also contains mappings for er:MineralDepositModel and er:EarthResourceMaterial, which are nested in er:MineralOccurrence through feature chaining (but not published as top-level types):
https://svn.auscope.org/subversion/AuScope/geoserver/config/geoserver-pirsa-earthresource-config/trunk/workspaces/er/er_MineralOccurrence/er_MineralOccurrence.xml

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia