- 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