RE: compound steps and primary inputs

If you don't specify any binding in p:iteration-source, it just reads
the data from the default readable port.

(Side note: I just noticed I was using "default/implicit readable input
port" in my previous e-mails. That is a nonsense and it should read
"default readable port")

Regards,
Vojtech 

> -----Original Message-----
> From: mozer [mailto:xmlizer@gmail.com] 
> Sent: Wednesday, September 24, 2008 3:49 PM
> To: Toman, Vojtech
> Cc: xproc-dev@w3.org
> Subject: Re: compound steps and primary inputs
> 
> Vojtech,
> 
> And what about p:iteration-source ? it *IS* the only input source of
> the for-each
> 
> Regards,
> 
> Xmlizer
> 
> 
> On Wed, Sep 24, 2008 at 3:30 PM,  <Toman_Vojtech@emc.com> wrote:
> > Compound steps, such as p:for-each or p:group (even p:pipeline) are
> > also their own declarations. That means that the 
> p:input/p:output elements
> > you specify on a compound step determine the signature of 
> the compound step
> > (and what will be the primary input/output ports, if any).
> >
> > p:for each does not allow you to specify an input port. 
> Unless you say
> > otherwise, it will read documents from the implicit 
> readable input port and
> > for each of the documents it executes the subpipeline. In 
> each iteration,
> > the document is available via the "curent" input port. This 
> input port is
> > created by the XProc processor and is only visible to the 
> subpipeline.
> 
> 
> 
> >
> > Compound steps that don't declare (or can't declare) an 
> input port are just
> > wrappers around the subpipeline, and the data from the 
> implicit readable
> > input port just "flows through", directly to the subpipeline.
> >
> > Regards,
> > Vojtech
> >
> > ________________________________
> > From: xproc-dev-request@w3.org 
> [mailto:xproc-dev-request@w3.org] On Behalf
> > Of James Garriss
> > Sent: Wednesday, September 24, 2008 2:54 PM
> > To: XProc Dev
> > Subject: Re: compound steps and primary inputs
> >
> > I understand what a primary input port is.  What I don't 
> know is how I know
> > that p:for-each has only one input.  If I look at a step 
> like p:filter, it's
> > obvious from it's declaration (I'm catching on to the 
> terms!) that it has
> > only one input port:
> >
> > <p:declare-step type="p:filter">
> >      <p:input port="source"/>
> >      <p:output port="result" sequence="true"/>
> >      <p:option name="select" required="true"/>              
>        <!--
> > XPathExpression -->
> > </p:declare-step>
> >
> > But p:for-each doesn't seem to have a declaration.  It 
> looks sorta like
> > BNF/parser-token-stuff to me.  So what tells me that 
> p:for-each has only one
> > input?
> >
> > <p:for-each
> >   name? = NCName>
> >     ((p:iteration-source? &
> >       (p:output |
> >        p:log)*),
> >      subpipeline)
> > </p:for-each>
> >
> > James Garriss
> > http://garriss.blogspot.com
> >
> >
> >
> > ________________________________
> > From: Norman Walsh <ndw@nwalsh.com>
> > Date: Tue, 23 Sep 2008 16:45:22 -0400
> > To: XProc Dev <xproc-dev@w3.org>
> > Subject: Re: compound steps and primary inputs
> > Resent-From: XProc Dev <xproc-dev@w3.org>
> > Resent-Date: Tue, 23 Sep 2008 20:46:27 +0000
> >
> > James Garriss <james@garriss.org> writes:
> >
> >> Do all compound steps have primary inputs?  I ask because 
> I can't tell by
> >> reading the WD if p:for-each has a primary input or not.  
> I'm probably
> >> missing a key word somewhere.
> >
> > The p:for-each step has only one input and the rules say
> >
> >   [Definition: If a step has a document input port which is 
> explicitly
> >   marked "primary='true'", or if it has exactly one document input
> >   port and that port is not explicitly marked 
> "primary='false'", then
> >   that input port is the primary input port of the step.]
> >
> > By the second clause, the input port of p:for-each is primary.
> >
> >> When I use it in Calabash 0.6.1, it behaves as if it does:
> >>
> >> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc">
> >>     <p:input port="source">
> >>         <p:document href="BookStore.xml"/>
> >>     </p:input>
> >>     <p:output port="result"/>
> >>     <p:filter select="/BookStore/Book[Date>'1970']"/>
> >>     <p:for-each>
> >>         <p:output port="result"/>
> >>         <p:identity/>
> >>     </p:for-each>
> >> </p:declare-step>
> >>
> >> The output of filter, a sequence of documents 
> (<Book>...</Book>), is being
> >> inputted (is that a word?) into p:for-each.
> >
> > That's right. And that's what you want, isn't it?
> >
> >> Appreciate any insights!
> >
> > 1. You only need to use p:filter if some part of the 
> expression you want
> > to test against is computed by the pipeline.
> >
> > 2. A p:for-each that contains only an identity step is a little, uh,
> > redundant.
> >
> > I believe that you could simplify the pipeline above to just this:
> >
> > <p:declare-step xmlns:p="http://www.w3.org/ns/xproc">
> >     <p:input port="source">
> >         <p:document href="BookStore.xml"/>
> >     </p:input>
> >     <p:output port="result"/>
> >     <p:identity select="/BookStore/Book[Date>'1970']"/>
> > </p:declare-step>
> >
> >                                         Be seeing you,
> >                                           norm
> >
> > --
> > Norman Walsh <ndw@nwalsh.com> | If we lived alone in a featureless
> > http://nwalsh.com/            | desert we should learn to place the
> >                               | individual grains of sand 
> in a moral or
> >                               | aesthetic hierarchy.--Michael Frayn
> >
> 
>

Received on Wednesday, 24 September 2008 13:54:30 UTC