Re: "Binary XML" proposals

["Stephen D. Williams" <sdw@lig.net>]

"W. E. Perry" wrote:
> 
> "Stephen D. Williams" wrote:
> 
> > IMHO, SAX events are the wrong model for a more useful binary structured XML.  DOM,
> > or rather DOM + optional DOM Deltas, are my current front running model.  For
> > protocol use, including passing around any kind of XML for application
> > interpretation, XML transmission will generally be done atomically where access to a
> > DOM style tree is typical.  SAX, in these situations, seems to be used mainly to
> > support a custom parse tree, including just loading values into a 3GL structure,
> > rather than for it's other advantage: processing documents too large to load
> > completely into memory.
> 
> Your model is a more perfect realization of the 'binary' (which I call 'canonical')
> philosophy advocated in this thread, and my philosophical objections to it are therefore
> even stronger. There is much XML, and many, many uses of it in myriad contexts, which
> under particular processing does not exhibit the object model envisioned by its author,
> and most especially not a *document* object model. The salient *document*
> characteristics of the DOM are document order and the hierarchical parent-child
> containment relationship. While a stream of SAX events will be emitted in document
> order, the processing of those events may legitimately handle them in a manner which
> upsets that order, and its expected implications, as well as instantiating relationships
> quite different from parent-child containment and an overall structure which is not the
> hierarchical tree you expect. In positing the DOM (or any *document* object model) you
> constrain the syntactical possibilities to a narrow range of instantiated object
> outcomes which might not fit the needs or expectations of a particular process that
> might otherwise have done something useful with an XML document. By further expecting
> *particular* DOM nodes to be instantiated, off of which you derive deltas, you
> effectively require a comprehensive agreement a priori between the creator and user of
> an XML document, covering all of the possibilities of its use. There are, of course,
> certain very narrow applications of XML messages for which such tightly constrained
> behavior suffices. I suggest that there is much more of use to most of us in the
> enormous range of possibilities outside those narrow constraints.

A very valid argument.  I would counter that the fact that data is
presented as a DOM structure or DOM+DOM Deltas (which allows 'streaming'
a la SAX to some extent) doesn't prevent non-intuitive processing that
would currently be done with a SAX stream.  You are correct in pointing
out that some of the potential advantages of a binary structure would
not be used, but this in itself is not a net negative, IMHO.

Regardless of the proportion, there are important applications where
potentially large documents/messages are handled in straight DOM style. 
This is especially true where the 'message' has a long,
multi-transaction lifetime as is the case with any N-Tier, distributed,
transaction based, routed application.  In fact, this is often true
within a single executable as different modules perform operations on
subsets of the data.  One major problem is that many modular programming
environments force you to 'flatten' your data to a wire/buffer format,
or even worse to a set of name/value pairs.  Netscape Application Server
and others fall into this category.  As a further rationale, NAS does
this specifically to allow replication of the session state to other
servers in a cluster.

One application I architected several years ago was a worse-case
scenario that required a number of advanced features to handle
optimally.  Using straight XML, which is what we had time to do, was
dismally slow and all our CPU was spent parsing or 'production' of XML. 
I've been evolving my constraints and solutions ever since.

> Respectfully,
> 
> Walter Perry

sdw
-- 
sdw@lig.net  http://sdw.st
Stephen D. Williams
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 
Dec2000