Peter,
The reason
<xsl:template match="//stone">...</xsl:template>
and
<xsl:template match="stone">...</xsl:template>
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
<xsl:template match="garden-path">
<xsl:apply-templates select="child::stone"/>
<!-- long for select="stone" -->
</xsl:template>
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.
But here
<xsl:template match="garden-path">
<xsl:apply-templates select="/descendant-or-self::node()/child::stone"/>
<!-- long for select="//stone" -->
</xsl:template>
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 --
Wendell
At 11:31 AM 11/11/2004, you wrote:
Nope. I haven't got it. Never mind. I'll go back to the spec and do
some reading. If I still can't work it out, I'll perhaps ask again.
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--