Implementation notes on Filter Encoding 2.0: matchAction

Work is undergoing to implement the WFS 2.0 and INSPIRE Download Service specifications in deegree 3. In the last few days, I have been working on Filter Encoding 2.0 (which is a prerequisite for WFS 2.0 support). This gave me some insights and also revealed some curiosities, which I would like to document and share.

This post is about the matchAction attribute introduced in filter 2.0. It disambiguates the evaluation of operators that reference multi properties. Consider the following example feature (from the spec, section 7.7.3.3):

<ex:Building gml:id="b123">
  <gml:name>175 Fifth Ave.</gml:name>
  <gml:name>Flatiron</gml:name>
  <gml:name>Acme Building</gml:name>
  <!-- ... -->
</ex:Building>

Now consider the following filter 1.1.0 expression (namespace bindings omitted for brevity):

<Filter>
  <PropertyIsEqualTo>
    <PropertyName>gml:name</PropertyName>
    <Literal>Flatiron</Literal>
  </PropertyIsEqualTo>
</Filter>

Should this filter evaluate to true or false? Well, it depends… If you assume that the PropertyIsEqualTo operator requires all gml:name properties to be equal to Flatiron then it won’t match. If a single match is sufficient, it will. Up until filter 1.1.0, the correct interpretation doesn’t appear to be specified (in deegree 3 a single successful match is considered sufficient). Filter 2.0 adds the optional matchAction attribute to clarify this situation:

<Filter>
  <PropertyIsEqualTo matchAction="Any">
    <ValueReference>gml:name</ValueReference>
    <Literal>Flatiron</Literal>
  </PropertyIsEqualTo>
</Filter>

(if you wonder: ValueReference replaces PropertyName in 2.0)

Any means that this predicate will evaluate to true since there is at least one gml:name with value Flatiron. Besides Any, one can also specify All or One (exactly one value must match).

I really appreciate this addition to the standard, but I wonder why this attribute is only defined for comparison operators of type fes:BinaryComparisonOpType? I think it would make perfect sense for PropertyIsLike and PropertyIsBetween as well (in some case it might even apply to PropertyIsNil). And what about the spatial operators — in complex application schemas, features often allow for multiple spatial properties. I think the correct evaluation of Intersects referring to a multi geometry property should be clarified as well. Why is matchAction not supported here?

Also, I wonder how operators that reference two multi properties have to be evaluated? Let’s modify the example feature and filter:

<ex:Building gml:id="b123">
  <gml:name>175 Fifth Ave.</gml:name>
  <gml:name>Flatiron</gml:name>
  <gml:name>Acme Building</gml:name>
  <ex:name>Acme Building</ex:name>
  <ex:name>Building I</ex:name>
  <!-- ... -->
</ex:Building>

Filter:

<Filter>
  <PropertyIsEqualTo matchAction="Any">
    <ValueReference>gml:name</ValueReference>
    <ValueReference>ex:name</ValueReference>
  </PropertyIsEqualTo>
</Filter>

Should this filter match the feature? What is the proper semantics of Any, All or One in the multi/multi case? Comments are welcome…

Advertisements

About Markus Schneider

Geospatial software developer, CEO of Occam Labs
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s