MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] Unique Message Identifiers in CAP
Still going through my emails. Some things I want to address as it
pertains to a public comment on CAP and the thoughts I shared about
such a topic.
On Mar 23, 2004, at 8:21 PM, Art Botterell wrote:
> At 10:08 AM -0500 3/23/04, R. Allen Wyke wrote:
>> We seem to take the "vote on it and move on" rather than "address the
>> issue, which may mean a vote" approach, which as Chair concerns me.
>> It is a train wreck waiting to happen.
>
> Allen, if there's been a lack of breadth and depth in our discussion
> of specific issues... and in some areas there has been... then that's
> something you, as Chair, need not only to decry but also to take some
> responsibility for. I very much regret that most of the input I've
> heard from you over the past half-a-year seems to been of the "we're
> going too fast" or "that won't work" or "we're on the road to hell"
> variety. I'm afraid that negativity has taken a toll both on the TC's
> membership and on its productivity.
I have provided countless examples (the "email" example at the first
f2f was just one of many) to support what I am saying. The public
comments, such as this one, coming in support what I was saying. With
all due respect, there is a dimension to building systems that support
standards, and therefore building standards that can be supported, that
not everyone has experience with nor are they expected to. While you
may not have understood the arguments and support information, they did
exist, and just as I respect the domain expertise you bring, it is
important that we all respect (even if we do not understand it) what
other's bring - because there are smart people in this group.
> Ultimately the question is "who needs to be satisfied, and what do
> they consider satisfactory?" To my mind, the only meaningful owners
> of CAP are the folks who actually use it. Allen, has your firm
> invested the effort, as many others have, to actually implement and
> deploy a CAP application outside its own office and in active
> connection with multiple other implementers?
An interface is built, however it is impossible to connect with other
systems in a standard (official) way as that means of connection has
not been defined. Sure, I can pick up a phone and talk to E Team, DMIS,
or anyone else and we can hash it out offline, but that is not
standards-based interoperability, which is part of the charter of this
TC - that is a one off proprietary use of a spec. And that is just a
comment about the exchange of the data, and has nothing to do with the
fact that the ambiguity in CAP leads to different ways to convey the
actual alert information (ie: like having multiple <info> blocks - is
that 1 "alert", or many? What are their relationships to each other?
etc.).
> If not, then I'm not sure why we should consider satisfying your
> personal opinion of what constitutes "addressing the issue" to be our
> chief goal. (And if so, then why not back up your various concerns
> with some specific evidence from that specific effort so we can craft
> specific solutions?)
>
> Our priority needs to be to field a basic standard quickly, build
> positive awareness of it in the user community, and then to pay
> attention to the folks who've actually rolled up their sleeves and
> applied it as we decide what can be refined. Otherwise we're just
> spinning our wheels in a pool of our own anxieties.
That is actually NOT how you build standards. Well, I will slightly
contract that statement and say that you can, if you want, but it means
that you will be 2 or 3 versions down the line before it is remotely
well baked. You do not through a "beta" standard out there with the
purpose of completing it, because people will simply say, "I will wait
until they have something that really works - v2 or v3". Your ethical
responsibility as a standards developer is to put a usable standard out
there for people to implement, and then seek to improve it.
Allen
--
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]