[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: sunshine and standards development
>* Ad-hoc specs that come from a small group, often but > not always with a "major power" sponsor. The interesting thing here is that quite often such "ad-hoc" standards are less "ad-hoc" than what one might think. Typically the small groups is *experienced* in the area of the standard, and so have a great deal of domain expertise. XML is a good example, as are VRML, the DOM and SAX (these latter two to a slightly lesser degree). My main concern with many of the recent "standards", SOAP et al. being among them, is that they are *not* advised by past experience. I would argue that in a number of cases the standards that are being created are worse than they should be because either: a) The space of the standard is so poorly understood in general that without experience in implementation to guide practise (as per IETF) no standardisation should take place. I put almost all XML messaging proposals into this bucket. b) The representation on the standards committee is such that the voices of experience are drowned out. I have seen this happen a number of times, and one form is "vendor pressure", where politics play more of a role than technical/market correctness. >* Pragmatic "let's compromise for the good of the > consumer" specs from industry consortia, or > de-facto standards from a dominant vendor. Quite often, these are "ad-hoc", but biased by experience. >* "Real" standards that rigorously define a > vendor-neutral specification and strict conformance > criteria. As we all know, these are the hardest to develop, and take the longest to develop... simply because the standard has to be complete. One can argue that ISO takes a long time on some things simply because it is *thorough*. > Nevertheless, as long as the W3C serves as the > "treaty organization" within which pragmatic > compromises that result in consensual > Recommendations are made, I don't believe that > more "sunshine" would help. I would argue that in some cases, there is already so much participation that (b) comes about, resulting in large, unclear specifications.
|
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
|