Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 12:01 PM 2/7/99 -0500, Simon St.Laurent wrote: >To a considerable extent this demands that spec writers see themselves as >implementors - and probably that they include implementors in the process, >especially implementors who don't have prior experience in whatever >standards provided the foundation of the current project. The story for >XML 1.0 of using Peter Murray-Rust as a canary is a good one, though I'd >like to see more of that in the actual group of people writing the specs, >not just the surrounding groups. There's an interesting lesson lurking in there. The original XML WG included implementors of Author/Editor, HoTMetaL, groff, SP, Jade, Pat/Lector, IBMIDDOC, Dynatext, Mosaic, and Grif. So Simon's (implied) theory that the specs would have been better, had the authoring group included implementors, stands on shaky ground. A couple of hypotheses that might explain this: - being an implementor is not a particularly strong qualification for writing specs - being a core-technology implementor, rather than a solution builder or system integrator, is not a particularly strong qualification for writing specs This group is notably and vocally dissatisfied with the specs, I am watching with attention for concrete suggestions as to how to make future specs better - the one premise that seems to get consensus, in this group at least, is "more examples". (Hmm, the namespace spec has tons). As regards the namespace spec, another hypothesis: - it might be easier to understand for people coming in from outside who aren't carrying around a bunch of SGML-derived expectations. And given that XML actually seems to be succeeding quite vigorously in the marketplace, a final hypothesis: - there is little relation between the presentation quality of a spec, in and of itself, and whether the world will welcome it (presumably we *do* believe that the quality of the design being spec'd does have some such relationship) My own personal take - the XML spec has holes that I'm more deeply aware of than anyone in the world, but it's a bearable compromise given the combined resource/time/political constraints - and the real-world problems with XML are not the spec itself, but SGML-derived bogosities like parameter entities. And as regards the namespace spec, I think that some people on this list are substantially full of [expletive deleted], and are wilfully refusing to see how simple it is because it does not meet their own design prejudices. I think that spec is *way* better than the XML spec. Having said all that, people who write specs always have to try to do a better job next time, so this recent discourse is very very useful. -Tim 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...)
|
