Altova Mailing List Archives
>xsl-list Archive Home
>Thread Prev - RE: [xsl] Problem using Position() in .NET environment.
>Thread Next - RE: [xsl] Problem using Position() in .NET environment.
RE: [xsl] Problem using Position() in .NET environment.
Date: 10/14/2004 1:41:00 PM
At 09:38 AM 10/14/2004, it was written: I would guess that giving a "//" in a match attribute, which we know now is actually not necessary, makes the pattern somehow invalid - don't know if this should happen or not, but now that we know, we can at least work around it. It doesn't make it invalid: it works fine. Or almost fine. The '//' operator is explicitly allowed in match patterns. Remember its semantics are as though it expands to this: /descendent-or-self::node()/ so match="//tile" would match as if it were "/descendent-or-self::node()/child::title" (although the descendant-or-self:: axis itself can't appear in a match pattern). If you work out how match patterns work -- a pattern returns a Boolean true (i.e. it matches) if the node against which it is tested can be reached, using the pattern as an XPath expression, from some other place in the document -- you'll see this is just the same as match="title". While a title element, say, could be selected from its parent using the XPath "title" (i.e. "child::title"), it could likewise be selected from anywhere at all using the XPath "/descendent-or-self::node()/child::title". Accordingly the two match patterns are effectively the same; the "//" is not wrong, but just unnecessary and probably slower to execute. (The "//" operator is very useful in such patterns as "front//title", however.) Except -- as David C. often has to remind us -- "//title" does *not* have the same template assignment priority, according to the rules for establishing priority, but is considered a "better match" than the plain "title". It's primarily this last reason, which can lead to unpredictable results when such a pattern is used in a stylesheet in which other templates also appear, that leads us purists to recommend against it. My guess is that newbies write "//title" either because they're trying to be extra-safe, and think "//title" to be more exact than "title", or because they're under the mistaken impression that a match pattern "reaches into" the tree and selects a node for processing. But it isn't, and doesn't, and they need not worry. I think what the OP is encountering is bugginess in new software, and perhaps a misunderstanding on the part of its implementors. XPath 2.0 has some new rules, but I don't think it should affect this. Cheers, Wendell ====================================================================== 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 ======================================================================