Re: [xml-dev] Adam Bosworth Article - what does "direct access" mean?

["W. E. Perry" <wperry@fiduciary.com>]

James Governor wrote:

> Are you for real? Trying to work out how much irony is in your posts.
>
> James Governor
> RedMonk
> (+44) 207 254 7371

None. What would be the point? I do have a full schedule and better things
to do with my time than score points for smirking off those who drop in to
XML-DEV a time or two and then disappear. I have said the same things here
consistently for five years. I think that it is necessary that they be said
(and heeded) for the long-term good of the craft. I have organized the
monthly meetings of the XML SIG in New York since 1998 for the same reason.
In both forums I have seen a steady parade of those who would improve XML by
subsetting it for efficiency in doing this or that. Their prescriptions
always involve cutting away at either the lexical or the internetwork roots
of XML, usually both.

My work depends on using XML to process documents, or data, together though
they come from disparate sources, usually unknown to each other, and were
never intended to mix. The 'intended' is crucial. The applications of XML
which appear truly magical, which provide the true "aha!" moment for someone
seeing them for the first time are, in my experience, always the result of
doing something which was never intended to be. But that's just the point.
What XML offers that nothing else I have worked with does is freedom from
intent. My process doesn't, and shouldn't, care what the creator of some bit
of data which it uses might have wanted, even to the extent of whether what
I have received is 'valid' according to some content model. The bare lexical
instance is there; either it provides something of use to me on this
particular occasion or it doesn't, without regard to whether that something
is labelled as it was in previous examples, or whether it parses out to the
same level in a hierarchical tree.

The richness or value of XML as data is observably in inverse proportion to
its intent. If you set out to publish a document full of information then
your primary concern is for the quality of the data which you will include
in that document, not for the nature of its eventual user. If I gain access
to that document there will be much in it which I can use, regardless
whether my use is one that you ever imagined. At the other extreme, if all
that your document contains is keys to a database which is available to the
document's intended recipient then that document is likely useless to me as
a third party bystander to its transmission between closely coupled sender
and receiver. The sender has perfect knowledge of the receiver's internals
and can therefore select, and force the receiver's attention to, particular
items of the receiver's own local data. Such intent is the underlying
premise of traditional enterprise network systems, where closely coupled
nodes have intimate knowledge of each other behind the firewall. In
transaction processing it is the fundamental premise of two-phase commit.

XML, by contrast, can leverage its lexical and internetwork roots to offer
an entirely different model of operation. The fundamental internetwork
assumption is that every node is directly addressable, but beyond that may
be entirely unknown. Communication between such nodes is necessarily loosely
coupled and depends in large part on one offering enough data that another
might do something useful with, even where the creator or publisher of
information does not know which particular data a particular user of that
information requires, nor how that user might process it. Such assumptions
coupled with the markup tools of XML result, in the best cases, in the
publication of well-labelled documents, filled with information that their
creator has to offer and cannot assume that any particular recipient might
otherwise have access to, and published at an internetwork URL where a
variety of interested parties might gain access.

As I see it, the real problem is imagining that a schema for a document is
like an interface to an object. Direct access--addressing parts of a
document based on what a schema indicates should be there--has been too
readily confused with invoking the methods of an object by presenting the
expected arguments to an interface. We have seen that, in practice, it is
too short a step from accepting that analogy to chopping away at the lexical
or the internetwork roots of XML, or both. Why can't an object
serialization, encoded as XML perhaps or maybe not, be passed between
processes, and save the inefficiencies of parsing and generally dealing with
awkward, prolix text? The answer is that in that question too many
unwarranted assumptions have been made, among them that any particular user
of an XML document will use it in any particular way, that the object
serialized by one user is useful, or even understandable, as an object to
another user, and that the data structure built on the output of a parse by
one process will, or should, be the same as that built by another process on
the output of a different parse of the same document.

The problem is thinking of documents in imperative terms:  it seems to be
too short a step from imagining a document as a message to imagining that
message can convey a command or anything resembling RPC. That assumption
depends not only on mistaking that one process will use a message or
document in much the same way as another, but also wrongly assuming that
different processes will instantiate anything like the same data from their
separate parsing of the same message. Those are assumptions which are
workable and useful in some narrow scenarios, but when they become the
general assumptions of XML processing the scope of XML's possibilities is
dramatically narrowed. It is important to me to keep all of the
possibilities inherent in XML open, no matter for how small a minority of
users, and to keep them open forever, because one of the chief needs for
XML's possibilities of interoperability is interoperability over time.

If most users, relying on tool vendors and a perspective of purely
programming efficiency, begin to create XML documents which are, as
instances in their own right, information poor because they are intended for
very specific narrow uses by particular programs, all of us lose. I lose
more than others because I depend so greatly on making unexpected use of
information-rich documents. But in general what is best about XML is lost
when documents aren't really documents at all, but codes and keys used for
interprocess communication between senders and receivers locked in a
brittle, closely coupled embrace.

Respectfully,

Walter Perry