CAP-related Comments

["Walid Ramadan" <WRamadan@blue292.com>]

CAP-RELATED COMMENTS
AS OF 10/13/2003

All:

The following is a list of comments/issues that I compiled from a
variety of sources. For the most part, comments were collected from
these sources:

* Review of the OASIS CAP-Interop monthly archives at
* Comments that I received directly from TC and Sub-Committees' members
on or before 10/13/2003.
* EM TC comments after the internal "format" (or "intent") test.

As I went through these comments it became apparent that they could be
triaged into several buckets. These buckets are the following:

a) Geospatial-Related (Issues 1 through 5): Questions and comments
around how CAP supports geospatial information. The result of this could
be anything from adding geo-specific "References" or maybe a section on
"How to Use Geospatial Data". 

b) Transformations (Issues 6 and 7): Questions and comments around how
to map/transform CAP into other formats, like other XML standards,
text-to-speech, ASN-1, etc. While this is mostly for backwards
compatibility with existing applications, standards, products, services,
etc., it can also be hugely beneficial for the future as well. Some
influence should be considered from issues 9 and 28 as well. 

c) Transport (Issues 8 through 11): Questions and comments around how to
properly exchange CAP messages. This is where the inline binary, Web
Service, encryption, authentication, etc. stuff falls into place. Need
to decide if this should be part of the existing specification (means we
have to go back to Working Draft), or should it be addressed in a
separate document that focused just on transport (current focus of TC).
Some influence should be considered from issues 14, 15, and 28 as well. 

d) System-Specific Uses (Issue 12): Questions and comments around how
system specific things should be communicated within CAP. For instance,
where it is "safe" to return a system-specific error code that is not
standard across all uses of CAP?

e) Implementer's Guide (Issues 13 through 15): These are things that
seem to be most appropriately addressed in the Implementer's Guide that
is to be written per our charter. It is necessary to help implementers
understand how to support CAP and use it in various environments. Some
influence should be considered from issues 9, 10, and 28 as well. 

f) Unsure (Issues 16 through 21): This is a collection of issues that
require discussion to determine their relevance for inclusion in the CAP
standard 

g) Editorial and Ambiguity (Issues 22 through 28): These are places
where the spec just doesn't seem to be clear on what the TC intents.
Also, places where there could be some editorial clarification that
doesn't change the spec.

Here are the details of these buckets.

[GEOSPATIAL]----------------------------------------------------
1. How to treat an <area> with no geospatial or <geocode> elements in a
CAP message? How best to define <geocode>? Should <geocode> be limited
to FIPS, SAME, and zip code?

2. Spec Document is silent on the format of polygons coordinate pairs:
should it be in long/lat order or lat/long? 

3. Geographic targeting codes: The <geocode> element, which was included
to provide backward compatibility with existing systems (notably EAS and
NOAA Weather Radio, but also many local systems) also adds a bit of
complexity. It seems possible that in an ideal world all areas would be
in pure geospatial terms (<polygon> and <circle>) but that may be a leap
too far ahead of the current state of the art to allow update of the
standard. In the meantime, one suggestion has been to restrict the use
of <geocode> to certain well-known coding schemes... although it's been
argued that doing so could create a barrier to adoption in existing
systems that use their own predefined alerting or response zones. 

4. How to cover cases where the sender doesn't have GIS or <geocode>
data readily available? 

5. The interface spec will have to declare what representation format it
wants for values in degrees. If it wants geographic data supplied in
decimal degrees, then it should state that; if it wants it
<sign>DD.MMmmm, then it should make that clear. Alternatively a separate
solution would have to be designed if multiple representation formats
are permitted.

[TRANSFORMATIONS]----------------------------------------------------
6. Protocol is too vague to allow for automated mapping of CAP messages
into other, existing systems. How to address the issue of automatically
translating a CAP interface in the case of specialized pre-existing
alerting and warning systems?

7. How to support captioning and text-to-audio applications?

[TRANSPORT]----------------------------------------------------
8. How to reconcile characteristics of a certain transport network with
the capabilities of interoperability standards such as CAP? A much more
intelligent architecture than currently provided for routing is
necessary.

9. Compatibility with existing systems. 

10. Application of CAP in broadcasting (one-way communication medium).
CAP must state exactly how one-way communication media should embed URI
referenced data within the alert message. Current CAP specs rely on the
ability of the receiving device to retrieve binary content, which is
impossible over a one-way broadcast link. Proposed solution is to
provide an explicit optional mechanism for including binary content
encoded as text within CAP XML message, accompanied by restrictions on
when that option should be used. 

11. From a standards perspective, what is the correct way to process and
therefore support CAP messages? Is there enough information in the CAP
specifications to tell target implementers how to implement the standard
and share CAP alerts?

[SYSTEM-SPECIFIC
USES]----------------------------------------------------
12. Addition of fields to CAP in order to allow the receiving device to
generate an EAS activation based on a CAP message. 

[IMPLEMENTER'S
GUIDE]----------------------------------------------------
13. Categorization of threats: The SC having tried unsuccessfully to
locate or devise a taxonomy for threats which satisfied them as being
both broad enough and specific enough to be useful in automated
processing in all-hazards applications, the current committee draft has
the <event> element as optional. Some implementers have expressed a
desire for a reliable (i.e., required) way to categorize messages
according to threat. 

14. How to support attachments (audio files, images, etc.)? Must the CAP
message always be in a SOAP message to transmit attachments? Current CAP
spec offers no specifications as to how binary representations of rich
presentation media can be transmitted over broadcast media.

15. CAP Alert content and the RSS feed format. More generally, the idea
of getting a "short list" of alerts to see before requesting the whole
alert.
 
[UNSURE]----------------------------------------------------
16. Categorization of responses: The committee draft doesn't attempt to
encode responses into categories, but some implementers have expressed a
desire to be able to automatically slot the recommended response
<instruction> into one or more machine-readable (i.e., coded)
categories. Should this be part of the current CAP or future versions?

17. ISO code royalty: The current spec provides for use of ISO language
codes to identify multilingual versions. ISO has recently asserted an
interest in collecting royalties for use of those codes (among
others)... this is a subject of debate internationally
(http://xml.coverpages.org/ni2003-09-20-a.html). Unless this issue is
resolved very shortly, some disclosure of this issue probably needs to
be included in the specification document. 

18. Name attributes in schema: Anonymous data types seem to cause
troubles with some parsers. It's been suggested that the schema ought to
provide explicit name attributes in <simpleType> declarations. Related
to the same question, should these attributes be declared globally
rather than locally? Looking at the items, they could certainly be
reused in other parts of the spec, and could be imported to other specs
as well. 

19. The existing CAP spec is not really a protocol - it is a format. It
should really be referred to as Common Alerting Format, and potentially
have a sibling standard called Common Alerting Transport - together they
create the Common Alerting Protocol.

20. Units of Measurement: The OCG has a document (based on ISO) that
provides an XML schema for expressing UoM in a consistent and easily
interpretable (processing) manner. The CAP group might consider using
this OGC recommendation. 

21. "area" Element and Sub-elements: As with Info element and Resource
element, it would be nice to have an optional slot for a URL/URI (such
as to an http request - like an OGC WMS request or a repository of
additional spatial information). What is the purpose of the additional
spatial information?

[EDITORIAL and
AMBIGUITY]----------------------------------------------------
22. Having multiple blocks within a single message as opposed to
different messages with single blocks in multiple messages and its
relation to the "rule of primacy."

23. Improvements can be made to the general schema design. For example,
there is no common format describing "altitude". If such a format is
available, we should define the schema (using the <restriction> and
<pattern> elements) to support it. "string" leaves it wide open.

24. Use Cases and Examples: They should be in the same section of the
document. More importantly, the examples do not speak to the use cases
listed.

25. Editorial comments: The Data Dictionary section does not provide for
SHOULD, MAY, MUST guidelines for implementers, which causes ambiguity.
"eventCode" is a good example.

26. CAP makes heavy use of the word "warning", which seems odd given it
is the Common Alerting Protocol. Should it say alerting instead? What is
the difference between an alert, a warning, and a notification? Document
should be consistent in the use of these terms. Document should also
define those terms in order to clarify their use. 

27. elementFormDefault = "qualified". Document should mention why.

28. Should CAP be a public warning protocol only or also be used for
targeting messages between entities? In the latter case, what fields
should be designated mandatory in order for the recipients to understand
that the messages was/was not intended for them? The use of text fields
and fields designated as optional represent limiting factors.

Walid