Re: p:pipeline

Jeni Tennison wrote:
>> 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?

I was talking about two pipelines defined in the same document (not on 
another document), whether through sibling or parent/child relations. 
Your solution of defining all pipelines separately in the same document 
achieves the same result.


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

Maybe, for simple cases, users won't have the need for defining a 
pipeline's name, as they may define just one straight-through pipeline :)

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

Requiring both to have namespaces may do the trick. Less conflicts, more 
interoperability.

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

Good point. I like this approach :)

Cheers,
Rui

Received on Monday, 24 July 2006 14:27:24 UTC