Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XOM vs. dom4j
 I just subscribed to XOM's mailing list and can take the rest of this discussion there if it is preferred, but since I started it here I will continue. After looking at the API (which is definitely breif - it does look simple :), the FAQ, future directions and the tutorial, I am not seeing some things I need or that some things will be put in a future release: - XPath - I need to get an element by ID which doesn't seem to be in Future Directions. I also need to get things by an element path which does appear in Future Directions. - XSLT - is the only way to do a transform by using nu.xom.xslt.XSLTransform? -- how do you setParameters? -- do you need to transform to nodes and then the do a toDocument on the XSLTransform object and then use nu.xom.Serializer(ServletOutputStream).write(Document) to send the result to the browser? Is there a better way? -- can I use XOM in a jaxp transformation so I can set a URIResolver on the TransformerFactory and another on the Transformer? In other words, is there something (planned) like a XOMSource? thanks, -Rob Elliotte Harold wrote: > Robert Koberg wrote: > >> I just googled looking for a comparison between XOM and dom4j (what i >> am currently using) and only found your comparisoin to JDOM. Looking >> at the XOM information at your site >> (http://www.cafeconleche.org/XOM/), it looks like XOM and dom4j are >> similar. Is that the case? > > > XOM and dom4j were both inspired by JDOM. Neither uses any JDOM code. > > dom4j was started by a developer who was dissatisfied with JDOM, and > wanted to add to it. XOM was started by a developer who was dissatisfied > with JDOM, and wanted to subtract from it. > > One of the many things dom4j adds to JDOM (conceptually, not in code) is > complete support for DOM interfaces. In other words, a dom4j Element is > also a DOM2 element. This means dom4j offers all the complexity and > confusion of DOM, plus its own complexity and confusion on top of that. > Somehow this doesn't feel to me like progress. To make matters worse, > dom4j isn't really a conformant implementation of DOM. A lot of the > methods don't do exactly what the DOM specification says they should. > > XOM does not implement DOM. There's only one API to learn and use, and > its simpler than any tree-based API I've seen in Java. It focuses on > correctness, simplicity, and performance, *in that order*. JDOM allows > you to create malformed documents, as do DOM and dom4j. It is simply > impossible to create a namespace malformed document in XOM (or if it > isn't, it's a bug; and I will fix it when it's pointed out.) > >> I am using less memory after switching from JDOM to dom4j. Would there >> be a similar benefit going from dom4j to XOM? Do you have any >> critiques of dom4j in favor of XOM? (I am open to switching.) > > > I've done a lot of memory profiling on XOM and made serious efforts to > reduce its memory usage. Right now it seems to need somewhere between 4 > and 5 times the size of the input document to store the model in memory. > There are a few more optimizations I plan to explore in the future, and > I hope to get that down to maybe a factor of 3 (though not in 1.0). I > don't know what sort of memory profiles JDOM and dom4j have so I can't > really compare. > > XOM does offer a streaming mode in which documents can be processed one > subtree at a time without storing everything in memory so it can process > documents much larger than available memory. JDOM has something similar, > but I think XOM's support for this is better documented and better > supported. > 
|
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
|
|||||||||
