Lists Home |
Date Index |
M. David Peterson wrote:
>Sorry, I meant XSLT processor. And with Xerces I am assuming Xalan
>but obviously it could just as easily be Saxon or a variety of
Indeed, I am using Xalan.
>More than the actual applications you plan to use I was meaning more
>along the lines of what type of application you are planning to build.
I am trying to stabilize my theoretical concepts. I am playing with
XSLT in order to learn its features but I do not have to build any
specific application right now.
>However, Oleg (and hes someone who knows a great deal in this area)
>brings up a very good point and you really should consider his council
>in this matter. It doesnt seem you are too worried about the
>internals of the transformation process (or have I misunderstood?)
Actually, this is what I am interested in. I am sure that it will
help me in the future if I understand how XSLT processors work (even if
I cannot see the benefits right now)
>understanding what happens on the inside will aid your decision on
>what format is best to pass the transformation engine. The chances
>are mighty good that your XSLT processor will accept a DOM document
>object but then optimize this to something more to its liking. As
>such, if you can save it some steps by using SAX throughout then
>you're going to find some performance gains.
Everything is clear for me. I did not know that XSLT processor have
their own internal representation of XML documents. That changes the
landscape quite dramatically. It also makes sense because a lot of DOM
functionality is not required by an XSLT processor (like changing the
original XML instance)
>In every transformation process
>exists a tree building process, a stylesheet compilation process, and
>a transformation process. If the first two processes can use data
>with an existing in-memory representation or a pre-compiled stylesheet
>then all thats really left is performing the transformation and your
>good to go.
1. tree building
2. stylesheet compilation
I'll surely remember this.
>> I will look into it. If XOM is another in-memory representation of
>>XML that is more memory - efficient than DOM then this could be very
>I think you might find a nice middle ground in XOM.