- From: Alessandro Vernet <avernet@orbeon.com>
- Date: Wed, 2 Aug 2006 18:04:19 -0700
- To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
Jeni, On 7/27/06, Jeni Tennison <jeni@jenitennison.com> wrote: > 1. It means pipeline definitions can be dynamically generated by other > pipelines, which means that pipelines can't be compiled. Yes: it means that pipeline definitions can be dynamically generated. But no, it does not mean that pipelines can't be compiled. Pipelines can always be compiled. The result from the compilation may of may not be reusable, depending if the pipeline has changed. For pipelines stored in separate files, a compiling engine needs to check if the file containing the pipeline has changed, whatever syntax we choose. If the pipeline is truly dynamically generated, say with XSLT, then the engine can either consider that it is different pipeline every time, or be a more "clever" and try to figure out if it has really changed. (We have implemented the latter in XPL.) > 2. Calling a pipeline becomes very difficult. The 'call-pipeline' > component needs to have a 'pipeline' input, an 'inputs' input, and an > 'outputs' output. All the inputs for the pipeline have to be defined > somehow within the 'inputs' input, which requires another complex > syntax. This is analogous to the problem we have with passing XSLT > parameters to an XSLT component. Calling a pipeline would not be more difficult than calling a stylesheet. If we have a construct we find good enough to run a stylesheet, why wouldn't it be good enough to run a pipeline? If calling pipelines happened much more frequently than calling stylesheets, one could argue that there could be some value in having a shortcut for that specific case. But in my experience, this is not the case, and calls to stylesheets in general happen more frequently that calls to pipelines. Alex -- Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/
Received on Thursday, 3 August 2006 01:04:29 UTC