xsl-list
[Top] [All Lists]

RE: Walking a complex object graph

2004-07-16 13:12:40
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



<Prev in Thread] Current Thread [Next in Thread>