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

Re: Pipe/Flow Example

From: Alex Milowski <alex@milowski.org>
Date: Wed, 14 Jun 2006 10:30:01 -0700
Message-ID: <44904799.60608@milowski.org>
To: public-xml-processing-model-wg@w3.org

Alessandro Vernet wrote:

> 
> For instance, using your syntax, your example (I just added here an
> output with a primary="true" for symmetry):
> 
>    <pipe>
>        <input name="in.document" primary="true"/>
>        <input name="in.schema"/>
>        <input name="in.stylesheet"/>
>        <output name="out.transformed" primary="true"/>
>        <step name="validate">
>            <input name="schema" ref="in.document"/>
>        </step>
>        <step name="xslt">
>            <input name="stylesheet" ref="in.stylesheet"/>
>        </step>
>    </pipe>
> 
> could be written using the full syntax as:
> 
>    <flow>
>        <input name="in.document"/>
>        <input name="in.schema"/>
>        <input name="in.stylesheet"/>
>        <output name="out.transformed"/>
>        <step name="validate">
>            <input ref="in.document"/>
>            <input name="schema" ref="in.document"/>

This should be:

              <input name="schema" ref="in.schema"/>

>            <output label="validated"/>
>        </step>
>        <step name="xslt">
>            <input ref="validated"/>
>            <input name="stylesheet" ref="in.stylesheet"/>
>            <output ref="out.transformed"/>
>        </step>
>    </flow>

It is not clear to me that the translation will always be this easy.

> 
> If the <pipe> construct is syntactic sugar that we can add on top of a
> full syntax, however useful it is, my take is that should focus our
> effort first on a "full" or "non-abbreviated" syntax, before we tackle
> the <pipe> construct.

Actually, I think if we believe that we need such a construct, we should
start with it to assure that everything works properly.  In addition, 
one huge motivation is the fact that most of our use cases are
straight-through pipes (chains of single inputs to single outputs).

In addition, the pipe concept isn't an abbreviation.  It would be
a basic building block in that flows are orchestration of
pipes.

One possibility is that there are no such thing as steps in a flow.
Instead, the are pipes.

For example, the translation of my example into a flow with one step
each would be:

     <flow>
         <input name="in.document"/>
         <input name="in.schema"/>
         <input name="in.stylesheet"/>
         <output name="out.transformed"/>
         <pipe>
            <input ref="in.schema"/>
            <input ref="in.document" primary="true"/>
            <output name="validated"/>
            <step name="validate">
               <input name="schema" ref="in.schema"/>
            </step>
         </pipe>
         <pipe>
            <input ref="validated"/>
            <output name="out.transformed"/>
            <step name="xslt">
              <input name="stylesheet" ref="in.stylesheet"/>
           </step>
         </pipe>
     </flow>

Notice the pipes are orchestrated by chasing the ref and name attributes
on the input/output child elements of each pipe element.

Now, while this example is the more verbose version, you might actually
have multiple steps that are necessary to transform the document.  For
example:


     <flow>
         <input name="in.document"/>
         <input name="in.schema"/>
         <input name="in.stylesheet"/>
         <output name="out.transformed"/>
         <pipe>
            <input ref="in.schema"/>
            <input ref="in.document" primary="true"/>
            <output name="validated"/>
            <step name="validate">
               <input name="schema" ref="in.schema"/>
            </step>
         </pipe>
         <pipe>
            <input ref="validated"/>
            <output name="out.transformed"/>
            <step name="xinclude"/>
            <step name="xslt">
              <input name="stylesheet" href="version12version2.xsl/>
            </step>
            <step name="xslt">
              <input name="stylesheet" ref="in.stylesheet"/>
            </step>
         </pipe>
     </flow>

Ultimately, pipes can be use inside iteration, conditional, or peephole
constructs as *the* way in which steps are applied:

     <flow>
         <input name="in.document"/>
         <output name="out.transformed"/>
         <for-each select="/doc/section">
            <input ref="in.document"/>
            <output name="out.transformed"/>
            <pipe>
               <step name="xinclude"/>
               <step name="xslt">
                 <input name="stylesheet" href="version12version2.xsl/>
               </step>
               <step name="xslt">
                 <input name="stylesheet" ref="in.stylesheet"/>
               </step>
            </pipe>
         </for-each>
     </flow>

Here, the pipe's input and output are contextual and so
specifying them isn't necessary.  The result of the flow construct
'for-each' is the result of taking each 'section' element matched
on the input, apply the 'pipe' to it as the primary
input document where the matched element is the document
element, and replace the element with the result of that pipe.


--Alex Milowski
Received on Wednesday, 14 June 2006 17:30:14 GMT

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