- From: Fang, Andrew <afang@ptc.com>
- Date: Thu, 20 Apr 2006 11:11:12 -0400
- To: "Alessandro Vernet" <avernet@orbeon.com>, <public-xml-processing-model-wg@w3.org>
> > On 4/13/06, Norman Walsh <Norman.Walsh@sun.com> wrote: > > I don't see how the constraint that order be determined before > > execution begins impacts caching. I'm not suggesting that the > > components have to be bolted together so that each component is forced > > to parse everything. I just don't want the engine to have to back > > track to determine what component would need to be executed to create > > something. > > A constraint in the pipeline language on execution order would prevent > caching if it mandated in the example that I mentioned in my previous > email that XSLT Step 1 has to run before XSLT Step 2. It would prevent > the pipeline engine for cleverly avoiding to run XSLT 1 if it already > has its output "in cache". > Instead of having the pipeline implementation decide whether XSLT Step 1 should be run, how about have XSLT Step 1 itself decide whether it should run the transformation and simply return a cached result if nothing has changed from a previous run? From pipeline's point of view, the XSLT Step 1 has to run before XSLT Step 2, but in reality, XSLT Step 1 simply returns a previous cached result. The overhead should be minimal. Andrew
Received on Thursday, 20 April 2006 15:11:18 UTC