[
Lists Home |
Date Index |
Thread Index
]
- To: xml-dev@lists.xml.org
- Subject: Re: [xml-dev] Time Travel
- From: Norman Walsh <ndw@nwalsh.com>
- Date: Tue, 01 Apr 2003 15:06:32 -0500
- In-reply-to: <1eb.5577b04.2bb6e5e8@aol.com> (AndrewWatt2000@aol.com'smessage of "Sat, 29 Mar 2003 07:04:56 EST")
- References: <1eb.5577b04.2bb6e5e8@aol.com>
- User-agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.1 (gnu/linux)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
/ AndrewWatt2000@aol.com was heard to say:
| As far as XML goes it would have been good if our time traveller had visited
| the W3C and encouraged better coordination among XML specifications over the
| last 4 years or so. We could have, perhaps, been spared the unnecessary
| terminology problems and inconsistencies between specifications.
I think "better coordination" is like motherhood and apple pie. Few,
if any, would argue against it in principle. In practice, it's more
like fois gras. Delicious, but expensive, and you wouldn't want to eat
a whole lot of it. (Yes, I know some of you would, and you know who
you are, but it's a metaphor darn it.)
If I could send a message back say four years, I'd send the obvious
thing, a roadmap showing where we would wind up four years later.
Armed with that information, I'm sure we could have made different
choices that might have been better in the long run.
The real problem with standardization in internet time is that it's
more often design by committee than standardization.
And design by committee is like any other engineering project.
Eventually you have to shoot the engineers and ship the code.
Companies invest huge sums of money nurturing the development of these
specifications (even if you wish sometimes they wouldn't :-) and they
don't see any significant return on that investment until it ships. It
doesn't matter if you think that's the way it should be or not, that's
the way it is.
As an "insider" on more than one of these projects, I can report first
hand that I find it absolutely agonizing at times. This is especially
true as specs approach last call and the pressure is mounting to
finish even if it means that some possibly significant design choices
have to be made with incomplete information in the direction of least
resistance.
The price of better coordination is that development takes longer, so
it has to be a balancing act. Total coordination would bring forward
progress to a halt. No coordination would produce utter chaos.
Every time someone complains that a spec is taking too long, they're
asking the designers to do less coordination. Every time someone
complains that two specs need to be better coordinated, they're asking
the designers to slow down and take longer.
The best thing we can all do is read the specs carefully, especially
as the enter last call, and lodge all the issues we can see. The
trick, of course, is seeing four years into the future.
Be seeing you,
norm
- --
Norman.Walsh@Sun.COM | Life always comes to a bad end.--Marcel Aymé
XML Standards Architect |
Web Tech. and Standards |
Sun Microsystems, Inc. |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
iD8DBQE+ifFIOyltUcwYWjsRAgTUAKCRVCkM4UUxeq4Nv7XkYfuK5/J0VwCgnym8
mj74SC+6mLaqAbN39bIRds8=
=UbqK
-----END PGP SIGNATURE-----
|