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

Re: xpath trickery (was A Question **TO** XSLT Newbies

Subject: Re: xpath trickery (was A Question **TO** XSLT Newbies)
From: S Woodside <sbwoodside@xxxxxxxxx>
Date: Thu, 24 Apr 2003 14:05:57 -0400
preceding xpath
This is going to be a long rant, but you asked...

On Monday, April 21, 2003, at 03:20 PM, Andrew Watt wrote:

The online documentation is way poor (the XSLT spec is pretty good, the XPath spec is shite).

Interesting. Same author/editor for both specs. So maybe he didn't anticipate that people would find such difficulties with XPath either.

Well, from what you said, XPath has a longer history so there may have been assumptions made when writing it that weren't made with xslt.


A lot of the resources about XSLT don't make it clear where the line between something being an XPath problem and an XSLT problem is >> drawn.

I am pretty sure this is deliberate. I assume the thinking is that XSLT and XPath are used together so teach them together.

Sure. What I meant was, that they have such a dramatically different syntax, and there are definitely cases especially with scoping and variables where they just plain behave differently.


XPath seems to have all kinds of special cases.

Care to share what you found particularly troublesome?

I'll try
- variable in XPath seem to be allowed / disallowed in random ways. I still haven't figured out where they're not allowed, but I've definitely encountered these situations. Well, it's probably because of the difference between nodesets and the other things (can't remember the name) that variables hold.
... see below


The syntax is totally overloaded

Is that the inevitable downside of compact? Or do you have something else in mind?

Perhaps... but to give some examples.


axes, location steps, functions, predicates.

- axes ... OK, these are pretty clear. BUT, the shorthand, like // I think is very unhelpful. That in particular is a kludge that often isn't necessary and besides it's slow. It really is better to know what is actually going on when the performance impact is so huge.
- also it is actually very irritating that axes have a different syntax from a location step. In particular I find myself all the time saying axis::*[name() = $var] instead of say axis::$var (so in that case, it's not enough overloading...)
- * location step ... what is the difference between /path/to and /path/to/* ?
- functions ... there are two ??? kinds of functions. One kind is that I think of as ordinary function, like string(...) because they operate on some value. But then we have text() ... as in path/to/text() ... what is that? What is text() operating on? is it a location step here? what about node()??? what is the difference between foo::* and foo::node() and foo::self ???
- and what about last() ? What about position() ? These seem to automatically scope themselves into some kind of operation upon all elements of the set that is defined by the location steps. But why is /path/to/text() allowed and /path/to/last() not allowed? That's BAD syntactic overloading
- predicates. well, i'm just confused here. I guess the key for me was discovering that the predicate is evaluated N times where N is the number of set elements defined by the preceding xpath, and each time the scope/context/whatever is different. that wasn't obvious from reading the spec, at least to me.


Enough for now. I'm sure I've made horrible errors already in the above, which just goes to show you how confused I am even after I've been able to come up with expressions like this one:

<xsl:for-each select="current()/ancestor-or-self::*[@name]">

in fact is that current() even needed???

or this one which I got help with from this list:

<xsl:when
test="$StartNode//zeroOrMore//*[generate-id()=generate-id(current())]
or $StartNode//oneOrMore//*[generate-id()=generate-id(current())]
">


(which is actually pretty efficient, although my original ( [. = current()] ) wasn't.)

or this one:

    <xsl:value-of
      select="descendant-or-self::*
        [self::element or self::attribute][@name][1]/@name"/>

in that one self:: is scope INSIDE the xpath to the set defined by *, but element and attribute are actually location steps, not keywords ... another whole topic...

I have more to say but I'll stop now.

simon


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list



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.