- From: Norman Walsh <ndw@nwalsh.com>
- Date: Sat, 26 May 2007 09:40:06 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87646fitzd.fsf@nwalsh.com>
|> | one other point no one has made is that I will never be able to use
|> | position() in Pattern
|> | <p:viewport match="p[p:position() < $max-to-process]">
|> | in not easily done with your proposal
|>
|> Match only takes a single document, so p:position() will only ever be 1.
|
| Oh damned !
| I see my mistake
| So I think that p:blabla_index was doing what I said !
Hmm. Maybe I was wrong about this one. Maybe the context position
would change for each matched section. That's what we said about
p:*_index() right?
| But I still think that some of us got the mistake still wrong
|
| <!-- the default input is a document -->
| <p:for-each select="//p">
| <p:option name="my-pos" select="position()"/>
| </p:for-each>
|
| what are the successive values of $my-pos in that case ?
I think options for a component should be evaluated exactly once.
In fact, I think they're evaluated *before* the step begins to
execute (otherwise how can they *be available* to the step?)
So $my-pos is equal to whatever the context position is for the parent
of the p:for-each and it has the value throughout all the iterations.
If instead, you said:
<!-- the default input is a document -->
<p:for-each select="//p">
<p:group>
<p:option name="my-pos" select="position()"/>
...
</p:group>
</p:for-each>
Then I think $my-pos would equal 1, 2, 3, ... for each successive
execution of the p:group.
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | Wisdom is only a comparative quality,
http://nwalsh.com/ | it will not bear a single
| definition.--Marquess of Halifax
Received on Saturday, 26 May 2007 13:40:14 UTC