Re: [xsl] XPath over DOM

Subject: Re: [xsl] XPath over DOM
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Wed, 14 Feb 2001 22:06:19 -0700
> : Why would any Java XSLT processor have a problem working with 
> : another's DOM 
> : nodes?
> : 
> : Could it be that even for mighty Java, interoperability is 
> : all illusory?
> 
> They don't have a problem working with another DOM objects, but what most of
> them do (AFAIK) is take and reparse them into internal format for speed
> optimization. In my particular project, we are very concerned with memory
> usage, so we need the processor that can use the DOM structures we already
> have.

I was being trivial.  Sorry.

I'll make amends by trying to help.

It does genuinely seem odd for a DOM implememntation to convert nodes for the 
sake of performance.  This step would probably take even longer than the 
likely performance savings.

So, to check this out, I had a look at Saxon, which I usually use from the 
command line.

I found com.icl.saxon.DOMDriver

And indeed it looks as if the business end is the convert() method, which 
takes any org.w3c.dom.Document object and turns it into a 
com.icl.saxon.DocumentInfo object for use with Saxon.  I did also see walk(), 
but this didn't seem to be the ticket.

So now I'm genuinely puzzled.  Why is it necessary to convert the nodes?  I 
understand the theory that SAX events can be stored more efficiently than DOM, 
but I don't see the gain when the DOM is already in memory.

So, in the end, I guess I am no help.  I'm curious about the answers you find.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread