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

Subject: RE: [xsl] Problem using Position() in .NET environment.
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 14 Oct 2004 17:40:52 -0400
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
======================================================================


Current Thread