Altova Mailing List Archives

RE: [xsl] Problem using Position() in .NET environment.

From: Wendell Piez <wapiez@---------------->
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 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:


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 

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.


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
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


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.