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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Binary XML" proposals

Al Snell wrote:

> Christopher R. Maden wrote:
> >If I get Al's Binary Structure Format, what the heck do I
> > do with it?  The drawbacks seem prohibitive and the benefits minimal.
> Dude, we covered this point... read the thread!

What this thread has not covered, IMHO, is this:  what you, or I, or any user of
an XML document might *do* with it is determined primarily by what the needs and
the abilities of that user are, and by the particular environment in which that
document is used, far more than by any fixed understanding of what that document
might 'mean'. One proposal earlier in the thread apparently visualized a 'binary
XML' format as a way to hash and then ship around SAX events between
applications, avoiding re-parsing with each use. This sort of thing is a well
known and common practice of course, but it utterly misses a salient point of
XML. It is inherent in the nature of XML that the text of a document be parsed
anew for each use of that document, in the particular context of that use. XML
applications begin by parsing because XML applications may be unique and
idiosyncratic uses of XML documents, where the outcome of that parsing is
determined by the environment in which it is done or by additional data available
at that parse which is not accessible to other users of the same XML document.
This is a uniqueness of XML, and one which affords an entirely new basis for
distributed applications. Such artifacts of the present distributed processing
orthodoxy as the two-phase commit protocol rely on a transparency which is
offered by an homogenous enterprise network, but unavailable on an internetwork.
On the homogenous network, nodes can recognize each other by their functions and
have privileged, intimate knowledge of both the data structures and the sequence
of process expected by other nodes with which they participate in distributed
transactions. The node performing bank ATM processing knows the data structure
which the node performing the account side of a withdrawal transaction expects,
and both follow the same sequence of identical process steps, which they can
reverse in identical order if it is necessary to rollback a transaction. In such
an homogenous environment, the SAX events from parsing a given XML document at
one node may well be identical to those from processing it at another, and could
be shipped in fixed binary form between the two without any loss of information.
In an internetwork topology, however, two nodes may share nothing but the ability
to contact each other through the addressing scheme which has been overlaid onto
constituent networks built on very different assumptions of process and of the
expected form of data. Through internetworking those nodes may be able for the
first time to exchange data, but the expected form or 'meaning'--let alone the
proper uses--of that data may have nothing in common between the two. When that
data is exchanged as XML text, with the fundamental expectation that it will be
parsed afresh and then processed at each node in an environment and for purposes
which are unique to that node, it is possible for the first time to execute
distributed processing between utterly dissimilar parties. That new and unique
benefit of the XML intellectual commons is the first thing lost to any canonical,
let alone binary, representation of meaning.


Walter Perry