"fid" attribute in WFS 1.0.0

[dmorissette]

This is kind of related to bug 1413 where Steve added the ability to use a
"gml_featureid" metadata to specify a feature id field for WFS services which is
output as gml:id in the GML responses.

The WFS 1.0.0 (paragraph 7.1) and the filter encoding 1.0.0 (paragraph 11.2)
specs both state that this attribute is required and it must be called "fid". I
believe the name "gml:id" comes from a later revision of WFS. Also, the two
specs also seem to suggest that the following schema fragment should be used to
define this attribute:

<xsd:element name="FeatureId" type="ogc:FeatureIdType"/>
<xsd:complexType name="FeatureIdType">
   <xsd:attribute name="fid" type="xsd:anyURI" use="required"/>
</xsd:complexType>

Questions:

1- Should MapServer be fixed to output the gml_featureid item as "fid" in the
context of WFS 1.0.0 instead of "gml:id"?

2- Should MapServer be modified to define the "fid" using the schema construct
above instead of simply using type="string" like it always does by default?

[tomkralidis]

1./ Yes
2./ we should adhere to the schema fragment def in OGC:WFS 1.0.0, section 7.1. 
This should be changed in mapgml.c, line 1538.

The reason fid is cited in OGC:WFS 1.0.0, is because OGC:WFS 1.0.0 works off a
GML2 schema def.  So @fid is okay for GML2, but for GML3 @fid should be used.

So, the following changes should be made:

- when OGC:WFS 1.0.0 GetFeature is called with no outputFormat specified, output
@fid
- when OGC:WFS 1.0.0 GetFeature is called with outputFormat specified GML3,
output @gml:id

[sdlime]

I agree with Tom's suggestions. The fixes should be easy enough. Dan would you 
like to make them or should I? Note that we also need to support queries based 
on feature ids. I created a bug for that a while ago and have talked with 
Assefa from time-to-time about it.

Steve

[dmorissette]

I'll see if I can make the changes now.

[dmorissette]

Fixed in 4.9 CVS and backported to 4.8.x branch. 

Thanks for your explanations Steve and Tom, the fix was simpler than I had
imagined, I only had to change mapgml.c, line 1538 to:

 if (outputformat == OWS_GML2)
   msIO_fprintf(stream, "      <%s fid=\"%s\">\n", layerName,
shape.values[featureIdIndex]);
 else  /* OWS_GML3 */
   msIO_fprintf(stream, "      <%s gml:id=\"%s\">\n", layerName,
shape.values[featureIdIndex]);
 

[tomkralidis]

Daniel: should the logic in comment 4 be reversed?  Currently, MapServer
defaults GML2 unless GML3 is explicitly requested via outputFormat.

[dmorissette]

Tom, actually the format is determined before getting to that line (with GML2
being the default), so when we get to that line, outputformat should be either
GML2 or GML3, but cannot be unset.

The reason why I did the logic this way, is that I believe GML2 and its @fid was
a deprecated mistake from the past and (that I treat as an "exception") and that
the "rule" in future versions of GML is that we should expect to see @gml:id
(unless the WFS/GML people change their mind again which would not surprise me).
So if OWS-GML4 support is ever added and it still uses @gml:id then this if()
block won't need to be changed since GML2 is the exception and any other more
recent GML is the rule. OTOH if I had tested for GML3 in the if() we would have
to modify this if block everytime a new version of GML is supported.

Makes sense?

[tomkralidis]

Makes sense.  Thx.