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] Avoding a repeat of W3C XSD - was Re: [xml-dev] Is Web 2.0

[ Lists Home | Date Index | Thread Index ]

That and a bit of maturity from the professionals.  How often 
do we go into these meetings prepared to skewer a submission 
because of the source?  By example, wasn't the original 
submission for XSD from Microsoft a lot simpler than XSD? 
Wasn't the VML submission a lot simpler than SVG?  

A tough ability to learn is knowing the good thing when we see it, 
rather than trying to find another thing because of the source. 
It's human, but wow, it can create collateral damage.  Wishful 
thinking is at the heart of many a failed business.

I don't expect Mike to answer this because he is now the 
source.  But company submissions ARE extreme specwriting. 

As to *permanent* Extreme committees, I don't like these 
any more than what we have.  The two-year limit might not 
be the solution but it has the desirable feature of a schedule 
with a Due Date.  One can get extensions.  If it takes 
longer than two years given due diligence (ISO is very 
nasty about schedules but forgiving if due diligence 
is provable), maybe it isn't ready for the mill.  What 
I worry about are the self-perpetuating committees that 
find they like each other, want to be together, and keep 
on keeping on past their capacity to produce timely hits. 
After all, it's fun to travel, see one's name in the trades 
and on the covers of the specs, get lecturing gigs, get 
to drink with one's heros, and destroy hotel rooms without 
having to learn new material.

In the music business, they lose their label deal and 
go indie, or form new bands.  Their managers are likely 
already working for the label.


From: Michael Champion [mailto:michaelc.champion@gmail.com]

There has been talk (I can't find a public reference so I won't say
more, maybe Liam can?) of a new type of group that would do more
experimental  "design by committee" work that would result in a
specification or other work product that had no claims to be a
standard.  Presumably a regular working group could then pick up such
a spec, refactor / refine / test  / clarify it and then see it through
to Recommendation status.

Details aside, I think that is one thing that would address some of
the problems noted here, especially Len's long-standing insistence
that "specification" and "standard" be clearly separated in people's

Or to put it differently, "extreme specwriting" is probably going to
be a very useful way to get useful specs written, but there's also the
reality that the whole notion of a "standard" implies a waterfall
process since it is hard to refactor a standard without breaking
applications.  XSD clearly illustrates this -- to go back and fix the
apparent mistakes would create an awful lot of havoc.  Reasonable
people can disagree whether that havoc would be worthwhile to clean up
XSD 1.0, but I don't think anyone disagrees that we really want to
avoid being put in this situation again.


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

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