Talk:XPath

From Wikipedia, the free encyclopedia

Contents

[edit] Expanded syntax

In the full, unabbreviated syntax, the two examples above would be written
...
* child::A/descendant-or-self::node()/child::B[1] respectively.

Isn't that suppost to be child::A/descendant-or-self::B/child::node()[1]?

>> No, it's correct as written! Mhkay 20:27, 12 May 2006 (UTC)

[edit] XPATH 2.0

either XPATH 2.0 section moves to XPATH 2.0 article, or the opposite.

atm this section here is way better than the article.

Another possibility is to say a sentence about XPATH 2.0 and point to XPATH 2.0 article (which will have the XPATH 2.0 section from this page)

The current situtation is bad --Nkour 14:05, 15 April 2006 (UTC)

It's still bad Mhkay (talk) 22:46, 24 November 2007 (UTC)

[edit] Predicates

Surely //a[@href='help.php'][../../div/@class='header']/@target means an <a> with href of help.php - not with a parent that's a div (as suggested in the article), but rather with a grandparent that contains a div (with class 'header') - even if that div is not an ancestor of the <a> node? —The preceding unsigned comment was added by Tim.spears (talk • contribs) .

Well spotted, Tim! That example has always been a pain. It was Hwiechers who first took me to task over it back in May, and by the time I'd fixed his point, while still trying to keep its original purpose, I opened up this problem without noticing.
So, rather than rushing at it again, today I took some time and, I hope, came up with something quite realistic (and tested!) that makes the point I was after. The point is something I've found quite useful in designing complex XPaths: Sometimes from a predicate in the midddle of an XPath you can, as I think of it, stick up a periscope (maybe by using ../../../) and peer into some far place in the document to check some detail over there. When I discovered I could do this at any time, it made some hard XPaths much easier for me. (I do this in XSLT, usually)
I hope I'm now making that point OK without labouring the issue. The reason I wasn't happy with Hwiechers' or AutumnSnow's otherwise fine suggestions was that, while they technically fixed the old example XPath, they shifted the emphasis away from that idea. Sorry, guys, if it seemed I was just being obdurate. --Nigelj 19:18, 29 July 2006 (UTC)
" Predicate order is significant, however. Each predicate 'filters' a location step's selected node-set in turn. //a[1][/html/@lang='en'][@href='help.php']/@target will find a match only if the first a element in a @lang='en' document also meets @href='help.php'"... Well this is not true. /html/@lang='en' evaluates true if an attribute @lang with value "en" exists within /html. So there is no connection to 'a'. --Ntropy

[edit] A realworld example would be useful

For the unitiated ...

[edit] Textual representation of example xpath is wrong

The text is ambiguous. It says:

  • A//B/*[1]
selects the first element ('[1]'), whatever its name ('*'), that is a child ('/') of a B element that itself is a child or other, deeper descendant ('//') of an A element that is a child of the current context node

The expression "first element" doesn't specify "first among which?". It makes one think that it first lists *all* the children of *any* such B, and *then* picks the first, returning only one element. When in fact what happens is that it returns a set consisting of the first child element of each such B. Helder Ribeiro 20:48, 5 July 2007 (UTC)

Absolutely right, Helder! Well spotted! I've added a new sentence into the article that, I hope, makes that point. Feel free to clarify the text if you can think of a better wording. You can't get a better encyclopedia than one with this many proof readers and copy editors!!! --Nigelj 21:59, 5 July 2007 (UTC)

[edit] Please check this xpath expression

The expanded form of A//B/*[1] is given as child::A/descendant-or-self::node()/child::B/child::*[position()=1] . Could someone sanity-check me? Is there a reason why this does not read child::A/descendant-or-self::B/child::*[position()=1] ? The response to the earlier post about this states that the original given example is correct. Which it is. But is the more concise alternative correct?


The abbreviated syntax A//B/*[1] is by definition short for child::A/descendant-or-self::node()/child::B/child::*[position()=1]. Now, there are many circumstances in which A//B actually gives the same result as A/descendant::B, or for that matter A/descendant-or-self::B, notably when there is no positional predicate and when A and B are disjoint tests. But we're not trying to find alternative ways of replacing this XPath expression by different expressions that give the answer; we're saying how the spec defines the semantics of the abbreviated syntax. Mhkay 22:59, 15 July 2007 (UTC)


Why don't we say something like this:

By definition, the abbreviated syntax is equivalent to

  • child::A/descendant-or-self::node()/child::B/child::*[position()=1]
but it could also be written as
  • child::A/descendant::B/child::*[position()=1]

As it is now, it looks like we're purposely trying to make the expanded syntax look bloated and ugly. Herorev 02:46, 24 August 2007 (UTC)

But if you want a compact representation, then the original one is fine. What's the point of offering an intermediate representation? Mhkay (talk) 22:49, 24 November 2007 (UTC)

[edit] Abbreviated syntax

W3C states that "// is short for /descendant-or-self::node()/". First, in the article, // is placed under descendant, not descendant-or-self. Second, to my understanding, // is not an abbreviated axis specifier -- that would yield ///node --, but merely syntactical sugar on the expression level.

Similarily, the axis specifiers self and parent don't correspond to the shortcuts . and .., respectively, as . and .. are abbreviated steps.

I call for a clarification in the article. Knut Vidar Siem 08:18, 16 October 2007 (UTC)

Agreed, changing // to descendant-or-self and some clarification would be great. I'm changing to descendant-or-self now and letting someone better in expressing themselves doing the other changes. Fredrikc 10:11, 2 November 2007 (UTC)

[edit] Incorrect example

The example is as follows: For example, h3[.='See also'] selects an element called h3 in the current context, whose text content is See also. The example is only correct if there are no children in the matched nodes. h3[text()='See also'] matches better and if unwanted spaces hasn't previously been accounted for the following is needed h3[normalize-space(text())='See also']. I'll change into h3[text()='See also'] but some text explaining about white-spaces might be appropriate. Fredrikc 11:09, 5 November 2007 (UTC)

No, this was a bad change. [.='See also'] is usually better practice than [text()='See also'] and corresponds better to the English description "whose text content is...". Examples where the results are different are:

<h3>See <?pi?>also</h3>

<h3><a name="anchor">See also</a></h3>

and in both cases [.='See also'] gives the "better" answer.

I'm going to revert it.

Mhkay (talk) 22:55, 24 November 2007 (UTC)

<h3>See also<sup><a href="...">[1]</a></sup></h3> and such gives worse with [. = 'See also'] but it might be more uncommon, using dot instead of text() is easier to read. Fredrikc 16:44, 1 December 2007 (UTC)

[edit] XPath vs. URL

I'll admit, I get terminology wrong a lot, particularly since I know few people I can talk using the terminology without them giving me a funny (and dirty) look. I have seen references to XPaths also being called URLs. In my head, which is almost always incorrect in some way, I think of URLs as having protocols like http:, ftp:, afp:, etc. Am I stupid for thinking an XPath is not related to a URL? If I am, should we make a mention to it being referred to by many as a URL? Dprust (talk) 19:44, 12 December 2007 (UTC)

There is no relationship between path expressions and URLs, other that the psychological one that they both have hierarchic components separated by slashes. Mhkay (talk) 22:14, 13 February 2008 (UTC)

[edit] Content node

The text twice mentions 'content node'. Shouldn't that read 'context node' instead, according to [1]? Muffat (talk) 14:43, 11 February 2008 (UTC)

Yes. Fixed. Mhkay (talk) 22:16, 13 February 2008 (UTC)