[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] CAP-related Comments
No objections here. Rick ----- Original Message ----- From: <emtc@nc.rr.com> To: "CONSULTRAC" <rcarlton@consultrac.com> Cc: <emergency@lists.oasis-open.org> Sent: Friday, October 17, 2003 9:22 AM Subject: Re: [emergency] CAP-related Comments > 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]