So I guess what I will do for now is create a special mime type for
GML3, which would then support app-schema. The old mime type would still
return GML2, and produce an error if it is run against app-schema data.
Cheers
Niels
On 18/11/10 04:12, Andrea Aime wrote:
On Wed, Nov 17, 2010 at 4:25 PM, Justin Deoliveira<jdeol...@opengeo.org> wrote:
Yeah, the mime type for gml output for GetFeatureInfo was not really though
out with regard to gml versions. "application/vnd.ogc.gml" is ambiguous.
Ideally choosing the output format would follow the way other output formats
do it and just use a different mime type. "text/xml; subtype=gml/2.1.2" vs
"text/xml; subtype=gml/3.1.1", etc... Choosing output format based on
backend data source could work... albeit a bit tricky. And I think it is
nicer to be explicit.
I could also see a configuration option that allowed the admin to control
whether gml2 or gml3 is used for the "application/vnd.ogc.gml" mime type.
Sigh, tricky issue, sounds like we're going to get screwed some way or the
other.
WMS 1.1 was created when only GML2 was around, I guess that's the
reason why they did not bother to specify the version (did GML1 ever
see the light of day?).
Wondering what's the practice in the wild? Afaik given than mime type
everybody is going to expect GML2, never seen it done differently.
WMS 1.3 does not even provide a mime type guidance for feature type
info afaik (and even for WMS 1.1 it was a set of suggestions, but they
did stick with implemetations), you are just free to do whatever you
want.
Whoever is using complex features today is breaking new grounds anyways,
meaning it's dealing with custom written clients, the out of the box
ones more often than not cannot deal with them.
The configuration idea might work, but what I've seen in practice
is that servers providing complex features are either working
in an academic or niche setup, or they have to provide both
complex features and then flat views of the former that provide
a simple feature interface to the same data (the first to abide to
a standard, the latter to actually be usable by the most common
OGC clients).
Going out with GML3 might please
the few that root for complex features but will break all
other clients. At the very least the choice should be per
layer, not per server, so that the setup that try to compromise
between complex features and common needs can still
work.
My suggestion: create an explicitly mime type for GML2 and GML3
and let the old mime type be used for what it has always been
used, that is, GML2. Don't go break established expectations,
spec may be ambigous, but industry practice does not look like
it is. At least, as far as I know. Glad to be proved wrong: what server
is returning GML3 out of a GetFeatureInfo when the request
says application/vnd.ogc.gml? What WMS clients can actually
deal with GML3 as a feature info response?
Cheers
Andrea
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-----------------------------------------------------
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
