Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Competing Specifications - A Good or Bad Thing?
 It's just management. Provide a rule/policy that discriminates project deliverables and their processes by project type. If a project is producing a specification, that has different processes and deliverables than a standard. Prior to the W3C-engendered perceptions of 'standards', this was well-understood in the engineering world. As-built vs as-designed, design notes vs product documentation, etc. are part of any reasonably sized engineering corporation's design methods. It all looks like YAGNI to someone itching to code, but for very large systems development, it is very necessary. The W3C correctly labels what it produces as specifications and that is indeed where it does its best work. It does nothing to correct the mythInformation in the press or here that it is a standards organization, something it would do, if it did it, badly. IP is now a top concern because some systems within the ecosystem decided that the cost of software should ideally be zero. Other parts of the ecosystem looked for other ways to recoup their energy budgets and IP is a way to do that. Emmninently predictable. We're managing a world we made even if unintentionally. That doesn't mean it is in a fixed form. Quite the opposite. If we manage it better, it will evolve into better and perhaps higher forms. If we keep using myths to make decisions, it will devolve into competing camps for every decision and every opportunity. Thus, it becomes a pack of dogs where the only reliable rule is force and what we [expletive deleted] on. Rule of thumb: if a consortium announces a project to develop a standard and the sign-up list doesn't include at least two to three recognized vendors for products of the kind that is to be the output/deliverable, the consortium is just marking territory ([expletive deleted] on it). If after a year of reportable work, a working product has not been produced, they are dogs jealously guarding a bone. A specification, on the other hand, has a research phase that can alter the evolution of the product dramatically, but if steady progress is not shown, they are just digging holes to bury the bones in so other dogs won't benefit from their work. len From: Michael Champion [mailto:mc@x...] Well, the W3C flourished in the ecosystem of the 1990's when there was a lot of intellectual capital floating around and the trick was to figure out how to extract the common ideas and expose them in a standardized way. Now the trick is to take this to the next level without having the ideas spend 20 years wandering around academia accumulating value by accretion and selection. I completely agree that the W3C process is demonstrably not up to that task, but I don't agree that its former reputation is based on myth. I'm not sure whether the way forward is by figuring out how to make design by committee actually work (and be allowed to fail, and forced to prove itself) so that software gets written and standards can advance in a short timeframe, or to abandon all hope and come back in 20 years or whenever there are enough good ideas that need to be standardized rather than forced to learn to survive in the wild. 
|
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
|
|||||||||
