Re: p:pipeline

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| 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.)

That would work too. If we say that all pipelines are global then the
guy with a working pipeline who decides to modularize a bit of it has
to change the outermost wrapper and move the hunk of code in question
up to be a sibling of the original pipeline. That seems like more work
than just wrapping the revant steps in a p:pipeline and calling it.

It also means that if the new pipeline gets modularized, it's
sub-pipelines will also be peers of the original "main" pipeline so
there's a measure of information hiding that will be lost.

| I wouldn't put them in a *pipeline*, but at the level of a pipeline
| library; declaring pipeline components and declaring other components
| ought to be at the same kind of level:

I agree. If we don't allow nested p:pipelines then it'd be silly to allow
p:declare-component inside p:pipeline.

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

Exactly, at least for V1. I'm thinking of them as roughly analagous to
XSLT extension functions.

                                        Be seeing you,
                                          norm

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