MHonArc v2.5.0b2 -->
emergency-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: Message coding
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]