Re: p:pipeline

Jeni Tennison wrote:
> I think it's unreasonable to require that every invokable pipeline 
> definition should be in a separate file. If we want several invokable 
> pipeline definitions in a single file, we need to have a wrapper for 
> them. I'm not saying that every XProc document should have a 
> <p:pipelines> wrapper, just that it needs to be a possibility.

If sub-pipelines are allowed to be defined inside a pipeline, they 
shouldn't be visible on for invocation outside of their scope, as 
discussed previously.

> You seem to be making the assumption that a user should be able to 
> invoke a pipeline by simply pointing at an XProc document. I'm making 
> the assumption that a user invokes a pipeline by supplying a *QName* and 
>  (any number of) XProc documents.

Yes, I made that assumption. It doesn't make much sense that if a single 
pipeline is specified, it has to be referenced explicitely in the 
execution environment.

> My opinion is that you will *usually* want to have multiple pipelines 
> defined in a single file, for modularity and reusability. [...]

We may also argue that, for modularity and reusability, multiple 
pipelines should be defined in different files. I believe both points 
are valid, like Java's motto of "one file = one class" vs. C#'s "one 
file = (possibly) multiple classes".


>> I believe local pipelines are analog to XSLT's named templates and 
>> functions, as these may be called inside other templates.
> 
> 
> These may be *called* from within other templates, but they can't be 
> *defined* within other templates. Putting <p:pipeline> within 
> <p:pipeline> is like defining a template within another template. Using 
> <p:step> to invoke another pipeline from within a pipeline is like 
> calling a template within another template.

Yes, good point. But the main issue on your approach regarding multiple 
pipelines in one file, IMO, is that it will allow two document roots 
*with different semantics* for  an xproc document: <p:pipeline> and 
<p:pipelines>. I'm not against it, neither in favour. But it has the 
same feeling as stating that an xslt document may begin with 
<xsl:template> or <xsl:stylesheet>.


> I'm somewhat equivocal. There's an advantage in having 
> <p:declare-component> as part of XProc in that it means *any* XProc 
> processor (or indeed XML editor) can check that the XProc document 
> itself is constructed correctly (calls each component with the correctly 
> named inputs and outputs). It's then an error if an implementation 
> either doesn't support that component (doesn't have a definition for it) 
> or has a different signature for the component than that given in the 
> XProc file.

So you're saying that it has a more schema-ish flavour, instead of 
config-ish?


Cheers,
Rui