SLD Extension Notes
From GO1Wiki
| Table of contents |
Major Differences from 1.0.20
We extended <OnlineResource> in sld/1.0.20/common.xsd to accept an optional <Parameters> element. <Parameters> may consist of an xsd:any blob or they may consist of <Param> elements which have a name and contain an ogc:expression (particularly for the <PropertyName> expression). if <Parameters> contains xsd:any, then that payload should be posted to the <OnlineResource>’s href. if <Parameters> contains <Param>s, then the <Param>s should become name=value pairs to added as a query string to the <OnlineResource>’s href. We fully intend to move this change forward within the OGC for adoption into the next version of SLD released.
This pattern is currently for <ExternalGraphic>. A suitable alternative would be to give <ExternalGraphic> the optional <Parameters> element, and applications parsing a <FeatureStyle> that uses an <ExternalGraphic> would be aware that a <Parameters> element will change the way they handle the <ExternalGraphic>’s <OnlineResource>. These details can be worked through the OGC SLD WG.
Be aware that MS2525 FeatureStyles cannot be handled without this enhancement. Without it, we would require a Rule for every Symbol in the MS2525 spec, and we would not be able to parse or execute such a FeatureStyle in a timely manner.
Namespace Issue
OGC schemas have problems, namely that different schemas attempt to reuse type names within the same namespace, which is illegal. The clearest fix was to change the namespace of some of the schemas. wfs/1.0.0/WFS-basic.xsd and wfs/1.0.0/WFS-transaction.xsd changed from http://www.opengis.net/wfs to http://www.opengis.net/wfsrequest (which parallels the wmsrequest namespace). filter/1.0.0/filterCapabilities.xsd moved from http://www.opengis.net/ogc to http://www.opengis.net/filter as it conflicted with filter/1.0.0/filter.xsd.
The Namespace Issue was dealt with in order to produce all of our OGCBindings in one fell swoop. We can still accept incoming WFS requests in the wfs namespace because we can transform the xml documents to the wfsrequest namespace before unmarshalling with no loss of information. Likewise, we can embed FilterCapabilities that have the expected ogc namespace by transforming before we send out our response.
OWS 3 and the emerging OWS schemas are addressing the namespace issue, but we will need to adopt new spec versions when they are realeased. Our solution allows us to have the desired power now, without sacrificing backwards compatability with older specs or compatability with the current OGC schemas.
OGC Schema Error
If you have a good validator, then you won’t be able to validate anything against the OGC provided SLD 1.0.20 schema as the
sld/1.0.20/common.xsd references a nonexistant gml schema (there is no 2.1):
<xsd:import namespace=http://www.w3.org/1999/xlink schemaLocation="../../gml/2.1/xlinks.xsd"/>
We fixed this in our schema versions by adding the expected “.2” at the end of the version.
Readability
SYS refactored the OGC schemas to be easier to read and understand (better organization, better comments, etc.) note that refactoring them in no way changed them, just cleans them up.
Parser Compatability
SYS applied some best-practices in writing schemas intended for binding generation. <element ref=”… was avoided at all costs, complexTypes were declared for all of the phantom types (an element declaration that defines the complexContent inline results in a phantom type). Editing was done in XMLSpy5, and it should be noted that XMLSpy2005 professional is not as happy with some parts of the schemas, most notably the usage of abstract=”true”. We have not yet investigated the feasability of re-editing the schemas to validate in XMLSpy2005, though this would seem advantageous and help ensure a higher quality product. It should be noted that XMLSpy2005 rejects the official OGC schemas in numerous places.
Aside from points mentioned above, there should be no other major differences, and (with the namespace caveat understood) xml that validates against the unadulterated OGC schemas should validate against SYS versions with no problem. Rigorous testing will either prove this correct or unearth areas where we need to improve/fix our schemas, and either result will be welcome.
