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] Do We Need James Clark to get Good Recs?

[ 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

 > 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 Megginson, david@megginson.com, http://www.megginson.com/


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

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