Re: p:for-each

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Norm Walsh wrote:
|> Do you imagine that either or both of the following constraints apply?
|>
|> * In a p:for-each, exactly one p:declare-input must have an @select
|>   attribute.
|
| (Given no joins as discussed below:) In a p:for-each, there must be
| exactly one p:declare-input that has a @ref-each attribute (and may
| have a @select attribute to indicate iteration over elements). This
| p:declare-input tells you what you're iterating over.

Given that there must be exactly one, is there a compelling reason to
do this with a p:declare-input as opposed to simply allowing those
attributes on the p:for-each element?

It seems confusing to me that one p:declare-input is required, but others
are optional. So you could wind up with

  <p:for-each name="loop">
    <p:declare-input port="doc" ref-each="..."/>
    <p:declare-input port="style" ref="..."/>
    <p:declare-output port="results" ref="#x/y"/>

    ... ref="#loop/doc"
    ... ref="#loop/style"
    ... ref="#otherstep/foo"
  </p:for-each>

It seems to me that you should declare all the inputs or none of them,
declaring only some just makes my head hurt.

|> * In the steps of a p:for-each, any p:input reference to a "global"
|>   input (i.e. one not renamed with @ref-each) is consumed on the first
|>   iteration and is "empty" for subsequent iterations.
|
| No, I don't imagine that. I imagine that, behind the scenes, the
| processor makes enough copies of any p:input reference to a 'global'
| input to have one per iteration.

Yeah, that's what I figured.

| It's a familiar thing to XPath 2.0 users ;)
| for $i in (a,b,c), $j in (x,y) return ($i,$j)

I avoid 'for'. Ought not to have been in XPath 2.0 dang it. :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.