- From: Alessandro Vernet <avernet@orbeon.com>
- Date: Wed, 22 Mar 2006 19:23:48 -0800
- To: public-xml-processing-model-wg@w3.org
On 3/22/06, Jeni Tennison <jeni@jenitennison.com> wrote: > Plus I don't think that allowing a pipeline to generate another pipeline > is necessarily a good idea: I think that the pipeline language should be > powerful enough for most processing tasks without having to resort to > auto-generated pipeline specifications. It would be good to see examples > where you've found it necessary to use them. Jeni, We have seen cases where being able dynamically create a pipeline is useful. But before I expose one case, I should say that: 1) I would like the capability to be there, but I agree with you: in most cases generating a pipeline dynamically is a "bad thing", it should be avoided, and the language should be powerful enough to handle most of the use cases without requiring runtime pipeline generation. 2) The question of whether there are valid use cases or not is almost anecdotal for our discussion here, as we all agree that we don't want to prevent an pipeline engine from providing a component which run the pipeline engine itself. But it is an interesting question nevertheless :). So: This happens when for a given problem space there is a way to express a "solution" in a natural XML application and that a document conforming to this XML application can be transformed into a pipeline that "runs" the solution. An example is the controller configuration that can be found in most web frameworks (struts-config.xml for Struts). With the right components available in the pipeline engine, you can automatically transform the configuration into a pipeline. So you can write the framework controller as a pipeline that run an XSLT transformation (configuration to pipeline) and run the generated pipeline. Alex -- Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/
Received on Thursday, 23 March 2006 03:23:52 UTC