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] Is Web 2.0 the new XML?

[ Lists Home | Date Index | Thread Index ]

From: Michael Kay [mailto:mike@saxonica.com]

> By participating in some n of successful and 
> failed standards efforts in a knowledge domain 
> in which they are competent. 

>So in each generation we need to create a few unsuccessful standards, in
>order to train the people who will create the successful ones of the

Yes.  That's the cost of continuity.  As best we can, we write down what 
we learn, but it comes with the warning that the past is not always
That for example, is one reason these lists exist.  It helps if the 
leadership does diligent research so they have a good handle on what 
the issues will be.  XML is a good example where the precepts were 
fairly informative even if they fall apart in specific cases (verbosity 
does matter but there are always maps).

Risk is real but manageable.  If it isn't, it isn't worth doing.

>Quite honestly, I don't think any failures of standards that I know of can
>be put down to the incompetence or amateurism of individuals. Teams, yes:
>two highly competent individuals pulling in opposite directions is not a
>good formula. And a match of people to the task: sometimes you want
>thoroughness and sometimes you want it cheap and cheerful. 

It depends on leadership.  If the standard really fails, 
leadership may have to suck it up.  So, one can say that individuals 
do fail, and that training leaders has high value.  Being able to 
pick a team is better than culling unknowns.  That is why I say 
hire professionals when possible.  When forming bands, one can cattle call
players but it is better to hire known pros if the gig 
is understood.  It saves time, conflict, and the gig itself. One 
can conceive of spec writing and standards writing as performance, 
so chops, attitude, and practice matter.  Unfortunately, too often 
we bless the notion that a good standard can come of whoever shows 
up.  It can work but the odds aren't as good.  So again, if someone 
is asking me for a professional piece of work, top flight players 
cost top flight money.  If they want cheap, the weekend warriors 
and the garages are full of willing players.  If they do pay me 
and I fail to put butts in seats, it is my fault.

So as you say, good requirements matter.   If they just want noise 
to fill the space so they can open the club, almost any set of players 
will do.  If they want 'young professionals making three figure salaries 
who like Jagermeister and occasionally purchase cocaine in the back office',

get top jazz musicians with a very foxy front singer, and BTW, I decline. 
I don't believe in poisoning clientele for profit.

>But mostly, it's down to getting the requirements right. ODA and X.400
>delivered all the requirements that people said they needed, and then the
>same people went out and bought something cheaper. The engineers who did
>work were highly competent and professional, it was the companies funding
>them who got it wrong.

The 'who benefits' question is germane.  A standard for a pre-existing 
market should advance that market by promoting quality or interoperability. 
A specification should create a market which might include taking customers 
from an existing market. Someone has to pick the metric of success and that 
is usually the customer.  MP3 has competitors but none are denting it much 
despite the encumbrances of MP3 because the vendor is glad to pay for that. 
Windows wav files rule in the LotsaFidelity formats but the market for the 
devices is much smaller because the distribution is on mass storage.

I think XML succeeded because the W3C with the exception of Dan Connoly 
was clueless about markup and the subset of markup professionals who 
understood hypertext were quite adept.  I advise people who want to 
write specifications to stay under the radar until they have running 
code.  Unfortunately, the lesson promoted is to get all the buy in 
they can before they have even gotten a solid team together.  It's a 
bad plan.  Jam first.  Pick the band.  Then rehearse like mad until 
you are ready to play a gig somewhere away from the target customer. 
Then cull the songlist and go get the money.



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

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