OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



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

[ Lists Home | Date Index | Thread Index ]


> -----Original Message-----
> From: W. E. Perry [mailto:wperry@fiduciary.com]
> Sent: Friday, January 17, 2003 6:59 AM
> To: James Governor; XML DEV
> Subject: Re: [xml-dev] Adam Bosworth Article - what does "direct
> mean?
> James Governor wrote:
> > Are you for real? Trying to work out how much irony is in your
> >
> > James Governor
> > RedMonk
> > (+44) 207 254 7371
> None. What would be the point? I do have a full schedule and better
> 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
> 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
> by
> subsetting it for efficiency in doing this or that. Their
> always involve cutting away at either the lexical or the internetwork
> roots
> of XML, usually both.

Perhaps you are too quick to impute positions to those who disagree with
you.  You seem bent on twisting others' positions into the one you
despise.  The history of this list makes it difficult for newcomers to
participate in the discussion.  The discussion on this list too often
seems like Slashdot with better grammar and a sense of history.  The
same old arguments are trotted out; the same presumed villains are
vilified; and the same set commonly held beliefs are reinforced through
repetition.  I followed this for some months before I posted.  There is
a good deal of useful information and a lot of very bright people, but
it is unclear to me exactly how open the list really is.
> My work depends on using XML to process documents, or data, together
> though
> they come from disparate sources, usually unknown to each other, and
> never intended to mix. The 'intended' is crucial. The applications of
> 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

This may be the crux of my substantive disagreement with your position.
I have seen the value of the scenario you describe, but I have seen far
more usefulness of XML when the document producers and consumers share
some amount of knowledge.  I think it is entirely possible to provide
tools that enhance the value of document exchange for systems that share
knowledge without denigrating the value of XML for your scenario.

> What XML offers that nothing else I have worked with does is freedom
> intent. My process doesn't, and shouldn't, care what the creator of
> 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
> the
> same level in a hierarchical tree.

Building a system that works in the way you describe is incredibly
difficult and XML makes it much easier.  I still fail to see how the
things that you object to prevent you from doing that.
> The richness or value of XML as data is observably in inverse
> to
> its intent. If you set out to publish a document full of information
> your primary concern is for the quality of the data which you will
> 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. 

I don't believe this is necessarily true.  It certainly is often the
case, but I see many other forces that work on the quality of the

>At the other extreme, if all
> that your document contains is keys to a database which is available
> the
> document's intended recipient then that document is likely useless to
> as
> a third party bystander to its transmission between closely coupled
> and receiver. The sender has perfect knowledge of the receiver's
> 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
> nodes have intimate knowledge of each other behind the firewall. In
> transaction processing it is the fundamental premise of two-phase

It's easy to make the extreme case seem silly.  I don't think it
advances your position at all.

> XML, by contrast, can leverage its lexical and internetwork roots to
> an entirely different model of operation. The fundamental internetwork
> assumption is that every node is directly addressable, but beyond that
> be entirely unknown.

This is a valuable quality of XML, but you have limited its use to one
type of system design by making a virtue out of a practical limitation.
When this limitation doesn't apply, I believe it's silly to impose that

>Communication between such nodes is necessarily
> loosely
> coupled and depends in large part on one offering enough data that
> might do something useful with, even where the creator or publisher of
> information does not know which particular data a particular user of
> information requires, nor how that user might process it. Such
> coupled with the markup tools of XML result, in the best cases, in the
> publication of well-labelled documents, filled with information that
> creator has to offer and cannot assume that any particular recipient
> otherwise have access to, and published at an internetwork URL where a
> variety of interested parties might gain access.

Again, this is excellent, but it's not the only thing.

> 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
> readily confused with invoking the methods of an object by presenting
> expected arguments to an interface. We have seen that, in practice, it
> 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
> 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
> another user, and that the data structure built on the output of a
> by
> one process will, or should, be the same as that built by another
> on
> the output of a different parse of the same document.

Again, you conflate several different approaches to define this straw
man you can knock down.  Fundamentally, I don't see how the XML
documents I define and use within my systems have a negative effect on
you.  Do you somehow fear that bad XML documents will drive out the
good, even if your systems never come into contact with mine?

> The problem is thinking of documents in imperative terms:  it seems to
> too short a step from imagining a document as a message to imagining
> message can convey a command or anything resembling RPC. That
> 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
> 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
> dramatically narrowed. It is important to me to keep all of the
> possibilities inherent in XML open, no matter for how small a minority
> users, and to keep them open forever, because one of the chief needs
> 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
> for
> very specific narrow uses by particular programs, all of us lose. I
> more than others because I depend so greatly on making unexpected use
> information-rich documents. But in general what is best about XML is
> when documents aren't really documents at all, but codes and keys used
> interprocess communication between senders and receivers locked in a
> brittle, closely coupled embrace.

I don't see how your literate brow-beating accomplishes your goal.  Can
you show us some systems that demonstrate your point?  Can you show us
counter-examples of real ill-effects of these brittle, closely coupled
> Respectfully,
> Walter Perry
> -----------------------------------------------------------------
> 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>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS