I agree that the default output format for each WFS version would be the 
behaviour of minimum surprise for client users. Not specifying an 
outputformat would achieve this.

Kind regards,
Ben.

On 28/05/14 13:44, Jody Garnett wrote:
> Ben you are correct that a client can request any supported format.
> However what should the default be for the GeoTools client if the user
> has not specified a version? I was guessing that it should follow the
> version of GML marked as the default for the spec.  Like they probably
> have it in there right? If not specified the server will return GML2 or
> something?
>
> I am concerned any further discussion just distracts Neils from the few
> remaining issues with the client (i.e. namespace).
>
> Discussion about how a client should act may best be done on the
> standa...@osgeo.org <mailto:standa...@osgeo.org> list, where we have
> access to other WFS implementors. Perhaps I am alone in being surprised
> :) I seriously assumed version negotiation had failed because of the use
> of GML3.
>
> One thing I cannot answer is *how*, at the GeoTools level, a java
> developer can choose what format is used?
>
> /Niels please take the following as "discussion" to ensure I understand
> the design of both GeoTools and the WFS Client. It is not intended as a
> request/distraction from your list of issues:/
>
> The obvious solution would be to allow Java developers to select a
> different (i.e. non default) exchange format as a Query Hints parameter.
> The hard part is communicating what options are supported for a given
> WFS. I am not sure if the DataStore API has a way to advertise both
> support for a query hunt, and what the valid options are.
>
> A "workaround" would be to use the FeatureType schema "user map" to
> advertise a list of formats. That is kind of opaque, and would prefer if
> Java developers have access to the WFS Client (and resulting
> GetCapabilities) to look up the list of formats directly in the parsed
> GetCapabilities data structure.
>
>
> Jody Garnett
>
>
> On Wed, May 28, 2014 at 12:25 PM, Ben Caradoc-Davies
> <ben.caradoc-dav...@csiro.au <mailto:ben.caradoc-dav...@csiro.au>> wrote:
>
>     If a WFS server advertises that it supports GML3 outputFormat, then
>     a client is entitled to expect that is can request this
>     outputFormat. For example, it is very common for app-schema layers
>     to be accessed using service=WFS&version=1.1.0&__outputFormat=gml32
>     . There is only the default format and an unordered list of other
>     formats. I do not see this as unusual, and it need not be for
>     performance reasons.
>
>     A bigger problem is that supported output formats cannot be
>     specified by feature type. This is a defect in the WFS
>     specification. This is a huge problem for app-schema layers as
>     application schemas define types for a single version of GML.
>     Current GeoServer behaviour is to respond with broken garbage if a
>     WFS 1.1 request is made for feature type defined in GML 3.2 without
>     outputFormat=gml32.
>
>     Note also that the namespace URI is different for WFS 2.0.
>
>
>     On 28/05/14 06:36, Jody Garnett wrote:
>
>         Like I guess it is "okay" for a client to recognise what supported
>         formats a server provides and choose GML3 over GML2. But it is
>         very unusual.
>
>     [...]
>
>         It is is very odd - My immediate assumption on seeing the use of
>         GML3
>         was that the client was broken.
>
>     [...]
>
>         I would expect the WFS 1.0 server to default to GML2
>         communication (i.e.
>         follow the specification as written) and only choose an
>         alternative for
>         performance reasons. All Requests going to the WFS 1.0 service
>         would be
>         using GML2, so this would be a case of input and output matching.
>
>
>     --
>     Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
>     Software Engineer
>     CSIRO Earth Science and Resource Engineering
>     Australian Resources Research Centre
>
>

-- 
Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to