[
Lists Home |
Date Index |
Thread Index
]
I delayed answering this publicly for a couple of reasons.
1. It is difficult to sound reasonable while saying on the one hand,
"Yeah I mostly agree with you," then, on the other hand saying, "but
there are reasons why things are the way they are and this is just
about the best we could get at this time." Show me someone who
actually likes saying stuff like that and you can bet I will mostly
try to walk on the other side of the street and in the opposite
direction if I see that person headed my way. So, basically, I just
hate being put in that position. Unfortunately, that's the case.
2. It really irks me to say, "Yeah, well you should have been there
when all of that was being agreed to, and maybe it wouldn't be like
that." True, yes, but mostly spilt milk and yesterday's papers. Bob
didn't get sufficiently involved to affect the course of how this
standard came into being until after the public review period and
didn't actually join the TC until just as the vote went through, so
from now on, hopefully, we can count on him being there to help
improve it.
That said, I was using CAP simply as an example, with which I was
familiar and thus could speak from personal experience, of an OASIS
specification that was subjected to public demonstration and scrutiny
to prove it was actually providing some demonstrable interoperability.
Be it as it may, CAP came to OASIS from a diverse group that was not
primarily a standards body, was in fact a true single-issue
constituency, the Partnership for Public Warning, with a whole
boatload of history, (about two years) and previously developed
concepts, with a substantial public investment of time and energy and
some requirements that were simply too important for those reasons to
be dismissed as not germane to an XML-only standard. Worse, the
necessity to provide "a simple but general format for exchanging
all-hazard emergency alerts and public warnings over all kinds of
networks." to quote from the abstract to the specification, rather
begs the question of strict interpretations or adherence to the
requirements for any specific network. CAP has to work for one-way
broadcast as well as XML Schema in Web-based applications meant for
distribution and exchange over the Internet. No excuse, just the bald
facts. There WERE honest to goodness knock down drag out polite
discussions about most of the issues.
Lastly, who wants to cast the vote the prevents allowing the only
viable, public standard completely uncoupled from partisan politics,
that stands a chance of saving a single life in a time when another
incident such as 9/11 or 3/11 could happen at any time, especially if
that public standard, because it IS public, CAN be amended to do its
job better?
I applaud Bob for joining the work and taking on the unenviable task
of helping to improve this work.
Ciao,
Rex
At 4:40 PM -0500 4/3/04, Bob Wyman wrote:
>Rex Brooks wrote:
>> CAP, for another example, which has not been tested
>> as thoroughly as WSRP, and is not a web service standard
>> although it can be implemented through a web service,
>> had public tests in September at the Global Homeland
>> Security Conference and again March 11, at a Congressional
>> demonstration, the ComCARE-sponsored Intreroperability
>> Now! workshop, holding the demonstration in the Rayburn
>> House Office Building that evening.
> Rex, if I were you, I wouldn't suggest that CAP [1] is an
>example of any thing good in the OASIS standards process. If anything,
>it should be an embarrassment to them. As you know, there are at least
>some (myself among the noisiest) who would say that CAP is one of the
>most poorly and ambiguously defined "standards" to be declared by any
>group in recent history. This standard includes:
> * An invalid XML Schema
> * Factual errors concerning the facilities it provides (i.e.
>it says it provides facilities for encryption and signatures, but does
>not)
> * Contains elements like <language> which are redundant with
>XML's xml:lang
> * Does not clearly identify all of its normative references
> * References out-of-date or obsolete normative documents
> * Departs from normal XML practice in many ways
> * Contains many ambiguously defined elements (like the
>name/value stuff, etc.)
> * Contains elements whose meanings can only be determined by
>processes external the spec itself. (like geocode, etc.)
> * Allows a range of date formats which is so broad that it is
>effectively not a definition at all. i.e. any of the gazillion formats
>provided by ISO8601 are "supported" by CAP.
> I could go on...
> Also, at least one of the three "Certifications" of
>"successful use" provided for CAP prior to voting was actually a third
>party report! i.e. The USGS certification makes reference to the CA
>EDIS group successfully using CAP but says nothing about USGS using it
>nor if USGS was a principle in the EDIS work.
> I contend now, as I have before, that I do not believe that
>any substantive interoperabilty could result from two independent
>development groups creating implementations without a great deal of
>inter-group discussion between the two.
> CAP is an exceptionally poorly written standard that could
>only have been passed by an organization like OASIS with very soft
>acceptance criteria. CAP wouldn't have stood a chance of acceptance by
>the IETF, ISO, W3C or most other standards groups. It is saddening and
>embarrassing that a standard which is as important as this one might
>be (it involves life-and-death situations) should be getting such
>shoddy treatment.
>
> bob wyman
>
>[1]
>http://www.oasis-open.org/committees/download.php/5666/emergency-CAP-1
>..0.pdf
>
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request
|
