Re: p:pipeline

Jeni Tennison wrote:
> I don't understand (I said no nested pipelines). If someone has a
> pipeline document at foobar.xp like:
> 
> <p:pipelines xmlns:p="...">
>   <p:pipeline name="foo">
>     ...
>   </p:pipeline>
>   <p:pipeline name="bar">
>     ...
>   </p:pipeline>
> </p:pipelines>
> 
> then you can use either the 'foo' or 'bar' pipeline by including
> foobar.xp into your pipeline document, and referencing them in a step:
> 
> <p:pipelines xmlns:p="...">
>   <p:import href="foobar.xp" />
>   <p:pipeline name="baz">
>     ...
>     <p:step kind="foo">...</p:step>
>     <p:step kind="bar">...</p:step>
>     ...
>   </p:pipeline>
> </p:pipelines>

I tend to like this approach, but I belive that most of the times users 
won't need to define multiple pipelines in the same file. It might be a 
15% case, probably. For the other cases (85%), the user shouldn't need 
to type extra tags (i.e. <p:pipelines>). And this feature would require 
for us to define which pipeline was triggered automatically (like 
makefile's and ant's target "all"). Do we really need to cope with these 
issues to ease a 15%-case? I'm not sure.

> As I said in my previous mail, I don't (at the moment) see the
> requirement for pipelines that are local to other pipelines. Why not
> have *only* 'global' pipelines? (Analogy with XSLT: we don't let people
> define templates inside other templates or functions inside other
> functions.)

I believe local pipelines are analog to XSLT's named templates and 
functions, as these may be called inside other templates.


> If you have a bunch of components that you use regularly, you can put
> all the definitions in a pipeline module and import it into other
> pipeline modules.
> 
> If we do have a language for declaring non-pipeline components, we're
> going to have to address issues such as:
> 
>  - providing mechanisms for pointing to definitions in different
>    programming languages, including handling things like classpaths
> 
>  - dealing with situations where different definitions are provided in
>    different programming languages, and enabling the implementation to
>    choose between them
> 
> This could get quite sticky... Perhaps the fact that you used an
> extension attribute (my:javaClass) indicates that you think only the
> basics should be part of XProc, and the rest implementation-defined?

If we allow implementation-specific issues to be configured in this type 
of files, maybe we should leave it outside the scope of xproc.

Cheers,
Rui