Re: XProc: An XML Pipeline Language

Norman Walsh wrote:

> If your pipeline declares that it has two outputs, and O1 and O2b are
> bound to those outputs, then they are both outputs of the pipeline.
> 

I agree. But that's not the same thing as "The outputs from the last 
component constitute the outputs of the pipeline itself", or am I 
missing anything else?

Maybe something along the lines of "The outputs of the pipeline are 
defined by explicitly declaration or implicitly bound to the last 
component's outputs."


> If you want O1 and/or O2b to be serialized, but not delivered as
> pipeline output, then you must bind them to a serializer:
> 
>              O1 -> Save
>             /
>  I1 -> XSLT
>             \
>              O2 -> XSLT -> O2b -> Save
> 
> Naturally, you could save one and send the other along as the pipeline
> output if you wanted.
> 
> In your original example above, if O1 and O2b aren't bound to the
> pipeline outputs, then your pipeline has a static error. We've said
> you can't have outputs that flow onto the floor.
> 
> Does that help?

Yes it does.


> 
> I see another problem with this pipeline:
> 
>              O1
>             /
>  I1 -> XSLT
>             \
>              O2
> 
> That's not how XSLT works. XSLT has two inputs and one output:
> 
> 
>  Stylesheet
>             \
>               XSLT -> Output
>             /
>  Document
> 

Silly me... You're right :)


> I think we'll need a component to decompose the multiple output
> documents into one or more (if you want to get one for example).
> 
> I can imagine a "MatchBaseURI" component that takes as input a
> sequence of documents and outputs two sequences, one containing all
> the documents that match a particular URI and one that contains all
> the ones that don't match:
> 
> <p:pipeline>
>   <p:input name="stylesheet"/>
>   <p:input name="document"/>
> 
>   <p:step name="xslt">
>     <p:input name="stylesheet" select="$stylesheet"/>
>     <p:input name="document" select="$document"/>
>     <p:output name="results"/>
>   </p:step>
> 
>   <p:step name="match-base-uri">
>     <p:parameter name="match">.*/MANIFEST.xml$</p:parameter>
>     <p:input name="results"/>
>     <p:output name="matched"/>
>     <p:output name="notmatched"/>
>   </p:step>
> 
>   <p:step name="save">
>     <p:input name="notmatched"/>
>   </p:step>
> 
>   <p:step name="xslt">
>     <p:input name="stylesheet" href="manifest.xsl"/>
>     <p:input name="document" select="$matched"/>
>     <p:output name="manifest-result"/>
>   </p:step>
> 
>   <p:step name="save">
>     <p:parameter name="href" select="'manifest.html'"/>
>     <p:input name="document" select="$manifest-result"/>
>   </p:step>
> </p:pipeline>
> 
> That pipeline processes the input document with the specified stylesheet,
> then splits the result document named MANIFEST.xml off and serializes
> everything else. It performs another transformation on the manifest and
> serializes the result to manifest.html.
> 

I like that solution as it dismisses explicit iteration constructs. On a 
sidenote, in your example "match" is regex-based, right?


Cheers,
Rui