[jdom-interest] JDOM and XSL/ problem with xalan 2 DO5

Marco.Mistroni at nokia.com Marco.Mistroni at nokia.com
Thu Jan 25 03:58:50 PST 2001


hi shaun,
	sorry again...
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
	marco

> -----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!
> 
> Regards,
> Shaun.
> 
> 
> 
> hi,
> 	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
> parsers????
> can i have more clarification on that???
> 
> thanx in advance and regards
> 	marco
> 
> 
> > -----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[0]));
> > 
> > --> 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 mailing list