make WFSCapabilities format retrieve feature type prefix and namespace

[elemoine]

this ticket suggests changing the WFSCapabilities format to retrieve the feature type prefix and namespace. Having this information is required to be able to create WFS protocols.

[elemoine]

patch-2640-A0.diff . Tests pass in FF3, IE7, and Chromium5.

[bartvde]

Hi Eric, the OGC would say, perform a WFS DescribeFeatureType to get that info, but I can understand you want to cut some corners, however, should we not use the same terminology as in the DescribeFeatureType parser, i.e.:

targetPrefix targetNamespace

However, these names are a bit XML schema specific, so maybe just

prefix namespace

or the terminology used by Format.WFST:

featureNS featurePrefix

otherwise we would end up with 3 ways to describe the same.

Just food for thought.

[elemoine]

I agree with being consistent with names already used in OpenLayers. See patch-2640-A1.diff .

[bartvde]

Looks good Eric.

[elemoine]

(In [10340]) make WFSCapabilities format retrieve feature type prefix and namespace, r=bartvde (closes #2640)

[elemoine]

As discussed with Tim we should avoid redundant data. See patch-2640-A2.diff . Tim, could you please review this?

[tschaub]

Thanks for making the additional patch Eric.

The namespace alias (prefix) in the type name is still redundant, and makes things more awkward in my opinion. The alias does not need to be stored between transactions. The document representing WFS capabilities may have a completely different set of namespace aliases than the document(s) representing feature reads/writes. When constructing a qualified name, the code creating the element should be able to pick any alias that doesn't collide and associate it with the namespace URI. And we shouldn't need to split the qualified name (namespace_alias:local_name) more than once.

[elemoine]

Understood. See patch-2640-A3.diff . Please review. Thanks for your patience.

[tschaub]

Nice. Thanks Eric. Please commit.

[elemoine]

(In [10348]) do not store redundant data in the object created by WFS Capabilities format, r=tschaub (closes #2640)

[ahocevar]

r10348 does not feel right to me. Tim, in your first comment, you said "OGC would say, perform a WFS DescribeFeatureType". Now we could do this by using the "name" and "featureNS" we get in the object that the WFSCapabilities format returns, issuing a POST request with xmlns declarations or a KVP request like:

?request=DescribeFeatureType&typeName=foo:${name}&namespace=xmlns(foo=${featureNS})

But the way we determine the feature type's namespace (by splitting it and using the prefix to look up the xmlns:<prefix> attribute in the responses DocumentElement), makes an assumption that does not necessarily need to work anywhere else than in GeoServer. The reason is that these xmlns declarations are redundant, neither required to return a valid WFS_Capabilities document, nor mandated by the WFS specification (see  http://schemas.opengeospatial.net/wfs/1.1.0/examples/WFS_Capabilities_Sample.xml).

So I would vote for returning the name of a featureType exactly as advertised in the caps doc, and adding a localName property (only set if we find can look up the namespace uri in the caps doc), to allow for a standards compliant workflow:

• do WFS GetCapabilities
• choose a featureType from the featureTypeList
• use its name to create a WFS DescribeFeatureType request

Having featureNS and localName is a benefit if we work with GeoServer, but we should not rely on it. The OGC way is to use DescribeFeatureType.

See attached patch with tests. Tests still pass. Please review.

[tschaub]

Replying to ahocevar:

r10348 does not feel right to me. Tim, in your first comment, you said "OGC would say, perform a WFS DescribeFeatureType". Now we could do this by using the "name" and "featureNS" we get in the object that the WFSCapabilities format returns, issuing a POST request with xmlns declarations or a KVP request like: {{{ ?request=DescribeFeatureType&typeName=foo:${name}&namespace=xmlns(foo=${featureNS}) }}} But the way we determine the feature type's namespace (by splitting it and using the prefix to look up the xmlns:<prefix> attribute in the responses DocumentElement), makes an assumption that does not necessarily need to work anywhere else than in GeoServer. The reason is that these xmlns declarations are redundant, neither required to return a valid WFS_Capabilities document, nor mandated by the WFS specification (see  http://schemas.opengeospatial.net/wfs/1.1.0/examples/WFS_Capabilities_Sample.xml).

Hey. I'm not opposed to making a change here - particularly because GeoServer didn't support the NAMESPACE parameter in WFS 1.1.0 until  r14549 and WFS 1.0.0 doesn't provide a NAMESPACE parameter. However, I'm confused what you mean by redundant xmlns attributes. The WFS 1.1.0 capabilities example linked above advertises a number of feature types. One snippet below:

  <wfs:FeatureTypeList>
      <wfs:FeatureType xmlns:bo="http://www.BlueOx.org/BlueOx">
         <wfs:Name>bo:WoodsType</wfs:Name>
         ...

(Note that browsers will often hide this xmlns prefixed attribute in their default rendering. Look at the source of the response directly to see it.)

In this case, the bo prefix is bound to the http://www.BlueOx.org/BlueOx namespace. And (as with all XML) this is true for child nodes of this one wfs:FeatureType element. A single document could very well bind the bo prefix to a different namespace for a different element.

If you look at the  WFS 1.1.0 xsd, you can see that the value of the Name element in a FeatureType element is a xsd:QName. This means that a feature type name is a qualified name (qualified with a namespace URI mapped to a namespace alias or prefix).

Again, I'm not opposed to making things work better, but I want to make sure we understand each other correctly. I am not sure what you mean about GeoServer specific functionality above.

So I would vote for returning the name of a featureType exactly as advertised in the caps doc, and adding a localName property (only set if we find can look up the namespace uri in the caps doc), to allow for a standards compliant workflow: * do WFS GetCapabilities * choose a featureType from the featureTypeList * use its name to create a WFS DescribeFeatureType request Having featureNS and localName is a benefit if we work with GeoServer, but we should not rely on it. The OGC way is to use DescribeFeatureType. See attached patch with tests. Tests still pass. Please review.

[tschaub]

In case my point is not clear, here it is restated: the literal value of the Name element advertised for a FeatureType is ambiguous if you don't know the namespace URI that the prefix maps to. The value of the Name element is a qualified name. That means it will be of the form ns:local or local. If a namespace alias is not present, the default namespace for the element is implied. In either case, the namespace alias (or prefix) doesn't carry meaning on its own. It is the namespace URI that qualifies the name.

[ahocevar]

Tim, thanks for the explanation. Stupid /me was looking for the xmlns:bo attribute in the WFS_Capabilities element only. Also, I gave the QName explanations in the WFS specs another read, and see now that you are absolutely right.

Sorry for the noise, closing this ticket again.

[tschaub]

I didn't mean to imply that request for a change here was invalid. As far as I can tell, a client cannot make a GetFeature or DescribeFeatureType request using GET in WFS 1.0.0 unless they maintain the namespace alias assumed in the capabilities doc. The common namespace paramter was added in WFS 1.1.0.

Unless I am misunderstanding, you can start with a perfectly valid WFS 1.0.0 capabilities doc and have no way to issue unambiguous GET requests with GetFeature or DescribeFeatureType methods. This would happen in the case a WMS caps snippet looked like the following:

  <wfs:FeatureTypeList>
      <wfs:FeatureType xmlns:feature="http://example.com/#foo">
         <wfs:Name>feature:unique</wfs:Name>
         ...
      </wfs:FeatureType>
      <wfs:FeatureType xmlns:feature="http://example.com/#bar">
         <wfs:Name>feature:unique</wfs:Name>
         ...
      </wfs:FeatureType>
      ...
  </wfs:FeatureTypeList>

In this way, WFS 1.0.0 is broken (please correct me if I don't understand). If this is true, our options are to include a workaround (maintain the advertised namespace alias and hope that it is unique) or tell people to use WFS 1.1.0.

I imagine the majority opinion would be to include a workaround (my opinion is to discourage the use of broken specs - the OGC even marks these old versions as deprecated).