[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Walking a complex object graph


Subject: RE: [xsl] Walking a complex object graph
From: "Michael Kay" <mhk@xxxxxxxxx>
Date: Fri, 16 Jul 2004 21:12:40 +0100

> Now, it seems that to do this one should be able to write a custom
> XPathNavigator, DOM object, etc. that simply keeps track of where
> it is in the object graph, and simply returns the right "attribute"
> and "child node" information accordingly when this is demanded of
> it by the XSLT transform processing engine.
> 
> However, it appears that the .NET XSLT engine is either attempting
> to read the entire XML structure into memory, or simply performing
> very deep searches, which often results in the XSLT engine getting
> stuck in an infinite loop. (I.e. if X -> Y and Y -> X, then you can
> keep ping-ponging back and forth endlessly between the two objects.)
> 
> We're suspecting the problem is not an issue with the XSLT code we're
> writing, but a problem with the way the XSLT engine is processing it,
> and we're wondering if there's a better XSLT engine (Xalan? Saxon?)
> to use for this kind of application.
> 
> Or is this simply an incorrect application of XSLT?
> For example do XSLT implementations generally assume the source
> document is finite, and can be completely read into memory
> before the transformation begins?

Well, it's certainly a novel way of using XSLT, and I'm not entirely
surprised if it causes some odd behavior in the engine.

You could do this in Saxon, and I think it would work, but it would not be
easy (you would need to write your own implementation of the NodeInfo
interface, including all the axes). You would have to be very careful about
implementing document order and node identity correctly. I think I would be
more comfortable copying the data into a "real" tree - you'd certainly be at
less risk of taking the processor into territory where no-one has taken it
before.

Michael Kay


Current Thread
Keywords