Filtering CAP messages Common Alert Protocol

Copyright © 2010 Open Geospatial Consortium, Inc. 123 Filtering on referenced values presents more of a challenge. Filtering on referenced values is not a function of FES but of the service within which FES is embedded – see section 9.1.3. If the service is capable of resolving referenced values then filtering is possible. Perhaps the best analogy to use here is the Web Feature Service 2.0 implementation specification. The WFS 2.0 standard defines a set of request parameters called the Standard Resolve Parameters. The following XML Schema fragment from the WFS 2.0 schemas defines these parameters: xsd:attributeGroup name=StandardResolveParameters xsd:attribute name=resolve type=wfs:ResolveValueType default=none xsd:attribute name=resolveDepth type=wfs:positiveIntegerWithStar default= xsd:attribute name=resolveTimeout type=xsd:positiveInteger default=300 xsd:attributeGroup xsd:simpleType name=ResolveValueType xsd:restriction base=xsd:string xsd:enumeration value=local xsd:enumeration value=remote xsd:enumeration value=all xsd:enumeration value=none xsd:restriction xsd:simpleType xsd:simpleType name=positiveIntegerWithStar xsd:union memberTypes=xsd:positiveInteger wfs:StarStringType xsd:simpleType xsd:simpleType name=StarStringType xsd:restriction base=xsd:string xsd:enumeration value= xsd:restriction xsd:simpleType The resolve parameters appear on requests and direct the service how to handle referenced values. The resolve parameter tells the service which referenced values to resolve; local, remote, all or none. The resolveDepth and resolveTimeout parameters control the number of nested levels to which referenced values should be resolved and how long to wait to resolve a remote value reference. When processing a predicate and the service encounters a remote value reference, it uses these parameters to control how it resolves that reference in order to obtain a value to test in the predicate. If the resolution is successful and a testable value is obtained, filter processing continues as normal. If value resolution fails, then filter processing fails and an exception is raised.

12.2.9.10 EDXL-DE

EDXL-DE Emergency Data Exchange Language Distribution Element was not used in the GSS experiment and so it is discussed only briefly here. The purpose of EDXL-DE is to facilitate the routing of any XML emergency message to recipients. An EDXL-DE message may be thought of as a container. An EDXL-DE message provides the information to route payload message sets such as Alerts or Resource Messages, by including key routing information such as distribution type, geography, incident, and senderrecipient IDs. 124 Copyright © 2010 Open Geospatial Consortium, Inc. The relationship between EDXL-DE and CAP is similar to the relationship between SOAP and WFS. Like a WFS message that is embedded within the body of a SOAP