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