W3C process (was: Re: Weighing in on XSL / Standards)
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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
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