Re: position vs index

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| Norman Walsh writes:
|
|> Do we agree that *outside* the context of a for-each, if the input to
|> this step is a sequence of three documents:
|>
|>   <p:matching-documents>
|>     <p:option name="test" value="p:position() mod 2 = 1"/> <!-- NB: value= -->
|>   </p:string-replace>
|>
|> then the p:position() function will return "1" for the first document,
|> "2" for the second document, and "3" for the third document in the
|> sequence?
|>
|> If so, then *inside* the context of a for-each, where the input
|> to this step is a single document (from the 'current' port):
|>
|>   <p:matching-documents>
|>     <p:option name="test" value="p:position() mod 2 = 1"/> <!-- NB: value= -->
|>   </p:string-replace>
|>
|> the p:position() function must return 1 for the first (and only)
|> document that matching-documents step sees on its input port.
|>
|> Anything else would seem wildly inconsistent.
|>
|> However, if you arrange to have p:position() evaluated before being
|> passed to the step, i.e., if you use select= instead of value=, then
|> p:position() is evaluated in the context of the for-each where the
|> natural thing to do is count the number of documents that have passed
|> by.
|
| OK, so now I see where things have gone wrong.  In my original
| proposal [1], I distinguised between two _different_ counters:
|
|  2) A 1-origin index of the position of the current document in a
|     document sequence;
|
|  3) A 1-origin indicator of the iteration number.
|
| Your example provides some motivation for why we might imagine that
| these should be different.  I agree that by careful adjustment of
| semantics of position() wrt the evaluation point you can get the
| desired effect, but I think in practice it will be difficult to define
| precisely and difficult to explain

Really? It seems straightforward to me.

We say that for the purposes of evaluating XPath expressions, the
context position is the number of the document in the sequence. Steps
that accept a sequence, like for-each and matching-documents, set the
context position based on the number of document's they've processed
and position() just "comes out right".

If

  <p:option name="pos" select="position()"/>

occurs inside a for-each, $pos is the number of documents the for-each
has processed.

If

  <p:option name="test">position() mod 2 = 1</p:option>

is evaluated inside a p:matching-documents, it's counting the number
of documents that it has received.

| -- do we have any other examples
| where crossing the threshold of the component changes the value of an
| expression in the way you propose?

I think p:viewport is similar to p:for-each. For the rest of the
compound steps, I think the context position is always 1.

| I'm left feeling that it will be easier to explain and implement if we
| keep position() for position in a sequence, and add p:index() for
| iteration count.

There's a fair bit of complexity in implementing and explaining
p:index() that doesn't seem necessary to me.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Time wounds all heels.
http://nwalsh.com/            |