Re: [emergency-msg] Re: Message coding

["R. Allen Wyke" <emtc@nc.rr.com>]

On Fri, 2003-10-03 at 19:13, Art Botterell wrote:
> I absolutely agree, Allen... we can improve.  I think that's what 
> we're all trying to do.   That's why specific, actionable suggestions 
> are so important.
> 
> At the same time, I think we also understand that we could wait 
> forever trying to achieve perfection... and still not get there, 
> because a lot of what we need to learn we'll learn only by 
> experience... as illustrated by Jeff's notes based on his real-world 
> implementation work.
> 
> Anyway... Allen has invited us to transfer our conversation about the 
> CAP message format onto the open 
> "emergency-msg-comments@lists.oasis-open.org" list.  Allen, can you 
> please brief the non-OASIS members among us on how to join that list?

Absolutely - I would love to. Quoting directly from the TC Process on
the OASIS site (http://www.oasis-open.org/committees/process.php):

"The purpose of the TC's public comment facility is to receive comments
from the public and is not for public discussion. Comments will be
publicly archived, and will be forwarded to one or more TC members
including the TC chair. TCs shall not be required to respond to
comments."

In a nutshell, this means the TC has a formal process and method to take
comments from non-members, such as those circulating on this list. You
can either submit a comment by sending it to
emergency-comment@lists.oasis-open.org, or you can click the "Send A
Comment" button on the EM TC page located at the following URL:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency

Those who have participated in the demo in DC have some incredibly
valuable lesson's learned from your experience, and sending this
information back into the TC is a way for us, as a group, to address
those comments and improve the standard before its final approval.

We look forward to hearing your comments - Allen

> Thanks!
> 
> - Art
> 
> 
> At 5:42 PM -0400 10/3/03, R. Allen Wyke wrote:
> >I *think* I can help here. Jeff, please correct me if I am wrong on my
> >assumptions of what you are asking.
> >
> >I think what you are bringing up is that there are 1,000 different ways
> >to technically do this - we all agree there, but that is not the real
> >root of the issue. The issue is, what is the "right" way to do it? More
> >specifically, what, from a standards perspective, is the correct way to
> >process and therefore support CAP messages? That is what developers what
> >to know, and it is something the spec should avoid ambiguity on and
> >around.
> >
> >>From a standards (MSG SC) perspective, the focus is on how to answer
> >Jeff's question, but also have it apply to the widest target audience
> >possible. How do we address not only Jeff's scenario, but also Frank,
> >Tom, Sarah, and Bob's?
> >
> >The take away from these comments is that we need to add some
> >clarifications to CAP. These can come in the form of normative or even
> >non-normative additions to the spec, or perhaps to supporting documents
> >(like the guidelines, or maybe a "CAP for Oneway Systems" or "CAP for
> >Web Services" or "CAP for Subscription-Based Processing" or...you get
> >the idea).
> >
> >Think of it this way. If the entire TC was hit by a bus, is there enough
> >information in the CAP spec to tell target implementors how to implement
> >the standard and share CAP alerts? Based on these comments (they are
> >GREAT btw!!!), I think we can improve here.
> >
> >Allen
> >
> >On Fri, 2003-10-03 at 17:27, Art Botterell wrote:
> >>  At 3:42 PM -0500 10/3/03, Jeff Kyser wrote:
> >>  >And even saying you must use at least one of:
> >>  >	FIPS/SAME
> >>  >	ZIP CODE
> >>  >	polygon
> >>  >	circle
> >>  >would give most/all of us the opportunity to parse a CAP message in
> >>  >a predictable way.
> >>
> >>  Since that would involve implementing some IF-logic anyway, would it
> >>  be hard to simply treat an <area> with no geospatial or geocode
> >>  elements as equivalent to no <area> at all?
> >>
> >>  It's generally true that different receivers will have different
> >>  capabilities, so if a sender has a broad audience in mind it's in the
> >>  sender's interest to provide as much detail as possible.  What we've
> >>  hesitated to do is prevent senders from sharing what information they
> >>  have, just because they don't have as much as we'd like.
> >>
> >>  Currently we permit the inclusion of an <area> block with only an
> >>  <areaDesc> inside.  That's to ensure support for captioning and
> >>  text-to-audio applications and to cover cases where the description
> >>  is something like "downtown St. Louis" and the sender doesn't have
> >>  GIS or geocode data readily available.
> >>
> >>  One reason for the <geocode> element was to permit the inclusion of
> >>  one or more system-specific alerting zone codes.  If we required that
> >>  the <geocode> had to be a FIPS code, a SAME code (they aren't exactly
> >>  the same, as you know) or a ZIP code, that would preclude including
> >>  system-specific codes.  Would that be appropriate from your point of
> >>  view?
> >>
> >>  Honest, Jeff, I'm not trying to bust your toes.  I'm just trying to
> >>  understand your concerns clearly, and to share with you some of the
> >>  concerns that have come up in the past, so what we carry back to the
> >  > formal process can be as useful and effective as possible.
> >>
> >>  - Art
> >>  _______________________________________________
> >  > CAP-Interop mailing list
> >>  CAP-Interop@lists.incident.com
> >>  http://www.incident.com/mailman/listinfo/cap-interop
> >>  This is a discussion list for people involved in testing and 
> >>evaluating interoperability of applications using the Common 
> >>Alerting Protocol (CAP).
> >--
> >R. Allen Wyke
> >Chair, Emergency Management TC
> >emtc@nc.rr.com
> >http://www.oasis-open.org/committees/emergency
> >
> >
> >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-msg/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-msg/members/leave_workgroup.php.
-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency