Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XPath is actually pretty useful once it stops being confusing

news.rapgenius.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: XPath is actually pretty useful once it stops being confusing

#51

Post by riffraff »

callmeed wrote: post #40

I just started getting into xpaths pretty hardcore with my trivia generator for http://playhattrick.com ... I use it for identifying tables of data to scrape. It's not as fun as regex IMO but it is powerful. Pro Tip: the chrome inspector lets you right-click on an element and get its xpath. Pro Warning: sometimes the xpath generated by chrome doesn't work when scraping with Nokogiri. I'm not sure why yet, I've just l…

additionally, chrome's confole also has a $x function to find elements by xpath

Re: XPath is actually pretty useful once it stops being confusing

#52

Post by neves »

W3C is full of terrible standards: the verbose dom, the obtuse xml schema, the crippled css (you can't have a variable), and others. XPath isn't one of them. It is the best way to query XML documents in a forward compatible way. Maybe someday we will able to use XPath in a CSS file instead of their crazy selectors.

Re: XPath is actually pretty useful once it stops being confusing

#54

Post by pragmatic »

moron4hire wrote: post #27

Years ago, I wrote a tool for wrapping .NET XmlDocuments and making them far easier to work with via XPath: https://github.com/capnmidnight/xml-stuff On its own, .NET's XML libraries are really only good for consuming XML documents, but even that is a rather painful experience, especially as it forces a namespace on all documents, complicating the XPath expressions necessary to query it. Actually authoring documents…

That's cool. Do you have any example comparing your work to LinqToXml? http://msdn.microsoft.com/en-us/library/bb308960.aspx

Re: XPath is actually pretty useful once it stops being confusing

#55

Post by jpatokal »

hfsktr wrote: post #15

"This is a perfectly reasonable solution, but it's a whopping 11 lines of code. Further, it feels like we're using the wrong tool for the job: why are we using Ruby iterators and conditionals to get at DOM nodes?" Is it really that bad to have 11 lines in Ruby? Initially I didn't get the wrong tool part but after reading it all that did make more sense. I haven't used XPath more than a few times and they were pretty…

Agreed. I find the 11 lines of Ruby a lot more readable/obvious than that fairly convoluted XPath. Although I'd probably have opted for RSLT instead:

http://hackpackers.lonelyplanet.com/2013/03/05/XML-Transform...

Re: XPath is actually pretty useful once it stops being confusing

#56

Post by graue »

After a great article on what looked to be a handy tool, this part disappointed me:

for this particular task, XPath is actually considerably slower than the pure-Ruby implementation. Interestingly, that's not true if you take out the
part and only look for text at the beginning of paragraphs. My guess is that the following-sibling axis is the culprit, since it has to select all the following siblings of the br tags, and then filter them down to only the first sibling.

I was hoping selectors were lazy, in which case, selecting all the following siblings but then immediately filtering that selection down to the first would be cheap. Lazy or not, can there really be no efficient way to do the equivalent of jQuery next()?

Re: XPath is actually pretty useful once it stops being confusing

#57

Post by voltagex_ »

masklinn wrote: post #41
yeahbutbut wrote: post #28

Earlier quoted context omitted.

> Also, that might have finally gotten us a non-eye-stabbing standard function for "match any item of a space-separated list in an attribute" CSS handles this rather nicely: [class~=foo] https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_s...

Whereas xpath... does not. Which is a severe understatement considering the equivalent to the CSS selector you wrote up (or to `.foo`) in xpath 1 is something along the lines of: [contains(concat(' ', normalize-space(@class), ' '), ' foo ')] the normalize-space can be dropped IIF you're certain all spaces are normalized, the spaces around the needle not. xpath 2 does quite a bit better through `tokenize`: //*[tokeniz…

Over in .NET land we appear to be stuck on XPath 1.0 forever. A project I used to work on used it extensively, but I now use the HtmlAgilityPack (badly formatted HTML) or XDocument (XHTML strict or XML) where I have the choice.

Re: XPath is actually pretty useful once it stops being confusing

#58

Post by 6ren »

kjhughes wrote: post #18

XPaths are extremely useful. I actually enjoy writing them, much like I enjoy writing regular expressions. In fact, I consider both to return manifold the modest investment they require to learn well. XPath : XML :: regex : text

Now you have three problems.

(But along with relational algebra, they are among the few abstractions that work really well)

Re: XPath is actually pretty useful once it stops being confusing

#59

Post by moron4hire »

pragmatic wrote: post #54
moron4hire wrote: post #27

Years ago, I wrote a tool for wrapping .NET XmlDocuments and making them far easier to work with via XPath: https://github.com/capnmidnight/xml-stuff On its own, .NET's XML libraries are really only good for consuming XML documents, but even that is a rather painful experience, especially as it forces a namespace on all documents, complicating the XPath expressions necessary to query it. Actually authoring documents…

That's cool. Do you have any example comparing your work to LinqToXml? http://msdn.microsoft.com/en-us/library/bb308960.aspx

Well, I wrote this off of the top of my head, and it has been several years since I've used the library heavily (though I have a project now that needs it, so I most likely will be dusting it off and fixing any hairy bits).

https://github.com/capnmidnight/xml-stuff/blob/master/README...

However, just take note that the main concept of the library is "make it work". The idea was that, given an XPath expression with several attribute selectors, it would fill in any necessary nodes to just make it happen. So you can technically chain a ton of editing commands together, by using an appropriately complex XPath expression.

It came out of a need to repair thousands of broken XML documents. It's probably not very complete. It was written for one project--and though I took time to make it generalized--it didn't make it into a key role into any other projects; I just didn't ever again have the need to deal with XML documents on such a scale.

It's actually one of the first "big" things I wrote out of college. I'm not too happy with some of the design right now, but the functionality has held up over the years and it's not as shitty as some of the other code I wrote at the time. I guess I knew that a lot of the project was hinging on how easy it was to write XML documents, so I made sure I did a ton of testing to make it work.

Re: XPath is actually pretty useful once it stops being confusing

#60

Post by goflyapig »

This is a great explanation and quick tutorial on XPath, but, like regex, don't think I'd ever use it in production code unless I absolutely had to.

I'm sure I'd have fun coming up with an XPath solution, but for me, the ultimate goal is maintainability. If I wasn't 90% sure that the next person to look at that code already knew XPath, then I'd go with the Ruby solution.

Dealing with 11 lines of code in a language you know is better than dealing with 1 line of code in a language you don't (which ends up forcing you to read 1000 lines of documentation and examples to understand it).

Post reply on HN