Re: [emergency] CAP-related Comments

[emtc@nc.rr.com]

Great work Walid - thanx for pulling these together.

TC: at this point, its time for our next decision. We have to decide on whether or not to address this information now or after the Public Comment. Doesn't mean that 100% has to be addressed now - just a decision on whether to edit the current doc now or to wait until Public Comment. If not, then we send to OASIS. If there is a need to edit now (or after the Public Comment for that matter), we will need to look at each of these items and determine what to do with them. We can basically decide to amend the spec, reject the comment, debate the comment, or postpone the comment (for a future spec version consideration for instance). There are some variations, but you get the idea.

At this time consider the list open to general comments on these issues and how to proceed. We will do this until EOD next Tuesday, at which time I will create a voting ballot on whether to edit or not before we send to OASIS.

Allen

----- Original Message -----
From: Walid Ramadan <WRamadan@blue292.com>
Date: Tuesday, October 14, 2003 3:16 pm
Subject: [emergency] CAP-related Comments

> 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' 
> memberson 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 
> couldbe 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 
> thatis to be written per our charter. It is necessary to help 
> implementersunderstand 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 
> includedto 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 
> beenargued that doing so could create a barrier to adoption in 
> existingsystems 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 
> separatesolution would have to be designed if multiple 
> representation formats
> are permitted.
> 
> [TRANSFORMATIONS]--------------------------------------------------
> --
> 6. Protocol is too vague to allow for automated mapping of CAP 
> messagesinto other, existing systems. How to address the issue of 
> automaticallytranslating 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 
> withthe 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 
> standardand 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 
> ideaof 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 
> languagecodes 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 
> specsas 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 
> potentiallyhave 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? 
> Documentshould 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 
> understandthat 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_workgroup.php.
>