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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Effective DOM (was RE: [xml-dev] Effective XML)

[ Lists Home | Date Index | Thread Index ]

> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Sent: 03 January 2002 15:18
> To: xml-dev
> Subject: [xml-dev] Effective DOM (was RE: [xml-dev] Effective XML)
> ...But in my biased opinion, it seems like a pretty straightforward way to use the
> generic XML object model.  It will be MORE useful when Level 3 defines
> standard load/save, validation, and XPath access interfaces are defined, of
> course. 

Yes these facilities will help, but it's unfortunate that they've been left 
until Level 3 -- they'd have saved a lot of heartache if they could have been 
dealt with earlier, IMO.

> I'd be interested in hearing concrete examples of why people find the DOM
> painful to use, in what ways JDOM and dom4j seem more friendly (besides
> their native Java idioms, of course), etc. 

Well the native Java idioms cover a number of reasons why I like JDOM and 
dom4j. I completely understand why the DOM interfaces are language-neutral, 
and rightly so. However that's why I was suggesting (and Fred Drake seems to 
agree) that if the primary object model for your application is that of the 
XML document, then the DOM is the correct model. However if you're just 
importing/exporting XML data from an application then another API will probably 
be easier to work with. This seems to fit well within the design goals of 
the DOM. 

I'd also place this as slightly different decision to whether one should adopt 
a JAXB-like tool. I'd suggest these are useful if you're using XML data to drive the 
creation of the majority of your application objects. Slightly different than 
choosing a handly tree API to work with -- and as we've seen before this is 
often the model that beginners prefer to work with.

>I have three motivations for soliciting this input:
> - Improving the standard DOM down the road 
> - Defining convenience layers on top of the W3C DOM that minimize the pain
> - Defining and documenting DOM gotchas, workarounds, best practices, etc.

IMO, the last two of these seem to have the most promise, mainly because I'm 
in favour of capturing best practices, but also because it was knuckling down to write 
a number of utility functions that ended up minimizing most of my pains. 

Are there any public collections of DOM utilities? This might be a useful thing to 
collect together if there isn't.

My list of utilities includes:

- document factory, and writers (obsolete with JAXP and DOM Level 3)
- methods to convert nodes to text (e.g. getting text content from 
elements, etc) and simple Java types, e.g ints
- getting the path for a given node
- pruning elements, including shifting their children upwards in tree
- pruning by name
- moving children between elements
- renaming elements
- node copying utilities (for moving nodes between documents)
- moving attributes into text content and vice verse
- DOM searching (i.e. quering) using a simple XPath subset

I also ended up implementing some of the DOM interfaces, e.g. 
DOMException, NodeList, NamedNodeMap to support some of these.

The majority of these were for a scripted transformation engine I wrote in 
1999. For this DOM was the right model, and besides there's wasn't anything 
else :)




News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS