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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] WS-Emperor naked?

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


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
>	* 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
>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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS