XPath is actually pretty useful once it stops being confusing

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.<p>XPath : XML :: regex : text

xpath is awesome, especially once you understand what an axis is.<p>And that is what I&#x27;ve found most people who have trouble with it don&#x27;t understand - like what exactly following-sibling or child means.<p>I spent about 2 months writing my own xpath evaluator once and it gets so much easier (to implement too) when you understand this is just a tree-traversal with an iterator following the axis.<p>Unfortunately the axis syntax makes it very verbose to read.

W3C is full of terrible standards: the verbose dom, the obtuse xml schema, the crippled css (you can&#x27;t have a variable), and others. XPath isn&#x27;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.

&gt; it&#x27;s a whopping 11 lines of code.<p>If you think 11 lines of code is a lot, you&#x27;re overly focused on concision at the expense of readability. I&#x27;ve never (read: never) worked on any Ruby code, yet I find the posted example more readable than the supposedly more valuable xpath.<p>At the very least, they&#x27;re the same. If you&#x27;re writing code in Ruby, 11 lines is nothing. If you&#x27;re writing code in Ruby and xpath is used nowhere else in the project, that single line of super-compact xpath might as well be 1000 lines of Ruby -- it doesn&#x27;t matter.<p>If you&#x27;re trying to compact 11 lines of code you&#x27;re probably doing it wrong.

After a great article on what looked to be a handy tool, this part disappointed me:<p><i>for this particular task, XPath is actually considerably slower than the pure-Ruby implementation. Interestingly, that&#x27;s not true if you take out the &lt;br&gt; 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><p>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()?

If you have great tools which keep the feedback loop short, then XPath, like Regex, SQL and CSS is extremely powerful and productive.<p>Just make sure that you document your test cases (i.e. what you should match) or your colleges will hate you.

Years ago, I wrote a tool for wrapping .NET XmlDocuments and making them far easier to work with via XPath: <a href="https://github.com/capnmidnight/xml-stuff" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;capnmidnight&#x2F;xml-stuff</a><p>On its own, .NET&#x27;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 is a nightmare. My XmlEdit project makes it almost as simple as key-value-pair config files.

&gt; But it gets more interesting if the lyrics are stored as an HTML fragment.<p>Is there any reason to store the HTML version with &lt;p&gt;s and &lt;br&gt;s instead of a plain text and converting it to HTML with simple rules à la markdown? (single line break = &lt;br&gt;, double line break = &lt;p&gt;)

I also like XPath for some purposes, but I think it really suffers from (IIRC) having been designed before the xml namespaces, which it only integrates very awkwardly IMO and which ruins the simplicity of XPath. Or maybe XML namespaces spoil everything they affect to some degree :)

&quot;This is a perfectly reasonable solution, but it&#x27;s a whopping 11 lines of code. Further, it feels like we&#x27;re using the wrong tool for the job: why are we using Ruby iterators and conditionals to get at DOM nodes?&quot;<p>Is it really that bad to have 11 lines in Ruby?<p>Initially I didn&#x27;t get the wrong tool part but after reading it all that did make more sense. I haven&#x27;t used XPath more than a few times and they were pretty simple so can&#x27;t complain. Just something I&#x27;ll have to keep in mind.

One problem with XPath is that it can be a lot slower than native or JIT&#x27;d code depending on the implementation. Interestingly enough you can do xpath like things in Scala with native code using pattern matching:<p><a href="http://ofps.oreilly.com/titles/9780596155957/HerdingXMLInScalaDSLs.html" rel="nofollow">http:&#x2F;&#x2F;ofps.oreilly.com&#x2F;titles&#x2F;9780596155957&#x2F;HerdingXMLInSca...</a>

Here&#x27;s how I use XPath - constant Googling! This is a good explanation, maybe I&#x27;ll actually learn it now.

If you are curious about XPath and CSS you might want to play with <a href="http://css2xpath.appspot.com" rel="nofollow">http:&#x2F;&#x2F;css2xpath.appspot.com</a>

