[GeoSciML] WFS querying of properties specified with xlink:href

Simon.Cox at csiro.au Simon.Cox at csiro.au
Wed Oct 10 18:27:32 EDT 2012

Sorry - I'm joining this thread part way through, so am not clear if the concern is around using the values of xlink:href in a query for 
(i) feature references
(ii) concepts
(iii) both. 

In GML 3.3 there is a clause that clarifies and revises the use of GML for 
(a) assigning names and identifiers
(b) referring to external resources using their identifier. 
Prior to GML 3.3 there was a lot of confusion about this, around the elements whose type is gml:CodeType and gml:ReferenceType. 
In GML 3.3 we made it explicit, that references to external resources (including concepts) should be serialized using the gml:ReferenceType, which means that the reference is carried on an xlink. 
This is consistent with the use of xlinks in the inline-or-by-reference pattern, but allows for reference to concepts that are not (necessarily) available in a GML serialization. 

Given this recommendation, I guess there shuld be a flow-on change to WFS/FES that enables this serialization pattern to be consistent with the query.  
My hunch is that the solution should be scalable to both feature-references (with some kind of rule about the relationship with a gml:identifier value) and concept/vocabulary items (resources denoted inherently by URIs under the SKOS model). 

Simon Cox
Research Scientist
CSIRO Earth Science & Resource Engineering

Phone: +61 8 6436 8639 | Fax: +61 8 6436 8555 | Mobile: 0403 302 672
simon.cox at csiro.au | www.csiro.au
Address: ARRC, PO Box 1130, Bentley, WA 6102, Australia
From: geosciml-bounces+simon.cox=csiro.au at lists.opengeospatial.org [geosciml-bounces+simon.cox=csiro.au at lists.opengeospatial.org] On Behalf Of Clemens Portele [portele at interactive-instruments.de]
Sent: Thursday, 11 October 2012 6:05 AM
To: Sen, Marcus A.
Cc: A mailing list for GeoSciML; Tertre Francois
Subject: Re: [GeoSciML] WFS querying of properties specified with xlink:href


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.
> Comments?
> Marcus
> --
> 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 mailing list