[OSGeo-Standards] [WFS 2.0.x] ListStoredQueries response ambiguities

[Alex van den Hoogen | Geodan]

Dear all,

I have a question regarding the WFS 2.0.0/2.0.2 ListStoredQueries request.
I already asked this question on the GeoServer development mailing list,
but they referred me to here, since the standard is a bit unclear for us.

First and foremost, regarding GeoServer, their current implementation
returns invalid XML. This is because the ReturnFeatureType element is
invalid, which is disallowed since this is of type xml;qname. This is also
confirmed by the example response in WFS 2.0.2 in 14.3.4 of the
specification. However it also states that ReturnFeatureType (along with
Title and attribute id) are described in 14.2.

In 14.2, however, there is no mention of ReturnFeatureType, but there is of
ReturnFeatureTypes. Is this the same as ReturnFeatureType? Because if it
is, it contradicts the given XML specification document by stating that an
empty string is equals to a wildcard.

Also the change request regarding this issue (CR 11-100, ref. 25)
explicitly asks for a change on the singular ReturnFeatureType and not the
plural variant. But it is referred to by ReturnFeatureTypes in the 2.0.2
specification document on 14.2.2.5.2, because this is the only mention of
ReturnFeatureType(s) in 14.2. The change request also clearly states a
request for one stored procedure, GetFeatureById, while the xml (example?)
contains the stored procedure: FeaturesInPolygon..

If we treat both the singular as the plural form as one and the same
element, and refer to 14.2.2.5.2, you can see that a corrigendum is made in
the form of: "If the value of the returnFeatureTypes parameter is an empty
string, this indicates that the stored query can return features of any
type that the service offers.". But it seems that it also has a different
meaning in this context.

I hope you can clearly see why we are confused here. Since we don't really
know whether to follow the XML specification of QName, which clearly
disallows for an empty element. Or the written specification - if that is
even applicable here.

So, the questions we have now are:
 1. Is the reference in 14.3.4, really to 14.2.2.5.2 or is it just missing
in 14.2?
 2. Which 'standard' should we follow, the xml or the text, because they
seem contradicting?
 3. Is CR 11-100 applied correctly and thus consistently, or should this be
changed?
 4. Are there any suggestions on how to handle wildcards if the current
specification is correct?

References:
 - WFS 2.0.2: http://docs.opengeospatial.org/is/09-025r2/09-025r2.html
 - WFS 2.0.0 CR 11-100: https://portal.opengeospatial.org/files/45707 (pdf)

Kind regards,
Alex van den Hoogen

-------------------------------------
*Geodan*
Buitenhaven 27-A
5211 TP 's-Hertogenbosch (NL)

E alex.van.den.hoogen at geodan.nl

www.geodan.nl | disclaimer <http://www.geodan.nl/disclaimer/>
-------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20150120/b01f2e41/attachment.html>