[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] CAP-related Comments
Hi Folks, Having been privy to the discussions on ICS 201, which overlapped some of Walid's CAP items list, and now having read Carl's and Art's responses to Walid's list, and considering that we have conducted two kinds of tests, I believe we have fulfilled the measures under which we voted to recommend CAP as a Committee Specification. In fact we have well and truly exceeded OASIS TC process guidance in doing such tests. I don't think we need another vote on record. To be honest, there are areas where I am sure we could tighten, tweak, and refine CAP, but we would still be facing a 30-public comment period, so beyond mentioning that an Implementation Guide is forthcoming, and adding a couple of explanatory statements such as Carl has suggested, I think we should proceed. On the lat/long issue, I think punting at this point makes more sense. Noting that referenced specs should be followed according to the current practice pending comment on the candidate Committee Specification should be sufficient. I say this because we are bound to discover more issues during the 30-day public comment period, and CAP will not actually become a an official Committee Specification until we have a vote after after we have dealt with each of the public comment issues as a whole TC. Some of what has turned up in Walid's list may need to be dealt with in this process, so we are not abandoning or ignoring any currently unresolved issues. Once the 30-day public comment period has passed, then we deal with each of the issues that have turned up to a resolution, voting on these item by item if needs be. Since I know how rigorous this process needs to be, believe me when I say that we will have thoroughly gone over everything, probably twice or three times as we go through the issues after the first round of public comment is done. We can't know what it will look like then, no matter how satisfied or dissatisfied any of us are now. And the same would apply if we tried to anticipate all possible known or hypothetical contradicitons, exceptions, misstatements, misunderstandings, etc. Like any battle plan, it won't last past the first engagement. So I think we should go for it rather than wait, and, as I said, we have already voted up on Committee Spec status with minor revisions, which is what we have right now. That's my $.02. Ciao, Rex At 12:53 AM -0400 10/15/03, emtc@nc.rr.com wrote: >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. >> > > >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. -- Rex Brooks GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth W3Address: http://www.starbourne.com Email: rexb@starbourne.com Tel: 510-849-2309 Fax: By Request
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]