Re: p:pipeline

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

Yes.

> 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).


Cheers,
Rui