W3C process (was: Re: Weighing in on XSL / Standards)

[Chris Lilley]

Just clearing up what seems to be a side issue, about how W3C works.

"Joshua E. Smith" wrote:

> - The W3C seems a little schizophrenic in their treatment of what is worthy
> of standardization.  There is the IETF model: take a collection of working
> solutions, resolve the differences, and standardize the results. 

Which is fine if these are minor differences on the eratta and
clarification level; in other words, if folks were already pretty much
working to the same spec, but the spec wasn't written down, so you
reverse engineer the running code to find out what the spec was.

>  There is
> the US Dept of Defense model: invent a brand new thing, declare it a
> standard, mandate it's use, then implement it. 

Thats also the ISO model, often (and the ANSI, BSI, DIN etc model).
However, its not the model that W3C uses.

> XML is an example of the
> IETF model: they took a good, working, thing (SGML) and tidied it up.

Sort of. The XML WG actually did a substantial amount of work, which
took up the time of a fair number of very bright people. In other words,
they invented something. Yes, it was based on something pre-existing.

> ECMA-Script is another good example of the IETF model.  From my viewpoint,
> XSL looks like an example of the USDoD approach.  Am I missing some history
> here? 

Yes, I think you are.

Concurrent prototyping is a key feature of W3C work. We do open source
stuff, we do little student projects, we encourage others in the
development community to do trial implementation and experiment with
things.

There is a saying: technology gets invented, implemented, depended upon,
obseleted, and standardised - in that order.

Which is why W3C doesn't work like typical standards organisations.

We don't (in spite of what you may have read in the press) just
"endorse" stuff. We design stuff, and have it implemented, and get key
industry players to contribute to making it and ensuring that it meets
their needs - and then , when the spec is good enough it becomes a
proposed recommendation. This typically takes about a year. One of the
questions that is asked before putting a proposed recommendation to the
360+ members of W3C for review is, "what is the level of implementation
support".

> When a detractor can say, with a straight face, that he doubts the
> standard can actually be implemented, that's usually a sign that the
> standard is *way* out in front of the community, and needs more baking.

Yes.

Of course, there are already a buncjh of implementations of the
transformation part, XSLT, and there are two announced initial
implementations of parts of the FO part.

> I lived in the USDoD standards world for a long, long time, and I know that
> their process is completely incapable of producing anything with any value
> whatsoever.  I have also dabbled in the IETF standards world, and have been
> uniformly impressed at how their process lets the cream rise to the top.
> Since the W3C is all about the Internet, why does it have a process
> separate from that of the IETF? 

Because standardising what has already been put into products is risky.
And because specifications need to be developed in a finite time, in
between a need for them being discovered and products shipping. 

I agree that the IETF has produced some excellent, implemented specs.
But their process isn't glitch free, and can fail; see the archives of
the IETF HTML WG for an example. Lots of debate, near-zero involvement
of browser implementors.


> I dont' get that.  Can someone explain
> that to me?  Does it have to do with paper documents or something?

Nothing to do with paper documents ;-)

We do theoretically sell paper copies of W3C specs, for an ammount that
covers postage and printing; AFAIK we have never actauuly sold a single
paper copy, which is great. All the specs are online as HTML, and
increasingly as xml as well.

> So my take on the argument, in a nutshell: Somebody needs to go implement
> XSL, develop some great apps using it, in the process fix everything which
> is wrong with it, 

yes. Feedback from indelv and from fop, and others, is indeed shaping
and forming the XSL spec.

> and then offer it up as a standard.  Standards bodies
> should be editors, not authors.

Actually, my experience is that specification-writing bodies should be
both authors and implementors. Which is what W3C working groups do. That
way, what gets produced is vendor neutral, openly available, and
demonstrably implementable by the time it gets to be a W3C
Recommendation.

Standards bodies, in the traditional sense, come afterwards and are
indeed editors. For example, the PNG spec, a W3C Recommendation since
1996, is currently going through ISO standardisation.

--
Chris

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)