Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: WS-Emperor naked?
 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@s... Tel: 510-849-2309 Fax: By Request 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
