RE: [xml-dev] DOM or SAX: Sense and Sensibility

[Michael Brennan <Michael_Brennan@Allegis.com>]

> From: bob mcwhirter [mailto:bob@werken.com]
> Sent: Wednesday, November 07, 2001 12:36 PM
> To: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] DOM or SAX: Sense and Sensibility
> 
> 
> 
> Just to include some data-points...
> 
> I think that in the open-source Java world, focus has been more on the
> infoset than on any given object-model.  Since we have JDOM, 
> dom4j, EXML,
> along with normal DOM, and only certain utilities are supported under
> certain models (ie, Xalan won't work with dom4j Documents directly),
> there's been a lot of work on translating one model to another.
> 
> Then, you have things like dom4j's ElementHandler interfaces, which
> allow folks who are used to processing object trees deal appropriately
> with very large datasets.  You can register a handler to 
> match particular
> subtrees.  Do whatever processing you need (including XPath 
> expressions),
> and then detach the sub-tree, freeing up memory for the rest of the
> parse.
> 
> Then, you have Jaxen (caveat: it's my project, so I'm baised), which
> aimed to be object-model independant for XPath evaluations, 
> and instead
> works through a Navigator interface, which aims to provide homogeneous
> access to InfoSet members regardless of the model being used.
> 
> In my experience, it's not just DOM vs SAX, but competition between
> the DOMs (sometimes mixing several in the same application) and SAX.
> And typically, dom4j's sub-tree mechnisms have keep me from having to
> venture into hard-to-maintain SAX code.

I've been eyeing the dom4j, SAXPath, and Jaxen stuff with great interest,
lately. I had been thinking along similar lines of Jaxen when I became aware
of it. Currently, our core platform is based on Microsoft technologies, so I
can't use this stuff internally. But this notion of registering a handler to
match subtrees based on XPath is very interesting. Using XPath as the glue
between object models that can support an infoset abstraction is also very
interesting. We commonly load XML into a DOM just so we can leverage XPath.
We use tools for mapping XML elements/attributes to internal data structures
and functions using XPath expressions. It would be great to have that same
abstraction and ease of implementation without having to load a DOM to do
it. (I've also advocated exposing our own data structures via XPath, but I'm
a lone voice in the wilderness, here.)

I hope this sort of approach gains wider acceptance and adoption. I think
having the sort of abstraction that Jaxen affords offers far greater
potential in the long run than looking toward the DOM (or even SAX) as the
glue between XML and other object models.

Is anyone working on any XSLT implementations that work with Jaxen? That
would be very cool.