[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: DOM or SAX: Sense and Sensibility
> 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|