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