OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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]