XSLT is defined as a functional language.  XSLT processors may take
advantage of that to rewrite/reorder the code for better efficiency. That
may result in extension functions occuring in a different order than you
intended, which makes side-effects problematic at best. So it's always
better if extensions are themselves functional.

It is sometimes possible to set things up so a value returned from one
extension is passed to another, creating a data dependency at the XSLT
level and establishing order of execution between them. But maintaining
that dataflow can become complicated, especially since XSLT 1.0 has limited
ability to return values back up the call chain.

It may be work looking again to see if you can come up with a native XSLT
solution, or at least one where all the related extension operations are
local enough to be threaded together by data dependencies.

______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
  -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish
(http://www.ovff.org/pegasus/songs/threes-rev-11.html)

Reply via email to