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

Re: p:pipeline

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 21 Jul 2006 14:38:49 +0100
Message-ID: <44C0D8E9.7060107@jenitennison.com>
To: public-xml-processing-model-wg@w3.org


Rui Lopes wrote:
> Norman Walsh wrote:
>> True. But requiring all pipelines to be in external files strikes me
>> as analagous to requiring all xsl:templates to be in separate files.
> I've been thinking lately about the issue of including and reusing 
> pipelines. Is this e-mail I'll be using the expressions "main pipeline" 
> and "called pipeline" to avoid potentially ambiguous interpretations. I 
> believe that we should be aware of three sides for reusing pipelines:
> 1) inline specification in the "main pipeline" document: useful when we 
> don't want to repeat a sequence of steps/processing logic inside our 
> "main pipeline" document. This is something like defining a function on 
> some programming language;

I'd say it was like defining a *local* function in some programming 
language (i.e. a function within a function).

> 2) include a "called pipeline" into a "main pipeline": useful when 
> creating more complex processing applications, whether focusing on 
> modularization for defining "called pipeline" libraries, or just to ease 
> management and maintenance of bigger pipeline-based projects. This is 
> similar to using a C preprocessor or an XSLT include directive;
> 3) use an external "called pipeline": useful when some pipeline logic is 
> executed elsewhere, whether for resource-intensive computations or using 
> a pipeline service provided by someone else. This is akin to calling a 
> web-service.

I don't think we need to worry about 1) if we have support for 2): it's 
always an option for users to write a separate 'called pipeline' if they 
want to repeat processing logic inside the main pipeline.

FWIW, this is my favoured design at the moment:

1. All components are identified through a QName

2. Pipelines are components (and are thus identified by a QName, and 
called using the <p:step> syntax)

3. Pipelines are all defined at the same level (no nested pipelines), 
with a <p:pipelines> wrapper (if necessary; if a document only defines 
one pipeline, then it shouldn't be necessary)

4. We have a <p:import> to import pipeline definitions kept in separate 
physical files

5. Pipeline invocation uses a component library, a component name, and a 
set of inputs and parameters. The component library includes the 
built-in components, pipeline components defined in XProc files, and 
implementation-defined components (which might be web services etc.)


Jeni Tennison
Received on Friday, 21 July 2006 13:38:59 UTC

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