[
Lists Home |
Date Index |
Thread Index
]
Inline
> -----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
access"
> mean?
>
> 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.
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
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.
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
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.
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
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.
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
document.
>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.
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
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.
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
assumption.
>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.
>
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
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.
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
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.
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
systems?
>
> 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>
|
