RE: [emergency] CAP-related Comments

[Art Botterell <acb@incident.com>]

Walid -

I know you're doing your best... and that you're also aware of the 
discussion that followed Jeff's initial post that you cite, in the 
course of which he clarified his concerns considerably from that very 
broad initial statement.

Those concerns turned out to be, primarily, about how restrictive the 
options for geospatial descriptions ought to be, and secondarily, 
whether the event descriptions and instructions could also be coded 
more strictly.  Those specific questions appear separately in your 
list.

For the benefit of other TC members who couldn't participate in the 
demo in DC, the archive of the demo team's working email is visible 
at <http://www.incident.com/pipermail/cap-interop/>.  I'll undertake 
to keep that archive online for reference at least 'till we're done 
with this round of deliberations.

- Art



At 6:21 PM -0400 10/15/03, Walid Ramadan wrote:
>Art:
>
>I was simply reading the archived emails and pulling out what sounded
>like a comment.  For example, the statement " Protocol is too vague to
>allow for automated mapping of CAP messages into other, existing
>systems" comes from the CAP Interop mailing list archives.  It is from
>Jeff Kyser, Sept 29, 2003 in response to your request for lessons
>learned following the demonstration.
>http://www.incident.com/pipermail/cap-interop/2003-September/00105.html
>
>I could not tell from the emails whether this issue was resolved or not,
>so I felt compelled to capture it as a topic for discussion.
>
>Walid
>
>-----Original Message-----
>From: Art Botterell [mailto:acb@incident.com]
>Sent: Tuesday, October 14, 2003 8:15 PM
>To: emergency@lists.oasis-open.org
>Subject: Re: [emergency] CAP-related Comments
>
>
>Walid -
>
>Thanks for all the work you've invested in this.  Some of what you've
>collected are issues that have been identified and discussed and
>found to have two or more sides among which the TC may decide... but
>a few seem to be just last-minute assertions of somebody's personal
>opinion, without evidence and without constructive proposals for
>improvement.
>
>E.g., item 6: "Protocol is too vague to allow for automated mapping
>of CAP messages into other, existing systems."  That's a broad claim
>for which no evidence is offered... in fact,  exercises like Eliot's
>GML mappings and the recent CAP tests seem to call it into
>question... and anyway, no constructive suggestion has been offered,
>so what are we supposed to do about it?
>
>Unless some sort of objective criterion can be derived from the
>documented requirements and use-cases for this project... and in the
>absence of concrete proposals for improvement... I'm not sure how we
>can engage such a claim as #6 or a number of the others in any
>rational or constructive way.
>
>Anyway, I thought our goal here was to smooth a few remaining rough
>edges, not to trash all the hard work we've done so far... and
>certainly not to throw roadblocks in the way of meeting the goals
>we've set ourselves.  So it seems like the TC's next task will have
>to be to decide which of these items we can profitably engage at this
>late date.
>
>- Art
>
>
>At 3:16 PM -0400 10/14/03, Walid Ramadan wrote:
>>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
>>
>>
>>To unsubscribe from this mailing list (and be removed from the
>>roster of the OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_wo
>rkgroup.php.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_wor
>kgroup.php.