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 Adrian Herscu <ad...@gmail.com> on 2010/06/30 18:15:45 UTC

xsl/xalan problem

Hi all,

Consider the following scenario:

+-----------+   +----------------+   +------------+
| Input XML |-->| XSLT Processor |-->| Output XML |
+-----------+   +----------------+   +------------+
                  ^              ^
                  |              |
+----------------+              +-----------------+
|    Input XSL   |              |  Runtime Input  |
+----------------+              +-----------------+

The Output XML depends on three sources:
  1. Input XML
  2. Input XSL
  3. ...and on the Runtime Input

Currently, I am getting the Runtime Input using a specially designed 
extension function. The problem with this approach is that the XSLT 
Processor sometimes calls my extension function too many times. I have 
been told that this may happen if the XSLT Processor decides to optimize 
some of the XSL templates and that I cannot control this behavior. Is 
there a better approach?

Thanks for your help,
Adrian.

Re: xsl/xalan problem

Posted by ke...@us.ibm.com.
Another strategy is to arrange your system to do all the 
calculations/retrieval once and put the data into a secondary document, 
retrieved via the document() function -- which, if you plug in an 
appropriate entity resolver, can be done without having to spend time 
generating and re-parsing XML syntax.

Another is to have an extension which does all that and returns a Java 
object which contains the results, then pass that to additional extensions 
to retrieve the data.  That way the retrievals are relatively inexpensive 
and stateless, so reordering or repeating them is pretty much harmless.

Another is to have your environment do the precalculations and pass the 
values in as stylesheet parameters. Then the stylesheet just has to 
declare those parameters and refer to the values by name, much as if they 
were stylesheet variables.


______________________________________
"... 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)



From:
Michael Ludwig <mi...@gmx.de>
To:
xalan-j-users@xml.apache.org
Date:
06/30/2010 02:27 PM
Subject:
Re: xsl/xalan problem



Adrian Herscu schrieb am 30.06.2010 um 20:03 (+0300):
> 
> Then how would you advise to implement such a system?
> I really need to get some input during the transformation.

Depends on what kind of input you have in mind and what's practical to
do. One strategy is to append your runtime data (user input, database
output, whatnot) to your main XML document which you construct in
memory, and then have XSL code handle it as you see fit.

/root
  /data
    ...
  /data
    ...
  /my:runtime-input -- All your extra input goes here.
    /my:object-A
      ...
    /my:object-B
      ...
    /my:more-context

-- 
Michael Ludwig

Re: xsl/xalan problem

Posted by Michael Ludwig <mi...@gmx.de>.
Adrian Herscu schrieb am 30.06.2010 um 20:03 (+0300):
> 
> Then how would you advise to implement such a system?
> I really need to get some input during the transformation.

Depends on what kind of input you have in mind and what's practical to
do. One strategy is to append your runtime data (user input, database
output, whatnot) to your main XML document which you construct in
memory, and then have XSL code handle it as you see fit.

/root
  /data
    ...
  /data
    ...
  /my:runtime-input -- All your extra input goes here.
    /my:object-A
      ...
    /my:object-B
      ...
    /my:more-context

-- 
Michael Ludwig

Re: xsl/xalan problem

Posted by Adrian Herscu <ad...@gmail.com>.
Thanks for the fast reply :)

Then how would you advise to implement such a system?
I really need to get some input during the transformation.

Adrian.

On 6/30/2010 7:52 PM, keshlam@us.ibm.com wrote:
>   XSLT is a functiional language. The order and frequency of execution,
> including execution of extensions, is not guaranteed by XSLT, or by
> Xalan, and depends on the details of code optimization and execution.
>
> You can constrain order by creating data dependencies. If each extension
> call is passed data from a previous extension call, that will force them
> to be executed in that sequence.
>
> You really can't constrain frequency. You are strongly advised not to
> write stateful extensions. Keep state in data.
>
>
> ______________________________________
> "... 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
> <http://www.ovff.org/pegasus/songs/threes-rev-11.html> )
>
>
> From: 	Adrian Herscu <ad...@gmail.com>
> To: 	xalan-j-users@xml.apache.org
> Date: 	06/30/2010 12:20 PM
> Subject: 	xsl/xalan problem
>
>
>
>
>
> Hi all,
>
> Consider the following scenario:
>
> +-----------+ +----------------+ +------------+
> | Input XML |-->| XSLT Processor |-->| Output XML |
> +-----------+ +----------------+ +------------+
> ^ ^
> | |
> +----------------+ +-----------------+
> | Input XSL | | Runtime Input |
> +----------------+ +-----------------+
>
> The Output XML depends on three sources:
> 1. Input XML
> 2. Input XSL
> 3. ...and on the Runtime Input
>
> Currently, I am getting the Runtime Input using a specially designed
> extension function. The problem with this approach is that the XSLT
> Processor sometimes calls my extension function too many times. I have
> been told that this may happen if the XSLT Processor decides to optimize
> some of the XSL templates and that I cannot control this behavior. Is
> there a better approach?
>
> Thanks for your help,
> Adrian.
>
>

Re: xsl/xalan problem

Posted by ke...@us.ibm.com.
XSLT is a functiional language. The order and frequency of execution, 
including execution of extensions, is not guaranteed by XSLT, or by Xalan, 
and depends on the details of code optimization and execution.

You can constrain order by creating data dependencies. If each extension 
call is passed data from a previous extension call, that will force them 
to be executed in that sequence.

You really can't constrain frequency. You are strongly advised not to 
write stateful extensions. Keep state in data.


______________________________________
"... 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)



From:
Adrian Herscu <ad...@gmail.com>
To:
xalan-j-users@xml.apache.org
Date:
06/30/2010 12:20 PM
Subject:
xsl/xalan problem



Hi all,

Consider the following scenario:

+-----------+   +----------------+   +------------+
| Input XML |-->| XSLT Processor |-->| Output XML |
+-----------+   +----------------+   +------------+
                  ^              ^
                  |              |
+----------------+              +-----------------+
|    Input XSL   |              |  Runtime Input  |
+----------------+              +-----------------+

The Output XML depends on three sources:
  1. Input XML
  2. Input XSL
  3. ...and on the Runtime Input

Currently, I am getting the Runtime Input using a specially designed 
extension function. The problem with this approach is that the XSLT 
Processor sometimes calls my extension function too many times. I have 
been told that this may happen if the XSLT Processor decides to optimize 
some of the XSL templates and that I cannot control this behavior. Is 
there a better approach?

Thanks for your help,
Adrian.