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

Re: p:pipeline

From: Rui Lopes <rlopes@di.fc.ul.pt>
Date: Mon, 24 Jul 2006 11:26:34 +0100
Message-ID: <44C4A05A.3060002@di.fc.ul.pt>
To: public-xml-processing-model-wg@w3.org
Jeni Tennison wrote:
> I'd say it was like defining a *local* function in some programming 
> language (i.e. a function within a function).

Yes, I agree.

> I don't think we need to worry about 1) if we have support for 2): it's 
> always an option for users to write a separate 'called pipeline' if they 
> want to repeat processing logic inside the main pipeline.

I like that approach, but for some cases (albeit not knowing the 
possible percentage), having the ability to define an inner pipeline 
might be useful.

> FWIW, this is my favoured design at the moment:
> 1. All components are identified through a QName
> 2. Pipelines are components (and are thus identified by a QName, and 
> called using the <p:step> syntax)

If we say pipeline QName's have to be explicitly bound to a namespace to 
avoid naming conflict, I'll support this idea. This becomes an issue in 
the following scenario:

1) pipeline author A creates a (sub)pipeline named "foo", and it 
compiles and runs ok in its xproc implementation;

2) pipeline author B has another xproc implementation that has support 
for a custom component named "foo";

3) B tries to run A's pipeline. *halt and catch fire* on component 
naming conflict. Therefore, interoperability issues.

> 3. Pipelines are all defined at the same level (no nested pipelines), 
> with a <p:pipelines> wrapper (if necessary; if a document only defines 
> one pipeline, then it shouldn't be necessary)

I'd prefer having just one root tag for xproc, whether it's p:pipelines 
or p:pipeline, and allow "privately defined" sub-pipelines.

> 4. We have a <p:import> to import pipeline definitions kept in separate 
> physical files


> 5. Pipeline invocation uses a component library, a component name, and a 
> set of inputs and parameters. The component library includes the 
> built-in components, pipeline components defined in XProc files, and 
> implementation-defined components (which might be web services etc.)

Yes, but still allowing the definition and usage of pipelines inside a 
pipeline or in a separate file (without defining in the component 
library). It will ease interoperability (as users may have their own 
component library properly configured for their purposes).


Received on Monday, 24 July 2006 10:26:48 UTC

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