[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]