xml-dev - RE: J'accuse (was re: opposition to ISO XML?)

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

1.  ISO bueaucracy is not demonstrably worse than 
consortium burearcracy and antics.  ISO 
has better processes and more practice at managing 
standards development.  Internet time is a myth and 
it is tougher month by month to get a W3C project finished.

2.  The potential of whims concern some, but so far, 
these get worked out in implementation.  The consortium 
members ignore whims and get on with what they want to do.  
Unfortunately, this also means that the W3C specs  
become less binding and less authoritative.  The software 
carries the burden of stability. 

3.  ISO and W3C maintain different profiles of SGML now. 
So far, no one has been seriously injured.  It doesn't do 
much for the problem of citation but citation again, is a 
lawyerese problem.  Namespaces can screw that over by conflating 
name and location then insisting the namespace names a semantic 
instead of naming a choice of an interface, but the PUBLIC id 
is still there for those who know how to use it wisely 
and the SYSTEM id is there for those who need to apply it.
  
What I like about ISO is that it looks very hard at 
issues such as adding new features.  It is NOT a technology 
incubator.  It ignores trivial innovations.  Since these 
are usually vendor-specific anyway, it doesn't stop them. 
They just can't be cited without a sole source justification. 
ISO shouldn't rubberstamp; it should be the authority that 
can freeze the spec into a standard.  That is a control on 
what gets released under what named set of resources, not 
what innovations can be made locally.

"Dim-witted government procurement departments" are responsible 
for ensuring the airliners we fly are safe, the electricity we 
use is on, the water we drink is uncontaminated, our armed forces 
are well-equipped, and so on.  Law is written for reliability 
and predictability: aka, standards for services.  Caveat emptor 
because the vendor is only as obligated as these standards require 
them to be aware.

It is the pace of change and the variations of the technology 
specifications that are beginning to concern much larger 
groups than these departments. How many kinds of trees 
are there in the XML specs?   How much time do we devote 
to explaining that the InfoSet is not the definitive model 
even if we think it should be?  How many checkboxes do we 
have to add to a GUI to cope?

The Los Angeles Times, November 27, 2000, has a piece on the 
complexity issue of software.   We know the moan:  "too many 
notes, Mozart!"  The author says this is old news in the computer 
science community.  He is right.  We keep trying to come up 
with ways to manage complexity and keep hitting the problem 
that our ways to manage have to be managed have to be managed 
have to be managed... and information theory outs Maxwell's Demon 
one more time.

Given how long we campaigned to make markup part of the solution 
of complexity management, it is disappointing to realize that 
the proliferation of options in XML and its siblings is now a 
source of failure.  We might do well to pay attention to the 
"dim-wits" if by our relentless spinning of our propellors 
we keep making their jobs harder.  After all, we can't expect 
"dim-wits" to protect our interests if we continue to befuddle them.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


From: David Megginson [mailto:david@megginson.com]

There are three alternatives:

(a) ISO takes over control of the spec from the W3C, so that it's
stable but difficult to change and buried in bureaucracy;

(b) the W3C continues to control the spec (with an ISO rubber-stamp),
so that it's easy to change unstable and subject to the W3C director's
whims; or

(c) ISO and the W3C maintain different, competing versions of XML.

I think that (a) would be problematic and (c) would be disasterous
(what would XML-conformance mean?), while (b) -- which most people
seem to be suggesting -- would be simply dishonest (somewhat akin to
companies submitting proprietary specs as W3C NOTEs to trick customers
into thinking they're Web standards).

I don't doubt that we would be able to use an ISO rubber-stamp to
trick dim-witted government procurement departments into approving XML
for internal use, but they won't really be getting what they expect
from an International Standard -- something that has been developed
deliberately and (painfully) slowly by a team of international
representatives and is guaranteed to be very stable.