+1 for option (1), compliance by default, with a system property to restore the current behaviour.
It would also be handy to have a Services / WFS option to return all responses as "text/xml", but this may be outside the scope of your work. It all depends how annoying "application/gml+xml" becomes. Kind regards, Ben. On 14/05/17 05:09, Nuno Oliveira wrote: > Hi all, > thanks for the feedback. > > You are correct Jukka it seems that I created a duplicated issue :( > thanks for the warning. > > So 'text/xml; subtype=gml/3.2' is an invalid MIME type that doesn't > comply with WFS 2.0 specification but is interpreted as XML by clients > that ignore the subtype parameter which is handy (note that the parsing > of this MIME type will fail for clients that actually try to interpret > the full MIME type definition). > > On the other side, 'application/gml+xml; version=3.2' is a valid MIME > type compliant with WFS 2.0 specification but is an horrible monstrosity > that is not recognized as XML by common clients like browsers. > > Note that WFS 2.0 reference implementation uses 'application/gml+xml; > version=3.2' as MIME type for GML 3.2 documents and adverts: > > <OutputFormats> > <Format>application/gml+xml; version=3.2</Format> > <Format>application/xml; subtype="gml/3.2.1"</Format> > </OutputFormats> > > So I see two options here: > > 1. Being compliant with WFS 2.0 specification by default which means > give preference to 'application/gml+xml; version=3.2', this will require > a flag in WFS configuration to allow the restore of the previous > behavior so clients that cannot be modified will still work. > 2. Not being compliant with WFS 2.0 specification by default and use > 'application/gml+xml; version=3.2' only when CITE compliant flag is > enabled. > > I vote for option 1. > > Cheers, > > Nuno Oliveira > > On 05/13/2017 09:55 AM, Andrea Aime wrote: >> Il 13 mag 2017 1:07 AM, "Ben Caradoc-Davies" <b...@transient.nz >> <mailto:b...@transient.nz>> ha scritto: >> >> Nuno, >> >> standards conformance is a good thing. There are three issues that we >> need to discuss: >> >> (1) This is a backwards-incompatible change for clients that rely on >> receiving a response with a "text/xml" MIME type. As this >> behaviour does >> not comply with the WFS 2.0 standard, clients have no basis to expect >> it, but it is nonetheless a change that may have some impact. >> >> >> Good call, we need a flag to re-instate previous behavior to avoid >> breaking upgrades >> for those that cannot fix the clients. >> >> >> (2) GML 3.1 output will still use "text/xml". This is inconsistent >> with >> GML 3.2 output, but then the WFS 1.1 and 2.0 standards are >> inconsistent. >> Do we prefer standards conformance or consistency? >> >> >> We have been running Cite tests for many years and are trying to >> update them (first my repeated failed attempts at prepping the work >> and then getting the community on board, >> and now Nuno working on Wfs 2.0 conformance, and Jody also said >> Boundless has an interest in upgrading the others to current) so >> I guess the choice has been "conformance" (at least most of the time, >> I don't pretend to make it the one and only). >> >> >> (3) Web browsers (certainly Firefox and Chrome) commonly display >> "text/xml" inline but offer to download "application/gml+xml". Try >> the >> layer previews and demo requests with your change applied and see the >> difference between GML 3.2 and GML 3.1. I can read XML (it is a >> Markup >> Language after all) and I like "text/xml" which indicates something a >> human can read. I think "application/gml+xml" is a horrible >> monstrosity. >> >> >> LOL, I agree it's pretty bad, but so are other things that we are >> doing to >> be compliant :-) >> >> Cheers >> Andrea >> > -- Ben Caradoc-Davies <b...@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
