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