Re: select in for-each and iteration-source

Thanks for the reminder about this message, Mohamed. It was in my
queue but somehow I overlooked it.

/ Innovimax SARL <innovimax@gmail.com> was heard to say:
| I assume in the rest of the email, that select in for-each does give
| access to all node matching the select expression and not only the
| outermost

Yes, that's the semantic of an XPath select. And that's the same
semantic that you get with select on input:

<?xml version="1.0"?>
<p:pipeline name="pipeline"
	    xmlns:p="http://www.w3.org/2007/03/xproc"
	    xmlns:px="http://xproc.org/2007/03/xproc/ex">
<p:output port="result"/>

<p:for-each name="for-each">
  <p:iteration-source select="//div">
    <p:inline>
      <doc>
	<div>div 1</div>
	<div>div 2
	  <div>div 2.1</div>
	</div>
      </doc>
    </p:inline>
    <p:inline>
      <doc>
	<div>div 1</div>
      </doc>
    </p:inline>
  </p:iteration-source>
  <p:output port="result"/>

  <p:wrap-sequence>
    <p:option name="wrapper" value="document"/>
  </p:wrap-sequence>
</p:for-each>

<p:wrap-sequence>
  <p:option name="wrapper" value="doclist"/>
</p:wrap-sequence>

</p:pipeline>

returns:

<?xml version="1.0" encoding="UTF-8"?><doclist><document><div>div 1</div>
</document>
<document><div>div 2
          <div>div 2.1</div>
        </div>
</document>
<document><div>div 2.1</div>
</document>
<document><div>div 1</div>
</document>
</doclist>

| [Note en passant : it means that in a for-each the same node could be
| provided multiple times]

Yes.

| Let's say we have a sequence in step="generate-sequence" port="result"
|
| Here are multiple way to access to doc elements in this sequence
| In this sequence we would have all use cases :
| a. some documents in the sequence do not contains any doc element
| b. some documents in the sequence do contains doc that are not
| themselves descendant of a doc element
| c. some documents in the sequence do contains doc that are descendant
| of doc element
|
| The goal is to apply the same select at different places to see what
| are the difference . I know it is totally arbitrary but it gives a
| opportunity to be sure of what we mean by selecting at those level

Right.

| Here are the different classes of construct
|
| == simple case ==
|
| [S1]
| <p:for-each select="//doc">
|  <p:iteration-source>
|    <p:pipe step="generate-sequence" port="result"/>
|  </p:iteration-source>
|  subpipeline
| </p:for-each>
|
| it would give to the subpipeline all the doc elements dispatched in
| the sequence (b and c)

I agree.

| [S2]
| <p:for-each>
|  <p:iteration-source select="//doc">
|    <p:pipe step="generate-sequence" port="result"/>
|  </p:iteration-source>
|  subpipeline
| </p:for-each>
|
| it would give to the subpipeline all the doc elements that are not b (only c).
|
| [Note en passant : I assume that select on
| p:input/p:iteration-source/etc. throw out empty matchs, please confirm
| !]

No, I don't believe that's the case. If it was, then 'select' wouldn't
have the semantics of an XSLT 'select' and I'd want to change the
attribute's name.

We decided to use 'match' on p:viewport where it's really important
not to process elements more than once. Everywhere else where we've
used select=, I assume we're using the standard XPath/XSLT select
semantics.

| == Nested case ==
|
| [N4]
| <p:for-each name="outer">
|  <p:iteration-source>
|    <p:pipe step="generate-sequence" port="result"/>
|  </p:iteration-source>
|  <!-- here we can get information and put them in options -->
|  <p:for-each select="//doc">
|    <p:iteration-source>
|      <p:pipe step="outer" port="current"/>
|    </p:iteration-source>
|    subpipeline
|  </p:for-each>
| </p:for-each>
|
| With this one the sequence is splitted document by document (wether or
| not they contain doc) and then S1 is applied
| so you get [S1]+[context on each doc of the sequence included a) ]

I think that's right.

| [Note en passant : do we have a way to know that the inner p:for-each
| had match anything in case of a) ?]

You could find out by running the results through p:count. (Or running
the input through it, if you wanted.)

| [N5]
| <p:for-each name="outer" select="//doc">
|  <p:iteration-source>
|    <p:pipe step="generate-sequence" port="result"/>
|  </p:iteration-source>
|  <!-- here we can get information and put them in options -->
|  <p:for-each select="//doc">
|    <p:iteration-source>
|      <p:pipe step="outer" port="current"/>
|    </p:iteration-source>
|    subpipeline
|  </p:for-each>
| </p:for-each>
|
| This one starts to be interesting
| from the outer one you get all the doc element (b and c)
| And in the inner loop you resplit

Right, in the outer loop you do b and c and then in the inner loop you
do ... b and c again.

| [N6]
| <p:for-each name="outer">
|  <p:iteration-source select="//doc">
|    <p:pipe step="generate-sequence" port="result"/>
|  </p:iteration-source>
|  <!-- here we can get information and put them in options -->
|  <p:for-each select="//doc">
|    <p:iteration-source>
|      <p:pipe step="outer" port="current"/>
|    </p:iteration-source>
|    subpipeline
|  </p:for-each>
| </p:for-each>

I think this is exactly the same as N5 for the reasons I gave above.

| This one, you will get a sequence of doc that have no doc ancestor
| And you apply a for each
| so you will get [S1]+[context of doc in the original sequence but a) removed ]
|
| [N8]
| <p:for-each name="outer">
|  <p:iteration-source>
|    <p:pipe step="generate-sequence" port="result"/>
|  </p:iteration-source>
|  <!-- here we can get information and put them in options -->
|  <p:for-each>
|    <p:iteration-source select="//doc">
|      <p:pipe step="outer" port="current"/>
|    </p:iteration-source>
|    subpipeline
|  </p:for-each>
| </p:for-each>
|
| With this one the sequence is splitted document by document (wether or
| not they contain doc) and then S2 is applied
| so you get [S2]+[context on each doc of the sequence included a) ]

Here you get b and c for each document, so I think that's just b and c.

| Are those interpretations correct ?

I'm not sure, but some of them are different from mine :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | In every work of genius we recognize
http://nwalsh.com/            | our own rejected thoughts; they come
                              | back to us with a certain alienated
                              | majesty.-- Emerson