[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] CAP-related Comments
I certainly agree. It's been more than two months since the TC adopted the draft... and we won't start getting the full benefit of public comment, beyond what's already come in, until we put the approved draft out there. - Art At 12:22 PM -0400 10/17/03, emtc@nc.rr.com wrote: >I agree as well. I would even go so far as to suggest we do not >tweak it at all, and send as-is. That prevents us from having to >revote on even a slightly edited version. Unless there are any >objections, we can make a final decision on Tuesday. > >----- Original Message ----- >From: CONSULTRAC <rcarlton@consultrac.com> >Date: Thursday, October 16, 2003 3:16 am >Subject: Re: [emergency] CAP-related Comments > >> After consideration, I agree with Rex's process suggestions. >> >> Rick >> ----- Original Message ----- >> From: "Rex Brooks" <rexb@starbourne.com> >> To: <emtc@nc.rr.com>; "Walid Ramadan" <WRamadan@blue292.com> >> Cc: <emergency@lists.oasis-open.org> >> Sent: Wednesday, October 15, 2003 9:09 PM >> 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 >> > >> > 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. >> > > >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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]