Announcement: XML Infoset Requirements Published

[Rob Schoening]

> > This layered approach to XML is burying its potential.
>
>I'm having a lot of trouble following the argument -- perhaps a simple
>summary of the main points would help.  Do you believe that layering
>is a problem because it's hard to keep track of or manage the
>different layers, or do you believe that XML should not be the base
>layer?

Some of both.  I worry that the stack model is deceptive in that it masks
the degree of complexity that each spec adds to the entire system.

1) Putting the XML spec at the bottom presupposes that the markup is the
essential characteristic of XML.  I would argue that the essential
characteristic of XML--what gives it so much potential--is the consistent
data model that is shared between the XML spec, DOM, Sax, RDF, etc.  I don't
see how the XML spec proper is somehow "more essential" to the system than
anything else.  Granted, it is much easier to formalize a language than an
abstract data model, but I see that as a poor objective justification for
elevating its status.  The issues at hand are very pragmatic.  The success
or failure of XML will not turn on the academic aspects of the langauge
spec.  It will turn on the degree to which the system as a whole is able to
tame the complexity (and thus costs!!) of various information systems.  If
history is any indication, that complexty (and cost) will be manifest in the
software required to process and manage the data.  To that end, it seems
naive to assume that decisions can be made at the lowest levels without
regard to their impact at the higher levels.

2) OSI-style protocol stacks work (or don't work) because the number of
interfaces are directly proportional to the number of layers.  Ideally seven
layers yeilds six interfaces.  XML isn't so neat.  This is manifest in the
discontent over namespaces.  If the namespaces interface was with the XML
spec only, I doubt that there would be so much complaining.  But ultimately
if we're to keep the XML camp together, all of these technologies need to be
kept in sync.  This is HARD!  If N is the number of XML related specs, the
number of related interfaces will be N!/2.  This is going to get really
complex, really fast.  

More than anything, we need a *name* for the system that is comprised of all
of the specs discussed on this list.  Java is a good example.  The java
language spec, the virtual machine spec, and the APIs, and the various
implementations all fall under the banner "Java".  This subtle organization
has been instrumental in its success.  Microsoft tried to claim that Java
was just the java language spec, but Sun has arranged things so that that it
is clear to the objective observer that this is not the case.  More
importantly, the Java banner has ensured that Java ISVs have gone in a
consistent direction.  You might not agree with what Sun is doing, but
they're doing a hell of good job doing it. 

XML is not heading down the same path.  

I'd like to see the following:

    1) A rallying point for XML related technologies.  The psychology of a
name is significant.  If this list was called XYZ-dev, I think that we'd all
be better off.  I know a lot of people will think this is frivolous, but I
hope there is some thought put into the issue.  I'm afraid that XML is going
to become, in Bill Gates' words, *just* a markup language.  (Please, don't
respond by telling me that XML is just a markup language because that is my
point.)

    2) Some formal analysis of the overall system.  At the very least, this
could be a set of hypothetical use-cases for the various XML technologies.
There is quite a lot of "XML is for ____" commentary on this list these
days.  Arguing these points in detail is bound to go nowhere.  The fact of
the matter is that people are going to use XML for all kinds of different
things.  Of course it does not make sense for all of these potential uses to
become guiding principles for the XML initiative.  However, without some
guidance, these differences will begin to manifest themselves in parochial
initiatives (ABC spec, DEF spec, etc) that will be mutually incompatible and
ultimately fracture the overall effort.  

  As you can see, these are *not* technical concerns.  I think that it is
imperitave that we realize that the success and failure of technology rarely
turns on objectively technological issues.  Focusing on the shortcomings of
XML namespaces misses the salient issues entirely.  The litany of woes will
continue unless something is changed.  Last month it was namespaces, now it
is the infoset, next month it is going to be something else.

Let's go after the root of these problems.

Rob


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)