Support for <?xml-template ?> headers in GetCapabilities responses (XSLT templates)

[relet]

Support for headers in GetCapabilities responses (XSLT templates)

"<?xml-stylesheet type=\"text/xsl\" href=\""+xsltUrl+"\" ?>\n"

We have some code to add xml-template headers to the GetCapabilities responses from geowebcache. XSLT style sheets can be used to help human readers / web browser users to get an understanding of the GetCapabilities document, by listing the data in human readable form, and provide a map client, or map client code to browse the service immediately.

I can issue a pull request, if you can confirm that my design choices are acceptable.

• I put the code into WM*SGetCapabilities.java (obviously)
• I put the configuration into meta/ServiceInformation.java, meta/XsltTemplates.java and the respective section of geowebcache.xml

Should we handle the relevant possibility that someone requires several documents for different versions of the GetCapabilities requests? (It could be handled in pure XSLT as well)
Should we take into account the remote possibility that someone wants to provide xml templates with a different mime type?

[groldan]

The only problem I see is the change of the content type header which for WMS 1.1.1 (the only one we support) the spec mandates it to be application/vnd.ogc.wms_xml and not text/xml.
Yeah, non very web friendly, but a spec is a spec. In any case I think we should only change the content type if an xsl template is in place, but still it would change it always potentially (although admittedly unlikely) confuse spec conformant clients.
One way to overcome this would be instead to make the template name a request argument. Then the transform/content type change would only take place if the client required it? And you can configure your client to call for one or another transform as necessary.
Makes sense?

[groldan]

Are you still interested on getting this on master? if so would you reply to the proposal above to avoid changing the content type always?

[relet]

Hi - sorry, I missed the first replies.

Yup, I think changing the content type if a xsl template is in place would work. If you do provide an xsl, you intend to break the spec and make it web readable.

I'm neutral on the other option to require a parameter. I have two use cases:

• To use the transformed URL in documentation - a parameter will work there.
• To be helpful to people clicking on GetCapabilities URLs to see what the service is about, instead of opening it with their client. I would have to send them either the non-transformed URL, or both.