Content based filtering using XPath 1.0

Copyright © 2011 Open Geospatial Consortium. 81

17.2.3 Content based filtering of notifications

Filters are used to identify the notifications from the set of all notifications generated by a producer see OGC 09-032 clause 6.6.1.3 that are of interest to a consumer see OGC 09-032 clause 6.6.1.1. Only those notifications will be sent to the consumer. The complexity of the filter criteria depends on the filter language, also called dialect. Content based filter dialects like XPath only work on XML encodings of notifications. Object based filter dialects like the Filter Encoding Specification FES use the object model underlying the notification content, potentially performing conversion of reference systems on the fly. A filter is usually applied on the actual event or message, not on a possible container type that may be added by the technology realizing the publishsubscribe pattern in a specific binding before the message is actually sent out to a consumer. The context for filter execution should be defined for a given dialect. This standard recognizes XPath 1.0 and FES 1.1 as potential content based filter dialects also see clause 8.2.2.

17.2.3.1 Content based filtering using XPath 1.0

Requirement http:www.opengis.netspecSWES2.0reqCommunicationPubSubXPathFiltering REQ 64. When using XPath 1.0, the value of a filter statement in a subscription shall be an XPath 1.0 predicate expression PredicateExpr. Its context is: • Context Node: the root element of the eventmessage XML – NOT of any container element that wraps the actual eventmessage • Context Position: 1 Context Size: 1 – because the filter applies to exactly one eventmessage that has exactly one root element • Variable Bindings: None. • Function Libraries: XPath 1.0 Core Function Library. • Namespace Declarations: The in-scope namespaces property see W3C XML Information Set of the XML element that contains the XPath filter statement. 82 Copyright © 2011 Open Geospatial Consortium. NOTE A service that accepts a subscription with XPath 1.0 filter dialect should store the in-scope namespaces and their prefix mappings from the subscription request. The service should use those mappings when evaluating the XPath expression for a given eventmessage. This avoids conflicts when the prefix mapping used in the subscription request does not match with the prefix mapping in the eventmessage. Consider the following example of a SWESEvent: Listing 7 – SWESEvent that signifies a capabilities change happened swes:SWESEvent xmlns:swes = http:www.opengis.netswes2.0 xmlns:xsi = http:www.w3.org2001XMLSchema-instance xmlns:wsa = http:www.w3.org200508addressing swes:identifier http:www.example.orgeventsa87s9c76s swes:identifi er swes:eventTime 2010-08-03T12:14:43Z swes:eventTime swes:code CapabilitiesChanged swes:code swes:service wsa:EndpointReference wsa:Address http:my.swe-service.compath wsa:Address wsa:EndpointReference swes:service swes:SWESEvent To find out whether the code in a SWESEvent matches a specific value, the following XPath expression can be used: swes:code=CapabilitiesChanged This expression would be evaluated to true. Copyright © 2011 Open Geospatial Consortium. 83

17.2.3.2 Content based filtering using FES 1.1