Dear Wendell and xsl-list,
Thank you (also the others who have responded) for the clarification. You
write that it "isn't about current()", but, for what it's worth, it was
misunderstanding current() that led me to misunderstand position(). The
spec (20.4.1) tells me that "The current function, used within an XPath
expression, returns the item that was the context item at the point where
the expression was invoked from the XSLT stylesheet", continuing (5.3.3.1)
that "The context position is the position of the context item within the
sequence of items currently being processed. It changes whenever the
context item changes." I had (mis) read that to suggest that as long as
current() referred to the same current context item, the position()
function would refer to its original context position. That assumption was
wrong for several reasons (e.g., I had glossed over "within the sequence of
items currently being processed", and that had changed; XSLT position()
isn't the same as the XPath position() function; "the 'outer' context
position is not retrievable accessible within the 'inner' expression"),
which are clearer now thanks to the helpful responses on the list.
Best,
David
On Mon, Dec 2, 2019 at 11:53 AM Piez, Wendell A. (Fed)
wendell(_dot_)piez(_at_)nist(_dot_)gov
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Dear David and XSL-List,
Mike points out this isn’t about current(): it is a red herring.
Nonetheless it might help to keep in mind that while position() is an XPath
expression, current() is not. It is defined only by XSLT.
This is because its entire purpose is to refer from inside an XPath
expression – that is, from a processing context that has changed from the
context at the start of the path – back out to the calling context. XPath
without XSLT has no such context (by definition, it is provided), so it
does not define this function. Other languages embedding XPath offer other
ways of dealing with this issue. Mostly this is by providing for variable
bindings to be made outside the path, permitting us to reference back out
to some context that way. Or simply by not supporting relative XPaths from
arbitrary locations, so the calling context is always the document root.
Indeed, since we can bind variables in XSLT, as in XQuery, we don’t
(mostly) need current() in XSLT either. Most always we could rewrite it
(apologies for smart keyboard making dumb syntax errors):
<xsl:variable name="letters" as="xs:string+" select="'a', 'b', 'c'"/>
<xsl:for-each select="$letters">
<xsl:variable name=”current” select=”.”/>
<xsl:message select="position(), $current ! position()"/>
</xsl:for-each>
This might suggest why the expression “current() ! position()” behaves the
way it does. It is the same as “for $c in (.) return position()”.
So position() is not different in XPath from XSLT. The difference is only
where the processing context is defined, which includes position along with
a context node (or item as here), context size (returned by last()) and
variable bindings in scope. Where the XPath is called, this context – it
can be thought of as a set of properties used to initialize the XPath
evaluation – is defined by the calling context in the XSLT. But deeper
inside an XPath is a different matter, since each step provides context(s)
for the next one (changes focus). The difference is not how position()
works but whose position within which sequence is being asked for.
Cheers, Wendell
XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3318727> (by
email <>)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--