- 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, norm -- Norman Walsh XML Standards Architect Sun Microsystems, Inc.
Received on Monday, 24 July 2006 19:51:15 UTC