[
Lists Home |
Date Index |
Thread Index
]
Thomas B. Passin writes:
> Sometimes it seems to me that most of the XML-related Recs/Specs
> that xml-dev'ers approve of are those that James Clark had a major
> influence on. Sax is an exception, I suppose, but that had David
> M. playing a unifying role, so maybe it is in a similar category.
SAX is not as much of an exception as you might think, since it was
heavily influenced by James's SGML parsers ab initio, then by James's
constant advice, criticism, and encouragement during the initial
development.
> I would like to ask a few questions about this.
>
> 1) Is this perception widely shared on the list?
> 2) If so, is it specifically James, or is it the mode of development?
> 3) Are there any examples of good/elegant/approved (by xml-dev'ers) recs
> that were developed in a different way?
> 4) If there is a mode of development that tends to lead to especially
> good/elegant/etc recs, can we foster that mode? Or does it take specific
> individuals with very special knowledge and personal qualities?
I cannot claim to have done any proper scientific survey, but I've
noticed a few common characteristics among specs:
1. Simplicity succeeds.
It is unlikely that a spec will be successful unless specialists in
the field complain that it is far too simple for real-world use
("I've been working with markup since 1988, and I know that in
industrial-strength projects we need to ..."). Pre-W3C HTML is the
classic example, but remember that networking types once looked
down their noses at TCP/IP as well ("It's fine for academic
research, but ..."). Sometimes the specialists get their revenge
in v.2 by joining the process and smothering the spec to death with
new features.
2. Process is poison.
It looks good on paper, but in practice formal process doesn't work
at all, at least not for initial spec development. XML 1.0 was
developed mostly under the radar at the W3C; after that, it became
very hard for the W3C to do any useful XML work (DOM and XSLT
succeeded only because they were already well underway). Process
is a good thing in a perverse way after a v.1 release, because it
slows down work and postpones the usually-catastrophic v.2 release.
3. Code first, then specify.
Anticipatory specs for problems people haven't tried to solve yet
are just wild, random shots in the dark; at best, they waste
everyone's time, and at worst, they cause confusion and hostility.
Most existing XML-related specs should not have been written yet:
we don't need a spec to cover X until many, many people have been
trying to implement X for a while and have discovered where a
common spec might be beneficial. A new field of development
shouldn't *start* with a spec; it should *end* with one.
4. Almost every new spec fails anyway.
Specs are more like frog or fish eggs than they are like infant
mammals -- we lay hundreds or thousands in the hope that at least
one or two will make it to adulthood. There is no way to guarantee
success, even by taking the previous criteria into account.
All the best,
David
--
David Megginson, david@megginson.com, http://www.megginson.com/
|
