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 (was Re: [CAP-Interop] Congrats / What have welearned?)
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]