Re: [xsl] characters in xsl

[David Carlisle <davidc@xxxxxxxxx>]

   Thanks David. Not sure I can see the rationale behind that,

well xslt 1 didn't (officially) let you do anything with elements once
you had created them so it didn't really make much difference what the
internals of a variable were, although basically it strongly hinted that
the variable form should act like a document (root) node, and that's
what all implementations of xx:node-set() produced.

XSLT2 (and Xquery) allow you to make and query elements in a single
transform  and allow sequences of elements. If you want to make a
sequence <a/> <b/> <c/> you might have expected it should be

<xsl:variable name="x">
 <a/>
 <b/>
 <c/>
</xsl:variable>

and once could have imagined a coeherent design based on that but that
would be very incompatible with XSLT and xpath 1. A sequence of three
elements is different from a sequence of one document node which
has three elements as children.

recall the recent threads abouut xsl:for-each select="x:node-set($x)
and people being surpised that the for-each only iterates over one node
(the document root) not over its three children.

Surprising or not, compatibility issues mean that it pretty much had to
stay that way by default but the new as= attribute allows you to build
sequences directly rather than being children of an implied root node.

That's often convenient but sequences have different properties. Not
sharing a parent means that they are not siblings for example.
$x/a::following-siblling::* wouldn't picj up b and c for the same
reasons sibling axes don't necessarily pick up the next item in an
xsl:for-each in xslt1.

  but that does make it... fairly clear.

  " match="//stone" will only match a stone element that belongs to a document tree. "

  Does the match just fail .... or is it an error? Suck it and see?
  Then recall that match="stone" works similarly (in 1.0) to //stone. 

It's not an error it just doesn't match.  If you look back in this
thread at Wendell's explanation of why //stone  and  stone match the
same thing you'll see that it essentially depends on the fact that every
element is the child of _something_ either another element or a document
node. In XSLT2 that is no longer true as it gives access to intermediate
results, you can query an element after it has been constructed but
_before_ it has been copied into the final result tree. Such a free
standing element has no parent. Given that, the WG had to decide what to
do, arrange that you could not construct such a thing (difficult as the
_natural_ thing that select="a/b" selects is the b element without its a
parent) or specify how matching works. If you kept the original XSLT1
definition of matching match="stone" would be equivalent to
match="//stone" and _neither_ of them would match a free standing stone
element as //stone is explictly looking for a document (root) node.
That would mean that it would be impossible to have _any_ match pattern
that matched a free standing element. That would have been a possibility
but instead they slightly altered teh description of matching with a new
(virtual) child-or-top axis
http://www.w3.org/TR/xslt20/#pattern-semantics
which can't be explictly used but does allow parentless elements to be
matched. The end result is that given a parentless stone element
match="stone" matches it and "//stone" doesn't as the element isn't
under a / node.

This is OK I think. It's a bit technical but you can't generate
parentless elements by mistake, and you can't apply templates to them by
mistake. If you know enough to do both of those things on purpose, then 
you'd better know not to use //foo unless you mean it.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________