[jdom-interest] JDOM and XSL/ problem with xalan 2 DO5
shauns at pixology.com
Thu Jan 25 04:18:04 PST 2001
JDOM is designed to be Java-specific, and is only really useful
if you need to programatically create XML documents, or modify
existing XML documents. To quote from the JDOM site:
'It has a straightforward API, is a lightweight and fast, and is optimized
for the Java programmer. It's an alternative to DOM and SAX, although it
integrates well with both DOM and SAX.'
JDOM by default uses the Xerces parser to create it's representation
of documents, this is pluggable if it needs to be.
In a situation where I was transforming using pre-existing documents
(on the local filesystem for instance), there would be no sense
in using JDOM; with Xalan I would be using Xerces to build a JDOM tree
in memory, and then having to output it again to a different representation
to do the transform.
My usage pattern is different; I am generating documents dynamically (and
no textual representation ever exists of the XML document - only the
JDOM tree), and then converting that to a DOM document (again, no textual
representation) and transforming it. The reason I use JDOM for that
is because it is quick and easy. The advantages I are that I never produce
a textual representation of the XML document, and I have an extremely easy
to use lightweight API. The disadvantage is the hit in transferring it
from an org.jdom.Document to a w3c.dom.Document - perhaps someone on this
list will suggest to me a more efficient way of doing it??
I hope this clarifies things a bit.
so can you explain me (again) how you used JDOM with XSL??
and, does your approach bring more advantages/disadvantages than using an
XSL with its own parser??
thanx again and regards
> -----Original Message-----
> From: ext Shaun Smith [mailto:shauns at pixology.com]
> Sent: 25. January 2001 13:51
> To: 'Marco.Mistroni at nokia.com'
> Cc: jdom-interest at jdom.org
> Subject: RE: [jdom-interest] JDOM and XSL/ problem with xalan 2 DO5
> I'll let others here clarify/correct me, but the purpose of
> the SAXBuilder class is to build a Java specific in-memory
> representation of the tree.
> I'm not sure what you mean by behind other parsers though;
> there are two ways to look at it:
> 1 - You use the SAX events and filter what you want. So, I
> - could build a partial tree in memory, but if I wanted to
> - drill down I would need to parse the file again to get the
> - sub elements that I wanted. Not terribly efficient!
> 2 - You can build a tree in memory. All elements in the document
> - will be accessible at once.
> It is hard to imagine a system which offers the 'best of both'
> without being reasonably inefficient (although probably doable
> with random-access files). JDOM does the latter; it does not
> fire events at the end user (the application programmer), although
> it can capture and send SAX events if needed.
> Also, JDOM is not strictly speaking a parser; it uses parsers to
> build an in-memory representation of the document. I'm not sure
> what the JavaWorld article is meaning, I may have a look at
> lunchtime :)
> What's a 'pmnace'?
> Anyway, can't help noticing that we've drifted away from the
> original problem!
> yeah.... now i am little confused
> according to an article appeared on JavaWorld,
> ' JDOM takes the best concepts from DOM and SAX.[...] it does
> not require
> the entire document to be in memory... '
> so...are you saying that in pmnace evaluation, JDOM is still
> behind other
> can i have more clarification on that???
> thanx in advance and regards
> > -----Original Message-----
> > From: ext Shaun Smith [mailto:shauns at pixology.com]
> > Sent: 25. January 2001 13:32
> > To: 'Marco.Mistroni at nokia.com'; Shaun Smith
> > Cc: xalan-dev at xml.apache.org; Scott.Boag at lotus.com
> > Subject: RE: [jdom-interest] JDOM and XSL/ problem with xalan 2 DO5
> > Sorry, I think I must be misunderstanding - I am sure that
> > I'll be corrected tho'!
> > --> Create a SAXBuilder ( SAXBuilder in memory )
> > SAXBuilder builder = new SAXBuilder();
> > --> Create an org.jdom.Document from the builder - this is an
> > in memory
> > representation
> > --> similar to the DOM tree
> > Document doc = builder.build(new File(args));
> > --> Create a DOMOutputter and create an w3c.dom.Document - we
> > now have two
> > representations
> > --> of the tree in memory ( the JDOM document and the W3C document )
> > DOMOutputter out = new DOMOutputter();
> > org.w3c.dom.Document doc2 = out.output(doc);
> > To avoid having the w3c.dom.Document tree in memory during
> > the transform,
> > you can use the Xalan SAXSource.
> > JDOM always constructs a tree in memory; see a few posts below
> > about parsing 16mb files.
> > Shaun.
> > <SNIP>
More information about the jdom-interest