You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Tomas Studva <ts...@gmail.com> on 2007/10/10 22:59:28 UTC
ElemApplyTemplates implementation
Hi,
I am developing an incremental(not in meaning as is Xalan) XSLT
processor called
Darwin(http://tstudva.googlepages.com/darwin-anincrementalxsltprocessor),
based on Xalan trunk.
I have some questions about Xalan implementation details. As I
understand every template element has execute method, which is called to
execute template element including children (direct). But sometimes
there is a difference.
1,
In ElemApplyTemplates when matching node against template there is code
case DTM.TEXT_NODE:
// if(rth.m_elemIsPending ||
// rth.m_docPending)
// rth.flushPending(true);
transformer
.pushPairCurrentMatched(
sroot
.getDefaultTextRule(),
child);
transformer
.setCurrentElement(sroot
.getDefaultTextRule());
//
dtm.dispatchCharactersEvents(child,
// chandler,
false);
dtm.dispatchCharactersEvents(
child, rth,
false);
transformer.popCurrentMatched();
continue;
There is some default template, sroot.getDefaultTextRule(), but it is
not executed and instead direct call to
dtm.dispatchCharactersEvents(child, rth,false); is performed.
Why?(optimization?)
2, In ElemApplyTemplates after template is found, is set on stacks and
so on and params are processed, follows code with comment
// And execute the child templates.
// Loop through the children of the template,
// calling execute on
// each of them.
for (ElemTemplateElement t = template.m_firstChild; t != null; t =
t.m_nextSibling) {
xctxt.setSAXLocator(t);
try {
transformer
.pushElemTemplateElement(t);
t.execute(transformer,
null);
} finally {
transformer
.popElemTemplateElement();
}
}
which directly executes children of matched template insted of executing
template. Why?
PS:Same mail I have sent on xalan dev mailing list, but I haven't
received any response.
Thanks for help, Xalan fan :) Tomas Studva
Re: ElemApplyTemplates implementation
Posted by Tomas Studva <ts...@gmail.com>.
David Bertoni wrote / napísal(a):
> Tomas Studva wrote:
>
> Xalan-C does not rely on recursion and the processor stack to execute
> stylesheets. Instead, it simply walks the stylesheet tree
> iteratively, figuring out what needs to be executed next. If it does
> need to save some small bit of context, it does that on a "stack"
> that's kept in dynamically allocated memory.
>
> This has a number of advantages:
>
> 1. There's a much smaller chance that stylesheet execution will
> consume the entire processor stack.
> 2. Because there is only a small amount of context to be saved, and
> it's not saved all of the time, execution is faster and consumes less
> memory. For example, just the overhead of the C++ stack frame is often
> greater than than any local context that needs to be saved.
> 3. Execution can be interrupted at any time by simply breaking out of
> a loop, rather than unwinding a large number of stack frames.
> 4. It's trivial to restart execution at the point it was interrupted
> by just re-entering the loop starting with the last template executed.
>
> I'm not sure what you mean by "incremental," because I don't see how
> it relates to the data model, unless you mean building the source tree
> incrementally, which is a very different thing from executing the
> transformation incrementally.
>
> Dave
I understand, iterative execution. No I don't mean incremental in a way
of reading source incrementally, what is usable for big size sources in
databases. I mean what you get when you type "incremental xslt" in
google. Or look at
http://tstudva.googlepages.com/darwin-anincrementalxsltprocessor or in
design of Darwin
http://www.javaforge.com/proj/doc/details.do?doc_id=36525. I don't
understand Xalan execution in details and that is problem for me. Some
good documentation would help. On Xalan page in design doc, there is
written, transformation is performed mainly in transform package. There
is transformer, the main class, and there is performed iterative
execution using self(on heap) managed stacks. But some part of
execution is performed in ElemTemplatesElement, so I am confused. My
second big question is if I choosed good to start with Xalan trunk and
not with any branch.
Re: ElemApplyTemplates implementation
Posted by David Bertoni <db...@apache.org>.
Tomas Studva wrote:
> Hi Dave,
> what is an iterative stylesheet execution model? I can look into Xalan-C
> code, but it is time consuming (so I won't look) and I need java xslt
> processor. I have explored Xalan-J, Saxon and hmm I don't remember the
> third. The main problem with implementation of incremental one based on any
> XSLT processor is their internal document model. I can work with DOM style
> document models only. Xalan has clear architecture, but optimization are
> everywhere, so there is DTM and special cases. Also Xalan supports so many
> format, I will only DOM. I've made design of Darwin based on Xalan but
> special case like two mentioned, breaks my design.
Xalan-C does not rely on recursion and the processor stack to execute
stylesheets. Instead, it simply walks the stylesheet tree iteratively,
figuring out what needs to be executed next. If it does need to save some
small bit of context, it does that on a "stack" that's kept in dynamically
allocated memory.
This has a number of advantages:
1. There's a much smaller chance that stylesheet execution will consume the
entire processor stack.
2. Because there is only a small amount of context to be saved, and it's
not saved all of the time, execution is faster and consumes less memory.
For example, just the overhead of the C++ stack frame is often greater than
than any local context that needs to be saved.
3. Execution can be interrupted at any time by simply breaking out of a
loop, rather than unwinding a large number of stack frames.
4. It's trivial to restart execution at the point it was interrupted by
just re-entering the loop starting with the last template executed.
I'm not sure what you mean by "incremental," because I don't see how it
relates to the data model, unless you mean building the source tree
incrementally, which is a very different thing from executing the
transformation incrementally.
Dave
Re: ElemApplyTemplates implementation
Posted by Tomas Studva <ts...@gmail.com>.
Hi Dave,
what is an iterative stylesheet execution model? I can look into Xalan-C
code, but it is time consuming (so I won't look) and I need java xslt
processor. I have explored Xalan-J, Saxon and hmm I don't remember the
third. The main problem with implementation of incremental one based on any
XSLT processor is their internal document model. I can work with DOM style
document models only. Xalan has clear architecture, but optimization are
everywhere, so there is DTM and special cases. Also Xalan supports so many
format, I will only DOM. I've made design of Darwin based on Xalan but
special case like two mentioned, breaks my design.
Tomas Studva
David Bertoni wrote:
>
> You would have to trace through the alternate code path to figure this
> out,
> but perhaps it's an optimization as well. Someone who is more familiar
> with Xalan-J might know better.
>
> If you have any knowledge of C++, you might want to look at Xalan-C, which
> implements an iterative stylesheet execution model. With some
> limitations,
> it could easily be adapted to an incremental model, since the execution
> could be interrupted with each "child" that is instantiated.
>
> One major limitation is that the evaluation of params and variables is not
> executed iteratively. Instead, they are executed recursively, because I'm
> not quite sure what the semantics of iteratively executing the evaluation
> of the params would be.
>
> Dave
>
>
--
View this message in context: http://www.nabble.com/ElemApplyTemplates-implementation-tf4603600.html#a13155655
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Re: ElemApplyTemplates implementation
Posted by David Bertoni <db...@apache.org>.
Tomas Studva wrote:
> Hi,
> I am developing an incremental(not in meaning as is Xalan) XSLT
> processor called
> Darwin(http://tstudva.googlepages.com/darwin-anincrementalxsltprocessor),
> based on Xalan trunk.
>
...
> In ElemApplyTemplates when matching node against template there is code
> case DTM.TEXT_NODE:
> // if(rth.m_elemIsPending ||
> // rth.m_docPending)
> // rth.flushPending(true);
> transformer
>
> .pushPairCurrentMatched(
> sroot
> .getDefaultTextRule(),
> child);
> .setCurrentElement(sroot
> .getDefaultTextRule());
> //
> dtm.dispatchCharactersEvents(child,
> // chandler,
> false);
>
> dtm.dispatchCharactersEvents(
> child, rth,
> false);
>
> transformer.popCurrentMatched();
> continue;
>
> There is some default template, sroot.getDefaultTextRule(), but it is
> not executed and instead direct call to
> dtm.dispatchCharactersEvents(child, rth,false); is performed.
> Why?(optimization?)
Probably, because the default text rule would just dispatch the characters
event. Xalan-C has a similar optimization.
>
> 2, In ElemApplyTemplates after template is found, is set on stacks and
> so on and params are processed, follows code with comment
> // And execute the child templates.
> // Loop through the children of the template,
> // calling execute on
> // each of them.
> for (ElemTemplateElement t = template.m_firstChild; t != null; t =
> t.m_nextSibling) {
> xctxt.setSAXLocator(t);
> try {
> transformer
>
> .pushElemTemplateElement(t);
> t.execute(transformer,
> null);
> } finally {
> transformer
>
> .popElemTemplateElement();
> }
> }
> which directly executes children of matched template insted of executing
> template. Why?
You would have to trace through the alternate code path to figure this out,
but perhaps it's an optimization as well. Someone who is more familiar
with Xalan-J might know better.
If you have any knowledge of C++, you might want to look at Xalan-C, which
implements an iterative stylesheet execution model. With some limitations,
it could easily be adapted to an incremental model, since the execution
could be interrupted with each "child" that is instantiated.
One major limitation is that the evaluation of params and variables is not
executed iteratively. Instead, they are executed recursively, because I'm
not quite sure what the semantics of iteratively executing the evaluation
of the params would be.
Dave
Re: ElemApplyTemplates implementation
Posted by Tomas Studva <ts...@gmail.com>.
Thanks for help Henry.
Now I know, that I understand code correctly(at least discussed) and can go
ahead with implementation. To say my feelings, I don't like optimizations :)
and I don't use them when gained value is very small. Like in case of having
small stack - don't worry or make it iterative or run java vm with bigger
size(I know it wasn't supported for a long time(1.2 - 1.6)).
Good luck and wish you the best of business.
Tomas Studva
--
View this message in context: http://www.nabble.com/ElemApplyTemplates-implementation-tf4603600.html#a13261058
Sent from the Xalan - J - Users mailing list archive at Nabble.com.
Re: ElemApplyTemplates implementation
Posted by Henry Zongaro <zo...@ca.ibm.com>.
Hi, Tomas.
Tomas Studva <ts...@gmail.com> wrote on 2007-10-10 04:59:28 PM:
> 1,
> In ElemApplyTemplates when matching node against template there is code
> case DTM.TEXT_NODE:
>
[HZ: Deleted code]
>
> There is some default template, sroot.getDefaultTextRule(), but it is
> not executed and instead direct call to
> dtm.dispatchCharactersEvents(child, rth,false); is performed.
> Why?(optimization?)
Yes, that's an optimization because that particular template rule is
invoked so often.
> 2, In ElemApplyTemplates after template is found, is set on stacks and
> so on and params are processed, follows code with comment
> // And execute the child templates.
> // Loop through the children of the template,
> // calling execute on
> // each of them.
[HZ: Deleted code]
> which directly executes children of matched template insted of executing
> template. Why?
It looks to me like somebody - Scott Boag very early on, probably - did
that to eliminate the extra step of recursively invoking the execute
method on the xsl:template element. I'm guessing it was done that way to
increase the amount of recursive processing that could be done without
causing a Java StackOverflowException.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro XSLT Processors Development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
Re: ElemApplyTemplates implementation
Posted by Henry Zongaro <zo...@ca.ibm.com>.
Hi, Tomas.
Tomas Studva <ts...@gmail.com> wrote on 2007-10-10 04:59:28 PM:
> 1,
> In ElemApplyTemplates when matching node against template there is code
> case DTM.TEXT_NODE:
>
[HZ: Deleted code]
>
> There is some default template, sroot.getDefaultTextRule(), but it is
> not executed and instead direct call to
> dtm.dispatchCharactersEvents(child, rth,false); is performed.
> Why?(optimization?)
Yes, that's an optimization because that particular template rule is
invoked so often.
> 2, In ElemApplyTemplates after template is found, is set on stacks and
> so on and params are processed, follows code with comment
> // And execute the child templates.
> // Loop through the children of the template,
> // calling execute on
> // each of them.
[HZ: Deleted code]
> which directly executes children of matched template insted of executing
> template. Why?
It looks to me like somebody - Scott Boag very early on, probably - did
that to eliminate the extra step of recursively invoking the execute
method on the xsl:template element. I'm guessing it was done that way to
increase the amount of recursive processing that could be done without
causing a Java StackOverflowException.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro XSLT Processors Development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com