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 ----------------------------------------------------- ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
