W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > April 2006

Re: Auxiliary documents

From: Alessandro Vernet <avernet@orbeon.com>
Date: Thu, 13 Apr 2006 00:38:33 -0700
Message-ID: <4828ceec0604130038g36135294w348863fa99fd795e@mail.gmail.com>
To: public-xml-processing-model-wg@w3.org
On 4/12/06, Norman Walsh <Norman.Walsh@sun.com> wrote:
> Oooh! I don't know. That strikes at the heart of the "foward chaining"
> vs. "backward chaining" question. My current thinking is that the
> pipeline processor should be able to look at the pipeline and
> determine an order before it begins execution.


A static execution order, that can be determined just by "looking at a
pipeline", makes the pipeline language simpler. This is good thing.
However, it prevents an implementation from performing clever caching.
In my experience, because of the use cases I am working with, caching
is very important.

For instance: parsing and analyzing XSLT is expensive, so it is
reasonable for an implementation to cache the internal representation
of a stylesheet. This is to avoid the same stylesheet to be analyzed
every time it is executed.

Consider the pipeline drawn in the attached diagram. The first steps
reads a stylesheet from a URI. It is fairly easy in this case for the
implementation to do caching without impacting how the pipeline is

Now let's assume this implementation is able to do caching for the
second XSLT step: it determines somehow that none of the input of
"XSLT Step 1" have changed, that the stylesheet does not have any side
effect, and so that it can use a cached stylesheet for the second
step. In this case since we don't need the output of step 1, it would
make sense to just not execute it.

I think that an implementation should be allowed to implement this
type of behavior.

This is an issue that we might want to discuss, so I create an entry
in Bugzilla:

Blog (XML, Web apps, Open Source):

(image/png attachment: caching-xslt.png)

Received on Thursday, 13 April 2006 07:38:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:39 UTC