- From: Alessandro Vernet <avernet@orbeon.com>
- Date: Thu, 13 Apr 2006 00:38:33 -0700
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <4828ceec0604130038g36135294w348863fa99fd795e@mail.gmail.com>
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. Norm, 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 executed. 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: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3118 Alex -- Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/
Attachments
- image/png attachment: caching-xslt.png
Received on Thursday, 13 April 2006 07:38:38 UTC