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

Re: p:pipeline

From: Jeni Tennison <jeni@jenitennison.com>
Date: Tue, 25 Jul 2006 21:50:40 +0100
Message-ID: <44C68420.8040400@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Norm,

Norm Walsh wrote:
> 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.

Sure. But it's the same amount of work that you have to do in a similar 
situation in standard programming languages. If you have a chunk of XSLT 
code in a template, you can't just wrap it in a <xsl:template> to make 
it callable from elsewhere, you have to pull it out to become a sibling 
of the other templates.

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

In standard programming languages, users tend to use naming conventions 
to distinguish between the functions that other users might want to 
reuse and those that are behind the scenes. I don't see why they can't 
do the same with a pipeline language.

At the end of the day, I think we want to have single files that hold 
multiple sibling invokable pipelines. We might have sub-pipelines as 
well (that are only usable within the pipeline in which they're 
declared), but if we do, we're only adding an extra feature that I don't 
think we really need in v1.0.

Cheers,
Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Wednesday, 26 July 2006 08:04:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:48 GMT