Re: p:pipeline

Rui,

Rui Lopes wrote:
> Jeni Tennison wrote:
>> 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.

Can you explain why/when?

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

Presumably you mean that you want every pipeline QName has to have a 
non-null namespace. I'm kinda OK with that, though I think that for 
simple cases it might be burdensome for users.

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

I think we can allow users to create pipelines whose QNames have no 
namespace while saying that implementation-defined components must have 
a namespace.

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

I was thinking of the definition at a spec level. If we say 
"implementations have a component library", then it's 
implementation-defined how that component library is set up by the user. 
A command line might be:

   myproc my:pipe -file foo.xp -in document=book.xml -out result=out/

where my:pipe is the name of the (pipeline) component to be used, "-file 
foo.xp" means "include the pipeline components declared in foo.xp in the 
component library", "-in document=book.xml" means "the 'document' input 
comes from book.xml", and "-out result=out/" means "put the 'result' 
output as files in the 'out' directory".

If you wanted to use a built-in component, you could do:

   myproc p:xslt -in document=book.xml -in stylesheet=docbook2html.xsl
          -out result=out/

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Monday, 24 July 2006 13:53:38 UTC