I&#x27;m happy to see many other XPath fans here.<p>But as far as the OP, this seems like a case of worrying about the code instead of the data structure. This would be easier to address before the lines are transformed into HTML. Which I assume is not how they are stored.

XML gets a bad rap because of how much prettier JSON is, but there are a lot of cool tools associated with it. XPath is pretty awesome, I had to write a XPath parser&#x2F;executor once (for a class) and it made me appreciate the value and simplicity.<p>Then there was XSLT, which was a pretty sweet way to turn a data format into a variety of &quot;print&quot; or &quot;display&quot; formats. Definitely been replaced by bigger and better things but it&#x27;s a pretty awesome technology that does one thing really well.

I have made a little XPATH primer. Which is very much a work in progress. Check it out on my github: <a href="https://github.com/GeorgeMac/xpath-primer" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;GeorgeMac&#x2F;xpath-primer</a><p>There are a few issues I am having with my markdown editor, in comparison to githubs markdown support.

I prefer to use html parsers for such problems, such as beautifulsoup in python. I used xpath in the past but the ending code wasn&#x27;t that much shorter then a more verbose version based on beautifulsoup. And, for someone looking at the code, the beautiful version makes so much more sense.. Xpath also feels like a big regex expression that magically works.<p>I&#x27;m not saying it&#x27;s not useful. Actually, I believe that if you only have one use-case, then using xpath might be overkill because of all the added-complexity of maintaining a new library&#x2F;technology&#x2F;ideology. But if it&#x27;s the sort of domain that xpath would be useful more than once, then sure use it.

I just started getting into xpaths pretty hardcore with my trivia generator for <a href="http://playhattrick.com" rel="nofollow">http:&#x2F;&#x2F;playhattrick.com</a> ... I use it for identifying tables of data to scrape. It&#x27;s not as fun as regex IMO but it is powerful.<p>Pro Tip: the chrome inspector lets you right-click on an element and get its xpath.<p>Pro Warning: sometimes the xpath generated by chrome doesn&#x27;t work when scraping with Nokogiri. I&#x27;m not sure why yet, I&#x27;ve just learned not to rely on it.

Interesting, (and this could just be a made up problem to illustrate the blog post), but wouldn&#x27;t it have been much easier to just store the lyrics in another format (not HTML)?<p>For example, you could use TEI XML (<a href="http://www.tei-c.org/index.xml" rel="nofollow">http:&#x2F;&#x2F;www.tei-c.org&#x2F;index.xml</a>), and then use stanzas and lines. Then when you go to render your lyrics, you can capitalize the first letters in your presentation code.

XPath is alright but as sixbrx noted it suffers from problems with namespaces. I keep using this xslt transformation to remove the ns info. Then it works just fine: <a href="http://stackoverflow.com/a/413088/34022" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;413088&#x2F;34022</a>

CSS selectors are much easier to remember than XPath. Python&#x27;s BeautifulSoup allows you to select elements with selectors and is very convenient. XPath is a bit more verbose and most people already are familiar with CSS syntax.

&gt; the &#x2F; in an XPath expression plays the same role as the &gt; in a CSS selector:<p>The `&#x2F;` in an XPath expression is probably a better match for the space in CSS selectors.

This is a great explanation and quick tutorial on XPath, but, like regex, don&#x27;t think I&#x27;d ever use it in production code unless I absolutely had to.<p>I&#x27;m sure I&#x27;d have <i>fun</i> coming up with an XPath solution, but for me, the ultimate goal is maintainability. If I wasn&#x27;t 90% sure that the next person to look at that code already knew XPath, then I&#x27;d go with the Ruby solution.<p>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&#x27;t (which ends up forcing you to read 1000 lines of documentation and examples to understand it).

Writing an XPath 1.0 parser in C was fun. Maybe one day I&#x27;ll use it to (partially) replace MongoDB&#x27;s JSON query language.

I use xpath way more than I care to at my job but it get&#x27;s the job done.