[GeoSciML] WFS querying of properties specified with xlink:href
portele at interactive-instruments.de
Wed Oct 10 18:05:32 EDT 2012
as far as I can tell this case is not perfectly clear in the standards. When WFS/FES went to ISO I had submitted a change proposal to support queries based on the underlying application schema only (not the XML artefacts). That was not fully accepted and while the query model is now defined on the feature/property level, it is explicitly allowed to use XPath expressions to reference also "components of the value of properties of a feature" when the feature content that a WFS offers is encoded using XML. The XPath profile includes access to XML attributes, so one could argue that "prop/@xlink:href" should work in filters. On the other hand, there is not clear requirement and there will always be limits how deep one can drill with Xpath into components of a property value (e.g. Xpaths to the outer ring in the third polygon in a multi surface are unlikely to work unless one uses a native XML database).
Am 10.10.2012 um 18:26 schrieb "Sen, Marcus A." <mase at bgs.ac.uk>:
> Clemens and GeoSciML listers,
> Some time ago we discussed the issue of using @xlink:href's for remote property values and querying them in a WFS service.
> In a meeting with Clemens Portele in Edinburgh in February 2011, which Tim summarised to the list on 7 March 2011, Clemens raised a concern that querying on the value of an xlink:href value was not strictly allowable under the rules of WFS/FES (Web Feature Service / Filter Encoding Specification). The property value should really be what is found by dereferencing the href in the GML property model. However, at the time, testing using @xlink:href in the XPath expressions in a fes:ValueReference element worked successfully both in Snowflake Software's GoPublisher WFS and in Clemens' XtraServer software.
> Since then we have happily been using these in queries. However, now I look back, I can't find a definitive decision that this is OK as far as the FES spec is concerned. My reading is that attribute values are allowed in the XPath and we are allowed to address "components" of a property but it isn't unambiguous.
> The issue has arisen again for us because BRGM have just tested querying our latest Snowflake GeoSciML v3 WFS and it doesn't like the use of @xlink:href in the query. I have confirmed with Snowflake software that they have, indeed, made the behaviour more restrictive than it used to be so queries that used to work no longer do. This is going to be a serious problem for querying GeoSciML features in a WFS as so many properties use our pattern of dictionary URIs in an xlink:href attribute.
> In order to ask Snowflake to change their software behaviour back again, I need some kind of authoritative declaration that this is valid behaviour. Or do current WFS and FES standards, in fact, not really support the kind of dictionary queries we want to do? This could be a problem.
> This message (and any attachments) is for the recipient only. NERC
> is subject to the Freedom of Information Act 2000 and the contents
> of this email and any reply you make may be disclosed by NERC unless
> it is exempt from release under the Act. Any material supplied to
> NERC may be stored in an electronic records management system.
More information about the GeoSciML