[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Problem using Position() in .NET environment.

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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.