Re: p:pipeline

/ Alessandro Vernet <avernet@orbeon.com> was heard to say:
| OK, I see. The only thing I would have against pipelines declared
| inside pipelines ("inner pipelines") is that I haven't seen so far use
| cases that would require inner pipelines, and in the absence of such
| use cases my preference is to keep this construct out of the language
| for that sake of simplicity.

Are you saying you don't see any need for sub-pipelines? I'd be
surprised if there was objection, in principle, to allowing pipeline
authors to modularize and reuse portions of a pipeline.

It seems to me there are four choices:

1. No sub-pipelines at all.

2. Only external sub-pipelines.

3. Some new container element for sub-pipelines:

   <p:pipelines>
     <p:pipeline name="locateSchema">...</p:pipeline>
     <p:pipeline name="checkDocBook">...</p:pipeline>
     <p:pipeline name="xform2HTML">...</p:pipeline>
     <p:pipeline name="xform2PDF">...</p:pipeline>
     <p:pipeline name="main">...</p:pipeline>
   </p:pipelines>

4. Allow nested sub-pipelines:

   <p:pipeline name="main">
     <p:pipeline name="checkDocBook">
       <p:pipeline name="locateSchema">...</p:pipeline>
     </p:pipeline>
     <p:pipeline name="xform2HTML">...</p:pipeline>
     <p:pipeline name="xform2PDF">...</p:pipeline>
     ...
   </p:pipelines>

The only argument I can see for option 1 is that it is in some
respects the simplest choice from a language design perspective.
However, it will make actual pipeline documents much more cumbersome
so I think it's a false simplicity. I think we need a sub-pipeline
construct.

Option 2 is in some respects the bare minimum needed. Certainly, users
will expect to be able to call pipelines in external documents. But
again, it seems to impose considerable pain on authors so I'd prefer
to allow some form of nesting.

Of choices 3 and 4, I have a marginal preference for 4 but I could
certainly live with 3. I like the recursive nature of 4 and the fact
that modularizing the checkDocBook pipeline doesn't require exposing
the locateSchema pipeline in the "public" API.

I concede that 3 has the advantage that you could imagine an xproc
processor starting with any of the pipelines in the single document
whereas in option 4, you really only get to start with the outer most
pipeline; so if you wanted to be able to start with xform2HTML,
xform2PDF, or main, you'd have to store them in three separate files.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.