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

Re: p:pipeline

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 24 Jul 2006 10:38:49 +0100
Message-ID: <44C49529.1040109@jenitennison.com>
To: public-xml-processing-model-wg@w3.org


Norm Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | FWIW, this is my favoured design at the moment:
> | 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)
> That's one choice. But it means you can't easily grab someone else's
> pipeline and stick it into yours (because it might already have it's
> own nested pipelines).

I don't understand (I said no nested pipelines). If someone has a
pipeline document at foobar.xp like:

<p:pipelines xmlns:p="...">
   <p:pipeline name="foo">
   <p:pipeline name="bar">

then you can use either the 'foo' or 'bar' pipeline by including
foobar.xp into your pipeline document, and referencing them in a step:

<p:pipelines xmlns:p="...">
   <p:import href="foobar.xp" />
   <p:pipeline name="baz">
     <p:step kind="foo">...</p:step>
     <p:step kind="bar">...</p:step>

> I'm inclined to say that a p:pipeline that occurs as a child of
> another p:pipeline is local to the parent p:pipeline and acts like a
> function definition when encountered (it's parsed and squirreled away
> somewhere but has no effect unless it's called by some p:step).

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

> | 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.)
> I think that's right.
> I'm still imagining that there'll be some XML vocabulary for defining
> the "signatures" of components. We'll publish a bunch which
> implementations must support (and maybe some that they can optionally
> support, if we must) but they're free to add their own. From a users
> point of view, a component is just a QName so whether it's a web
> service or not is irrelevant.


> I think we'll probably want to allow such declarations to occur in
> pipelines as well.
>   <p:pipeline name="my:pipe">
>     <p:declare-input ...
>     <p:declare-output ...
>     <p:declare-component name="my:ouiji"
>                          my:javaClass="com.nwalsh.xproc.OuijiBoard">
>       <p:declare-input ...
>       <p:declare-input ...
>       <p:declare-input ...
>       <p:declare-output ...
>     </p:declare-component>
>     <p:step kind="my:ouiji">
>       <p:input ...
>       <p:input ...
>       <p:input ...
>       <p:output ...
>     </p:step>
>   </p:pipeline>

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:

<p:pipelines xmlns:p="...">

   <p:declare-component name="my:ouiji"
     <p:declare-input ...
     <p:declare-input ...
     <p:declare-input ...
     <p:declare-output ...

   <p:pipeline name="my:pipe">
     <p:declare-input ...
     <p:declare-output ...

     <p:step kind="my:ouiji">
       <p:input ...
       <p:input ...
       <p:input ...
       <p:output ...


If you have a bunch of components that you use regularly, you can put
all the definitions in a pipeline module and import it into other
pipeline modules.

If we do have a language for declaring non-pipeline components, we're
going to have to address issues such as:

  - providing mechanisms for pointing to definitions in different
    programming languages, including handling things like classpaths

  - dealing with situations where different definitions are provided in
    different programming languages, and enabling the implementation to
    choose between them

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?


Jeni Tennison
Received on Monday, 24 July 2006 09:39:01 UTC

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