[XSL-LIST Mailing List Archive Home]
[Reply To This Message]
Re: characters in xsl
Subject: Re: characters in xsl|
From: Peter Bradley <apvx95@xxxxxxxxxxxxx>
Date: Thu, 11 Nov 2004 22:49:54 +0000
Ysgrifennodd Wendell Piez:
I think it does Wendell. I'll have to play with it to test my
understanding. Thanks for your help (again).
are functionally (almost) the same is related to the way match patterns
work as well as to what these expressions mean. (Note: they're precisely
the same as far as which elements they match, but they're not assigned
the same match priority. Because "//stone" is considered a "better
match" is the main reason we say to stay away from it as a match pattern
-- largely because this sometimes-crucial fact is usually not understood
by people who deploy the pattern.)
As David explained, "//stone" is short syntax for (long syntax)
"/descendant-or-self::node()/child::stone", which translates into
English as "any 'stone' element that is the child of some node that is
the descendant of the root, or of the root itself". That is, all 'stone'
elements in the document.
XPath "stone" is short for (long syntax) "child::stone", which is to say
"any stone elements that are a child (of something)".
If you reflect on the way all nodes in the tree are descendants of the
root, and all elements are the child of something, you can see these
expressions are the same.
Yet this is only in the context of a *match pattern*. If instead of
appearing there, the XPath appeared in a *select expression*, you'd have
a different situation on your hands.
This is because when you select nodes, you select from a given context.
(This is not true of the way match patterns are evaluated.) So if you have
<!-- long for select="stone" -->
the stones selected would not be just any stone (in the document) but
only those stones that are children of the garden-path element that is
the current node (hence the context node for evaluating the expression).
So whatever your garden-path is at the point the expression is evaluated
(and maybe you have several garden-paths in your document), only its
child stones are selected.
<!-- long for select="//stone" -->
the stones selected are collected by an XPath that traverses from the
root, and does not refer to the context node at all. So all the 'stone'
elements in the document are selected irrespective of what the current
node is at that point (which garden-path you're in, or indeed whether
they're in a garden-path at all).
If you consider how ".//stone" is short for
"self::node()/descendant-or-self::node()/child::stone" you'd also see
why this selects (when used as a select expression) all stone
descendants of the context node, as opposed to all stones in the document.
I hope this helps --
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format