[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [humanmarkup-comment] Fwd: re: [xml-dev] Do We Need James Clark to getGood Recs?
Hi folks,
I ran across this today and it caught my attention because two of the
five or six genuine good-guys/authorities I pay attention to happen
to be evident. David Megginson wrote it and it is about the uncannily
successful and remarkably common-sensical contributions of James
Clark.
However, it is the numbered items that resound for me, especially
now. As unexpected as it might seem, and certainly would have
yesterday, it makes me cherish our current obscurity and lack of
visibility and, this is the odd part, the sheer ability to get work
done (no matter how much of it there is for any given individual).
Unfortunately the only way I can look back on this period without
great longing for the "good old days" is if we fail or are co-opted
by a similar effort, and I am doing my best to avoid that.
1 is very important right now. 2 is what I wish we didn't need so
much. 3 is words to the wise, especially semiotic processor and our 3
implementations. And 4 is what we need to avoid, but keep in mind if
it becomes necessary to begin again some other day.
Ciao,
Rex
>
>From: David Megginson <david@megginson.com>
>Date: Sun, 27 Oct 2002 07:25:25 -0500
>To: xml-dev <xml-dev@lists.xml.org>
>Subject: re: [xml-dev] Do We Need James Clark to get Good Recs?
>X-Rcpt-To: <rexb@starbourne.com>
>X-DPOP: Version number supressed
>Status: U
>
>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/
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>
--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC