[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [SPAM] RE: RE: [SPAM] - RE: RE: [SPAM]
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@xxxxxxxxxxxxxxxx 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 ======================================================================
|
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
|