Re: [xsl] is the processing model of XSLT 1.0 bit ambiguous?

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

I think your reasoning here is rather confused.
>
> I'd like to give one example, where I find the processing model of XSLT 1.0
ambiguous and it is a fit case of adoptiong to XSLT 2.0 or 3.0. Lets say,
there are sibling "x" nodes (the number of siblings is greater than 1), and we
refer it as /p/x
>
> When we write an experssion /p/x in XSLT 1.0, it may mean various "x"
nodes.

Actually it's an expression whose evaluation returns a node-set.


> But in XSLT 2.0, it doesn't mean like that. To refer to the "x" nodes at
positions 2, 3 .. etc we have another way in 2.0. *In XSLT 2.0, /p/x means the
1st "x" node*. To refer to all of "x" nodes, we can write in XSLT 2.0
/p/x[position() gt 0].

In XSLT 2.0, /p/x is an expression whose evaluation returns a node sequence.
The semantics are exactly the same as XSLT 1.0 except that instead of a set of
nodes (with no intrinsic order) we have a sequence of nodes that are
guaranteed to be in document order. This makes no practical difference,
because 1.0 constructs like xsl:for-each and xsl:apply-templates that operate
on a node-set always process the nodes in document order anyway.


> To refer to the 2nd one, we can write /p/x[2] or /p/x[position() = 2]

Actually /p/x[2] doesn't refer to the second node in the result of /p/x. That
would be (/p/x)[2]. It refers to a sequence containing every x node that is
the second x child of a p element.

>
> When you come to the XSLT 2.0 world from 1.0 world, I believe you'd find lot
of determinism (in the sense of formal languages. ref DFA).

I can't see what determinism (in the DFA sense or any other) has to do with
it. (I've occasionally seen people describe the semantics of path expressions
in terms of regular expressions, and perhaps that's what you're thinking of,
but it only really works for downwards axes).
>
>
Michael Kay
Saxonica