Question on gml:FeatureCollection schemaLocation
Just van den Broecke
This question originates from ESDIN who are now validating all INSPIRE
themes services for all member states. It deals with the value of the
schemaLocation location attribute. In a GetFeature response (e.g. for
CadastralParcel) the response starts like for example:
<gml:FeatureCollection
xsi:schemaLocation="http://www.opengis.net/gml/3.2
http://schemas.opengis.net/gml/3.2.1/deprecatedTypes.xsd
urn:x-inspire:specification:gmlas:CadastralParcels:3.0
http://localhost:8080/deegree3/console/../services?SERVICE=WFS&VERSION=1.1.0&REQUEST=DescribeFeatureType&OUTPUTFORMAT=text%2Fxml%3B+subtype%3Dgml%2F3.2.1&TYPENAME=cp:CadastralParcel&NAMESPACE=xmlns(cp=urn%3Ax-inspire%3Aspecification%3Agmlas%3ACadastralParcels%3A3.0)"
gml:id="WFS_RESPONSE">
(Yes includes the fix to get rid of file:/ schema location) while the
following should be sufficient for the schemaLocation attribute (and
validates with XMLSpy):
xsi:schemaLocation="urn:x-inspire:specification:gmlas:CadastralParcels:3.0
http://localhost:8080/deegree3/resources/schemas/inspire/annex1/CadastralParcels.xsd"
(And GML deprecatedTypes.xsd is already indirectly included in
CadastralParcels.xsd).
Any ideas ?
best,
Just
Markus Schneider
If I understand this correctly, this is only about cosmetics, right? Or is
there an actual validation issue here?
But of course you're right. The indirection via DescribeFeatureType is not
strictly necessary -- it just stems from the fact that DescribeFeatureType
is the usual way to access feature type definitions (as mandated by the
WFS spec). For simple feature types (e.g. backed by shape files), the
deegree WFS creates the needed GML application schema on-the-fly, for
application schemas such as INSPIRE it just writes a wrapper schema
on-the-fly.
Technically, it's convenient to have the DescribeFeatureType request deal
with schema delivery. I am a bit hesitant about changing anything here as
I don't see a real problem at the moment... however I am open to
suggestions / patches.
Note that if this is a strict necessity, it's always possible to plug-in
your own custom output format implementation without modifying any
existing code...
> (And GML deprecatedTypes.xsd is already indirectly included in
> CadastralParcels.xsd).
I agree. There's already an implicit reference to
"http://schemas.opengis.net/gml/3.2.1/deprecatedTypes.xsd" via the INSPIRE
schemas. It should be possible to get rid of the explicit reference by
simply tweaking the GML output format configuration in wfs.xml. However,
there's an actual reason why I configured it to be included. Some XML
validators (Eclipse) won't validate the response correctly if there's no
explicit reference to the schema for the namespace of the root element...
Best regards,
Markus
Markus Schneider
> I agree. There's already an implicit reference to
> "http://schemas.opengis.net/gml/3.2.1/deprecatedTypes.xsd" via the INSPIRE
> schemas. It should be possible to get rid of the explicit reference by
> simply tweaking the GML output format configuration in wfs.xml. However,
> there's an actual reason why I configured it to be included. Some XML
> validators (Eclipse) won't validate the response correctly if there's no
> explicit reference to the schema for the namespace of the root element...
Generally, the suggestion was correct: It's possible to omit the
additional schema location from the WFS configuration to get rid of the
direct reference. However, there's been a bug that caused an invalid
xsi:schemaLocation attributes then :-(
The good news is that it's fixed in trunk. However, please note that we
need to adapt the configuration files in the project in order to make it
work with 3.0-SNAPSHOT again (some configuration options have changed). I
would advise to wait a few more day until we finished changes in the
postgis feature store configuration (together with introducing hybrid mode
:-).
If you still want to give it a go, please refer to [1] for up-to-date
configurations (still changing).
Best regards,
Markus
Frans
schema reference. On the contrary, it seems a good way of keeping
GetFeature and DescribeFeatureType consistent. The only 'problem' that
I can think of is that DescribeFeatureType tends to ignore the
TYPENAME parameter, so it is possible that is returns a lot of
irrelevant information.
Markus Schneider
Are you referring to the fact that for, example a
DescribeFeatureType-request with typeName="ad:Address" will still return
a wrapper schema?
I know that one usually would expect to get back a document that only
defines "ad:Address", but I didn't find a way to do this that would
actually allow validation of GetFeature-responses. I ran into two
difficulties with such an approach:
- The definition of ad:Address depends on elements / types from other
namespaces (e.g. base). Therefore, all dependencies must be determined
and corresponding imports have to be included in the response.
- The import-relation in the schema fragments may contain cycles, and
schema parsers seem to get mad if an element / type is defined in two
documents with different system ids (although the definitions are
identical). The only way I found to solve this is by using a wrapper
schema...
Because of all this, the WFS does no re-exporting of the schema at the
moment if it is configured based on an GML application schema -- however
it does on-the fly schema generation for simple configurations, e.g. for
feature types derived from shapefiles. Instead (for the given example),
it determines all namespaces that the ad-Namespace depends upon and
writes a suitable wrapper document that imports all relevant fragments.
Improvements / ideas are welcome, but I am afraid that this is as good
as it gets...
Best regards,
Markus
Just van den Broecke
A suggestion, taken I understand the issue. Is it not possible to return
the schema file in which the feature is defined as-is without the
wrapper schema ? Appearantly the WFS "knows" its defining schema file as
in this response for AdministrativeUnit:
this would be the content of the response:
http://inspire.kademo.nl/deegree3/resources/schemas/inspire/annex1/AdministrativeUnits.xsd
This schema should be self-contained, i.e. define the relevant NSs and
do the proper imports.
Or am I missing something here ?
best,
Just