Hi,
as you surely known playing with label options in GeoServer SLD
editor is hard, especially because the SLD you end up creating
often contains VendorOption tags that are not in the standard
schema.
I was wondering if we could do the following to alleviate the issue:
* create a StyledLayerDescriptorGS.xsd file that contains the extra
definitions and ship it along with the other schemas in GeoServer
* publish a copy of the relevant schemas at geoserver.org, much
like in schemas.opengis.net, so that we have a stable place
that the XML files can refer to (we could keep the schemas in
svn and publish it directly, so that if we need to make
any further customisation it's easy to do so).
The nice thing about renaming the xsd is that we simply admin
we tweaked it, it's not the standard, but gives you more opportunities
than the standard itself, and avoids the validation issues.
If we wanted to make this super clean, we could extend the
TextSymbolizer element into a GTTextSymbolizer that allows
the vendor option element. That would be cleaner from a schema
p.o.v., but it would require some parser work in GT2 (not
that much actually).
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Sounds like a good idea. So just to ensure that I understand the two options are:
1. Modify StyledLayerDescriptor.xsd directly adding support for vendor options.
2. Create a GTStyledLayerDescriptor.xsd which includes StyledLayerDescriptor.xsd and creates a new element called "GTTextSymbolizer" which extends from "TextSymbolizer".
Option 1:
+ Easier on users as they simply keep on referencing the regular SLD schema
- We have to modify the schema... so if they try to validate against say the schema at schemas.opengis.net validation will fail.
Option 2:
+ Cleaner from a schema point of view, user explicitly has to specify the "new" schema which seems less confusing
- I am not sure a clean extension of TextSymbolizer is possible b/c it is an element with an anonymous complex type. If it had a named type then it would be easy. So I think the only way would be to basically copy the type of TextSymbolizer into the type of GTTextSymbolizer and our custom stuff.
Tough call... I guess if i had to choose one it would be option 2. Seems cleaner and more explicit.
Andrea Aime wrote:
Hi,
as you surely known playing with label options in GeoServer SLD
editor is hard, especially because the SLD you end up creating
often contains VendorOption tags that are not in the standard
schema.
I was wondering if we could do the following to alleviate the issue:
* create a StyledLayerDescriptorGS.xsd file that contains the extra
definitions and ship it along with the other schemas in GeoServer
* publish a copy of the relevant schemas at geoserver.org, much
like in schemas.opengis.net, so that we have a stable place
that the XML files can refer to (we could keep the schemas in
svn and publish it directly, so that if we need to make
any further customisation it's easy to do so).
The nice thing about renaming the xsd is that we simply admin
we tweaked it, it's not the standard, but gives you more opportunities
than the standard itself, and avoids the validation issues.
If we wanted to make this super clean, we could extend the
TextSymbolizer element into a GTTextSymbolizer that allows
the vendor option element. That would be cleaner from a schema
p.o.v., but it would require some parser work in GT2 (not
that much actually).
Opinions?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Sounds like a good idea. So just to ensure that I understand the two options are:
1. Modify StyledLayerDescriptor.xsd directly adding support for vendor options.
2. Create a GTStyledLayerDescriptor.xsd which includes StyledLayerDescriptor.xsd and creates a new element called "GTTextSymbolizer" which extends from "TextSymbolizer".
Option 1:
+ Easier on users as they simply keep on referencing the regular SLD schema
- We have to modify the schema... so if they try to validate against say the schema at schemas.opengis.net validation will fail.
Option 2:
+ Cleaner from a schema point of view, user explicitly has to specify the "new" schema which seems less confusing
- I am not sure a clean extension of TextSymbolizer is possible b/c it is an element with an anonymous complex type. If it had a named type then it would be easy. So I think the only way would be to basically copy the type of TextSymbolizer into the type of GTTextSymbolizer and our custom stuff.
Tough call... I guess if i had to choose one it would be option 2. Seems cleaner and more explicit.
Option 1 was actually copying over, changing TextSymbolizer, _and_
changing the schema file name into GSStyledLayerDescriptor.xsd.
So still explicit, what is not explicit is what we modified.
Option 2 is more explicit instead... and yeah, it seems we'll
have to clone the element. Darn, why is everything always so
complex with OGC? 
Anyawys, I agree option 2 is better.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.