Talk:XPath 1.0

message: : 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)
thread_title:  Expanded syntax 

message: 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)
thread_title:  XPATH 2.0 

message: For the unitiated ...
Reply:
I think that I've tidied things up under Examples so the explanation of what the code does shows up better.  I'm still not entirely happy with it, though.  I did try putting the plain English in italics or bold but that didn't look right either.  But at least the lines of code being explained aren't boxed off. Does this help? Meanwhile, /wikimedia/projects/project/@name is a piece of code used in the explanation but I'm not finding it in the full example.  Could someone help with this?
--Kovar (talk) 21:21, 12 December 2008 (UTC)
thread_title:  A realworld example would be useful 

message: 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)
replies: text: 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)
thread_title:  Textual representation of example xpath is wrong 

message: 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)
thread_title:  Please check this xpath expression 

message: 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)
replies: text: 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)
thread_title:  Abbreviated syntax 

message: 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)
thread_title: Incorrect example

message: 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)
thread_title: XPath vs. URL

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

message: I dont know if it is part of the standard, but I'm using PHP's xpath implementation and you can do things like this one:
(//ul)[1]  => gives the first UL element in the document whereever it is.
On the other hand:
//ul[1]  => gives all UL elements that are the first child of any other element.
If it is part of the standard then it should be included in the article.
--190.20.241.225 (talk) 05:27, 20 June 2008 (UTC)
thread_title:  Nesting node sets in parenthesis 

message: There isn't a shred of evidence offered that developers have rapidly adopted Xpath. For instance ElementTree has minimal support for the abbreviated syntax. It is just too much work to implement anything more than the basics, and when you get done, you have a tool that few people will have the patience to use anyway. So this standard looks like it will go the way of SGML. If you disagree, post a link. A statement like "developers are rapidly adopting technology X" needs to be backed up.
169.229.200.176 (talk) 22:49, 26 June 2008 (UTC)
thread_title:  Hype and Disinformation 

message: The section on Predicates repeatedly uses the expression //a[1] (perhaps with intervening predicates) and explains it as meaning "the first <a> element in the document". This is incorrect. //a[1] selects every <a> element that is the first <a> child of its parent. The correct way to select the first <a> element in the document is (//a)[1]. I corrected this and someone reverted it - God save us from self-styled experts!
Mhkay (talk) 21:39, 26 August 2008 (UTC)
replies: text: No. There is no first() function. Mhkay (talk) 11:38, 3 November 2008 (UTC)
replies: text: How about //a[position()=1] ?  —Preceding unsigned comment added by 69.125.25.190 (talk) 16:29, 6 November 2008 (UTC)

text: Look, if you aren't an expert in XPath, why are you writing here? //a[position()=1] means /descendant-or-self::node()/child::a[position()=1], which selects every a element that is the first a child of its parent. Mhkay (talk) 23:59, 6 November 2008 (UTC)
thread_title:  //a[1] 

message: I didn't even realize there were Xpath 1.0 and 2.0 articles. It would be better if all three articles were merged, with the version histories and whatnot still intact.  —Preceding unsigned comment added by 69.125.25.190 (talk) 15:50, 14 September 2008 (UTC)
thread_title:  MERGE 

message: What was the issue with the correction I made? Is the forward slash actually required? I never use the forward slash after a open-bracket in XPath, it seems to break the path, at least when I use the JDOM and Dom4J libraries. - Poobslag (talk) 20:37, 6 November 2008 (UTC)
replies: text: Hi Poobslag. I moved your question from my talk page to here as you seem to be discussing this article rather than me personally. The reason I reverted your edit was because in the two XPaths you altered the point was that, in the context of an 'a' element, one predicate was going out of context and looking at a top-level 'html' element ("[/html..."), whereas another was staying in context and referring to a child 'href' attribute ("[@href..."). As these 'look-arounds' were contained in predicates, they "affect[ed] neither the context of other predicates nor that of the location step itself", as the article says. A leading slash is not a matter of habit, but has a particular meaning. --Nigelj (talk) 22:24, 6 November 2008 (UTC)
replies: text: Alright thanks, I didn't catch that. Rereading the example within the context you've provided here, everything makes sense. - Poobslag (talk) 22:54, 10 November 2008 (UTC)

text: I don't know the history of this. The current expression that we have in the Predicates section a[/html/@lang='en'][@href='help.php'][1]/@target is correct, but far more complex in my view than is appropriate for a brief XPath overview article: it's not a good choice of example for explaining predicates, because it distracts attention from the essentials. Mhkay (talk) 23:56, 6 November 2008 (UTC)
replies: text: I agree, these examples are more advanced than I would expect from an Xpath overview. - Poobslag (talk) 22:54, 10 November 2008 (UTC)
thread_title:  XPath error I introduced?