[wfs-dev] XSD pitfall? (OWS)

Frank.Steggink@bentley.com Frank.Steggink at bentley.com
Tue Oct 31 14:34:58 EST 2006


Hi all,
 
I was looking at the XSD's belonging to WFS 1.1 today (in particular the
OWS schemata), because of some XML validation errors with existing WFS
servers. I've downloaded a fresh copy of the files this morning (TAR
dated October 20, 2006 on schemas.opengis.net) before the testing.
 
OwsServiceIdentification.xsd (version 1.0.0) mentions an element with
the name "ServiceIdentification", which uses an anonymous type that is
an extension of "DescriptionType" (in owsDataIdentification.xsd). The
types are both sequences, so the elements in the instance doc (in this
case the WFS_Capabilities document) must be in order. Because of the
inheritance, the content models of both the parent and the child are
treated as a sequence. This means that the elements in "DescriptionType"
(Title, Abstract, Keywords) must come before the elements in the
anonymous type of "ServiceIdentification" (ServiceType,
ServiceTypeVersion, Fees, AccessConstraints).
 
However, the result (to a GetCapabilities) I'm getting as the child
elements of ServiceIdentification is the following sequence of elements
(ServiceType, ServiceTypeVersion, Title, Abstract, Keywords, Fees,
AccessConstraints). This is the same order as the example in section
13.5 in WFS 1.1. (So, that means that the example is also wrong.) At
least the service metadata example (section 7.4.9) in the Web Common
Specification is right. Perhaps this problem is due to the fact that WFS
1.1 was released before OWS Common 1.0. (But wfs.xsd refers to version
1.0.0.)
 
I've a couple of questions: 
1) I assume the XSD's are normative, and not the examples, right? 
2) Have others experienced the same problems, while trying to validate
the Capabilities document with the XSD's?
3) What are good strategies when the resulting XML doesn't validate?
I've been thinking about it, but I would like to hear your opinions.
It's not very user friendly to mention that the responses don't
validate, so the user can't use the service. In case of GML, it is a bit
risky to accept the content, since you don't know what the author means,
but with WFS_Capabilities it's pretty clear what every element/attribute
means (within reasonable limits).
 
While browsing in the WFS 1.1 spec (section 6.6), I also see that the
OGC namespaces all have the following format
"http://www.opengeospatial.net/<spec_abbr>", but the schemata and all
implementations (known to me) use "http://www.opengis.net/<spec_abbr>".
I've confirmed this with a freshly downloaded PDF of WFS 1.1, in case I
missed any updates. The corrigendum 06-027r1 doesn't mention anything
about the namespaces.
 
Regards,

Frank Steggink
Bentley Systems
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.opengeospatial.org/pipermail/wfs-dev/attachments/20061031/f6d146db/attachment.html


More information about the wfs-dev mailing list