- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Tue, 25 Jul 2006 21:50:40 +0100
- 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 UTC