[
Lists Home |
Date Index |
Thread Index
]
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.
>
|
