Justin, I agree. A configurable option would allow deployers to choose the behaviour they want.
Kind regards, Ben. On 21/04/10 22:39, Justin Deoliveira wrote: > Hi Ben, > > I have ran up against this before as well, and indeed lots of things > will break with this change. I tried it out when doing experiments on a > faster encoder and multiple featureMemeber elements led to lots of trouble. > > However that said I think it would be a good idea to add a configuration > element to allow to toggle this behavior, and leave it to featureMembers > by default. Pretty much exactly the way we handle feature bounding. > > -Justin > > On 4/20/10 8:45 PM, Ben Caradoc-Davies wrote: >> I propose a change to WFS behaviour that will have widespread impact on >> GeoServer and GeoTools users. In particular, XML consumers that have >> grown accustomed to consuming featureMembers may break. However, this >> change is necessary to support gml:id uniqueness in complex features. >> GeoServer cannot be be a general-purpose WFS response encoder without >> it. It is worth noting that deegree encodes featureMember not >> featureMembers. >> >> In a nutshell: don't use featureMembers because it is an >> ArrayPropertyType and cannot be used for xlink:href. >> >> http://jira.codehaus.org/browse/GEOT-3046 >> >> ****** >> >> GeoTools (and thus GeoServer) encodes a FeatureCollection as (for example): >> >> {code} >> <wfs:FeatureCollection> >> <gml:featureMembers> >> <gsmlMappedFeature gml:id="mf.1" /> >> <gsmlMappedFeature gml:id="mf.2" /> >> <gsmlMappedFeature gml:id="mf.3" /> >> </gml:featureMembers> >> </wfs:FeatureCollection> >> {code} >> >> In this skeleton, the features are empty, but if they are encoded >> inline, it is possible that, because of associations, a feature (e.g. >> mf.3) might have been already been encoded inline as a property of an >> earlier feature before it is to be returned as a top-level feature in >> its own right. In this case, the feature should be encoded as an >> internal xlink:href link on the enclosing property type, because >> gml:id's cannot be duplicated in a document. This is only possible if >> featureMember is used. The response then becomes: >> >> {code} >> <wfs:FeatureCollection> >> <gml:featureMember> >> <gsmlMappedFeature gml:id="mf.1"> >> ... >> <gsmlMappedFeature gml:id="mf.3" /> >> ... >> </gsmlMappedFeature> >> </gml:featureMember> >> <gml:featureMember> >> <gsmlMappedFeature gml:id="mf.2" /> >> </gml:featureMember> >> <gml:featureMember xlink:href="#mf.3" /> >> </wfs:FeatureCollection> >> {code} >> >> ****** >> > > -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
