Copyright © 2010 Open Geospatial Consortium, Inc.
119 The following XML-Schema fragment shows the declaration of the
cap:area
element which allows CAP messages to be tagged with location.
Listing 5: Extract of CAP XML Schema showing location support
element name = area minOccurs = 0 maxOccurs = unbounded complexType
sequence element name = areaDesc type = string
element name = polygon type = string minOccurs = 0 maxOccurs = unbounded element name = circle type = string minOccurs = 0 maxOccurs = unbounded
element name = geocode minOccurs = 0 maxOccurs = unbounded complexType
sequence element ref = cap:valueName
element ref = cap:value sequence
complexType element
element name = altitude type = string minOccurs = 0 element name = ceiling type = string minOccurs = 0
sequence complexType
Location is expressed textually using the
cap:areaDesc
element and can be expressed geometrically or using a geo-code such as a postal code. The standard states that
geometric tagging is the preferred method. Unfortunately, the geometric tagging is done using a non-standard encoding forcing a conversion to and from a standard encoding like
GML.
12.2.9.4 Code lists
The CAP standard defines a number of lists of values for parameters in the model. Here are a couple of examples:
element name = category maxOccurs = unbounded simpleType
restriction base = string enumeration value = Geo
enumeration value = Met enumeration value = Safety
enumeration value = Security enumeration value = Rescue
enumeration value = Fire enumeration value = Health
enumeration value = Env enumeration value = Transport
enumeration value = Infra enumeration value = CBRNE
enumeration value = Other restriction
simpleType element
element name=responseType minOccurs=0 maxOccurs=unbounded simpleType
restriction base=string enumeration value=Shelter
enumeration value=Evacuate enumeration value=Prepare
enumeration value=Execute enumeration value=Monitor
enumeration value=None restriction
simpleType element
120
Copyright © 2010 Open Geospatial Consortium, Inc.
These lists of values are hard-coded into the schema significantly reducing the extensibility of the model. Also, the particular vocabulary used is focused on emergency
management which is fine if that is the intended context within which the notification messages are being used. Otherwise, the enumeration value
Other
tends to be used a lot significantly diminishing the usefulness of a parameter like
category
. This was certainly the case when CAP was used in the GSS experiment.
A better approach would have been to use code lists similar to the approach used in GML with the
gml:CodeType
type. This allows lists of values to be dynamically referenced allowing the vocabulary to be adjusted to fit the particular context. Also, from the point
of view of implementing a generic CAP client, code lists allow such clients to read these lists and generate lists at run-time thus adjusting the client to the context.
12.2.9.5 Resource references
The CAP message format defines the
cap:resource
element which may be used to embed or reference resources related to the notification. This was intended to allow references to
images, audio andor video content but was used effectively during the GSS experiment to reference, for example, modified features. The element could also contain a more
detailed representation of the event that the CAP alert summarizes information of.
12.2.9.6 Other features
The following list describes features of CAP that are anticipated to be useful in a general eventing environment but which were not exercised by the GSS during the OWS7 test
bed:
Multilingual support - alert messages can include the same information in multiple languages
Multi-audience support - alert messages can be targeted to multiple audiences Message management - the protocol defines procedures for updating and
canceling previously issued alerts Time - alert messages include onset and expiry times which allow for phased of
delayed alerts to be signaled
12.2.9.7 Interoperability
Interoperability with respect to different ways of encoding notifications can be achieved by using a gateway that provides uniform access to various notification technologies - the
Web Notification Service OGC best practice could become such a gateway right now it is limited, unfortunately. The gateway can then tie into emergency alert middleware that
uses CAP to route alert messages to recipients.
