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] Competing Specifications - A Good or Bad Thing?

[ Lists Home | Date Index | Thread Index ]

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 piss 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 (pissing 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.


From: Michael Champion [mailto:mc@xegesis.org]

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.


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

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