Copyright © 2010 Open Geospatial Consortium, Inc.
95 A more detailed discussion of reliable messaging technology for SOAP and RESTful
bindings is provided in chapter 8.8.1 of OGC 09-032.
9 Event filtering
In this chapter, various aspects that are relevant for event filtering are discussed. The first section elaborates the pitfalls that exist when filtering at an Event Service. The second
section discusses languages for filter processing events. Finally, spatial filtering of events is investigated in more detail.
9.1 Potential Pitfalls
This section briefly discusses some of the general pitfalls that need to be avoided for doing useful filtering with an Event Service.
9.1.1 Boolean Result for Filter Statement
An Event Service matches events that it generates or that it receives from some publishers against the existing subscriptions. The service needs to decide whether a
given event matches a subscription’s filter criteria or not. Therefore, the filter used in the subscription needs to evaluate to a boolean value.
A filter language needs to define very clearly how such a result is computed. For example, an XPath expression may have a set of XML nodes as result. If no further rules
are defined how the Event Service should handle the result of the XPath expression, it will produce an exception. Further details on how XPath expressions should be handled
are provided in section 9.2.2. Here, the following observation is important: in order for a filter language to be usable in an Event Service, either the language itself clearly defines
how to achieve a boolean result out of a filter statement encoded in that language or the Event Service defines the required rules. In the case of XPath, the Event Service could
for example apply an implicit boolean function call to the results of an XPath expression
– see section 9.2.2 for further details. If a subscription does not use a filter language but some form of processing language to
identify the events that are of interest, the requirement to have a boolean result does not apply. The processing language then defines the results that are sent to a subscription’s
consumer endpoint. The Event Pattern Markup Language is such a processing language see section 9.2.3.
9.1.2 Event Wrapper
Another problem to perform filtering processing at an Event Service may arise if the service is instructed to or automatically applies a wrapper format to an event before a
filter is applied to it. If the service does not indicate the exact behavior in this situation, then subscription filters may not work as expected. In cases where the Event Service
implementation uses a wrapper that is only a message container for multiple events, it should apply content based filtering on each of the events contained in the wrapper. The
WS-Notification Notify message represents such a container.
96
Copyright © 2010 Open Geospatial Consortium, Inc.
9.1.3 Resolve Content Given By Reference
The GML model allow values of feature properties to be given by a reference a URL in an xlink:href property rather than inline of the XML instance. The idea is that a system
that receives such an XML instance would automatically resolve the reference to get the value and insert it into the inline content.
An Event Service should automatically retrieve event properties given by reference if they are queried in the filter statements of a subscription. This can happen on demand.
Problems can occur if the value cannot be resolved e.g. if wrong connection timeouts have been chosen or if the value itself is complex and has properties given by reference.
Such deep reference structures can slow down an Event Service.
The effects and possible performance issues of using event properties given by reference in event filtering should be investigated in more detail.
When using xlink references encoded according to the GML specification, data providers that create event instances should be aware that applications receiving the events may not
preserve the namespace-prefix binding for the XPath expression used in the reference.
Consider the following example: xlink:href=http:www.aixm.aeroschema5.1dnotamexample
elementdnotam:Event[gml:identifier=aPreviousId] It shows an xlink with a URI reference that the GML standard OGC 07-036 calls an
element scheme based XPointer
. The absolute URI http:www.aixm.aeroschema5.1dnotamexample is followed by the fragment
identifier and then the XPointer. Although this behavior is not recommended by the W3C, an application that receives an event e.g. an XML router application could
change the prefixes in the attributes and elements of an XML instance but not in the content of them. In the above example, the
dnotam
and
gml
prefix would then no longer bind to the correct namespaces. A service could no longer resolve the correct element
from the given URI. Therefore, it is more safe to use an
xpointer scheme based XPointer
see OGC 07-036 – the example would then look like this:
xlink:href=http:www.aixm.aeroschema5.1dnotamexample xmlnsdnotam=http:www.aixm.aeroschema5.1dnotam
xmlnsgml= http:www.opengis.netgml3.2 xpointerdnotam:Event[gml:identifier=aPreviousId]
Here, the namespace-prefix binding is preserved in the reference itself.
9.1.4 Reference System Transformation
When a filter statement is created to be used in subscriptions, it often includes filter operand values. In simple applications, the reference system of these operands e.g. a
