Re: Message coding

[Art Botterell <acb@incident.com>]

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?

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.