[Geoserver-devel] extend ExtendedCapabilitiesProvider for WMS 1.1.1

GeoServer GeoServer Developer
1

Hi Justin, all,

I am working on tighter gwc/wms integration and found myself in the need
to use ExtendedCapabilitiesProvider for WMS 1.1.1, in order for the
geoserver gwc module to be able of contributing to the WMS 1.1.1
capabilities (well I could have hacked on the WMS module but this is
nicer and cleaner).

I would like a review and opinions on the following patch, to hopefully
get it applied asap:
<https://github.com/groldan/geoserver_trunk/commit/5ac14330c3ad0a1f64aa048015c96ee23d359450&gt;

Quick tour:
- ExtendedCapabilitiesProvider gets two more methods,
getVendorSpecificCapabilitiesRoots and
getVendorSpecificCapabilitiesChildDecls. The intent of each is
documented on their javadocs. The reason why both are needed instead of
a single one a'la getSchemaLocations() lies on how we need to set up the
internal DTD definition for the capabilities document instance. By one
side we need the allowed elements for the VendorSpecificCapabilities
element, which may come from various providers, in order to build a
declaration like !ELEMENT VendorSpecificCapabilities
(ContributedElementOne*, ContributedElementTwo*) >.
By the other side we need to declare all children elements bellow that,
hence the two methods.

- both those and encode now have an argument of type
GetCapabilitiesRequest. Reason is that the provider may need to take
some action depending on some request property (version, presence of a
parameter like TILED or NAMESPACE, etc).

- the other thing to note is that, for 1.1.1, the internal DTD
declaration needs to be written in GetCapabilitiesResponse and not on
the transformer, simply because there's just no way in the Java XSLT api
to output an _internal_ DTD declaration, so workaround is to apply an
extra transform that outputs the declaration as plain text and then
follows as an identity transform. So I build the full DTD declaration
before writing to the client (only if needed) and then pass it as a
parameter to the getcaps_111_internalDTD.xsl stylesheet.

Well, with that in place we can now also contribute to WMS 1.1.1 caps
the same way than for 1.3.0, meaning we _could_ implement the WMS 1.1.1
INSPIRE profile as well as the WMS-C one for 1.1.1 and 1.3.0.

Any comment/concern/approval to commit is welcomed.

Cheers,
Gabriel

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

2

Hi Gabriel,

All sounds good to me. The extended caps was kind of developed quick and dirty for the requirement. So any refactoring you see fit sounds good and supporting them for wms 1.1.1 as well is great.

+1.

-Justin

On Mon, Jan 3, 2011 at 9:24 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

Hi Justin, all,

I am working on tighter gwc/wms integration and found myself in the need
to use ExtendedCapabilitiesProvider for WMS 1.1.1, in order for the
geoserver gwc module to be able of contributing to the WMS 1.1.1
capabilities (well I could have hacked on the WMS module but this is
nicer and cleaner).

I would like a review and opinions on the following patch, to hopefully
get it applied asap:
<https://github.com/groldan/geoserver_trunk/commit/5ac14330c3ad0a1f64aa048015c96ee23d359450>

Quick tour:

  • ExtendedCapabilitiesProvider gets two more methods,
    getVendorSpecificCapabilitiesRoots and
    getVendorSpecificCapabilitiesChildDecls. The intent of each is
    documented on their javadocs. The reason why both are needed instead of
    a single one a’la getSchemaLocations() lies on how we need to set up the
    internal DTD definition for the capabilities document instance. By one
    side we need the allowed elements for the VendorSpecificCapabilities
    element, which may come from various providers, in order to build a
    declaration like !ELEMENT VendorSpecificCapabilities
    (ContributedElementOne*, ContributedElementTwo*) >.
    By the other side we need to declare all children elements bellow that,
    hence the two methods.

  • both those and encode now have an argument of type
    GetCapabilitiesRequest. Reason is that the provider may need to take
    some action depending on some request property (version, presence of a
    parameter like TILED or NAMESPACE, etc).

  • the other thing to note is that, for 1.1.1, the internal DTD
    declaration needs to be written in GetCapabilitiesResponse and not on
    the transformer, simply because there’s just no way in the Java XSLT api
    to output an internal DTD declaration, so workaround is to apply an
    extra transform that outputs the declaration as plain text and then
    follows as an identity transform. So I build the full DTD declaration
    before writing to the client (only if needed) and then pass it as a
    parameter to the getcaps_111_internalDTD.xsl stylesheet.

Well, with that in place we can now also contribute to WMS 1.1.1 caps
the same way than for 1.3.0, meaning we could implement the WMS 1.1.1
INSPIRE profile as well as the WMS-C one for 1.1.1 and 1.3.0.

Any comment/concern/approval to commit is welcomed.

Cheers,
Gabriel

–
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.