[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: DOM or SAX: Sense and Sensibility

dom4j sax
> From: bob mcwhirter [mailto:bob@w...]
> Sent: Wednesday, November 07, 2001 12:36 PM
> To: xml-dev@l...
> Subject: RE:  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.


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.