W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > July 2006

Re: p:pipeline

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Mon, 24 Jul 2006 15:51:02 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87vepmye6x.fsf@nwalsh.com>
/ 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,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Monday, 24 July 2006 19:51:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:40 UTC