[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [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
xsl characters
Ysgrifennodd Wendell Piez:

The reason

<xsl:template match="//stone">...</xsl:template>


<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" -->

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" -->

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 --

I think it does Wendell. I'll have to play with it to test my understanding. Thanks for your help (again).



Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.