4 ms·

It's the latter (XML namespaces spoil everything). In every single task I do that involves munching on XML with xpath, the largest timesink is figuring out how

by fein 13y ago

It's the latter (XML namespaces spoil everything). In every single task I do that involves munching on XML with xpath, the largest timesink is figuring out how the ns needs to be set up. (Looking you you, PHP simpleXML).

masklinn 13y ago
> In every single task I do that involves munching on XML with xpath And more generally that's true of every single task involving muching on namespaced XML. Namespaces are a good idea implemented absolutely terribly. XPath is a good idea well-implemented (no, XPath 2 does not exist, there is only one XPath). One of the few I've found in XML-land. I still hate that we have to use CSS selectors rather than XPath (although that's understandable considering CSS selectors predate XPath), most of the improvements since CSS1 were in XPath day 1, and the rest (pseudo-classes) could probably have been implemented using functions. 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" (matching HTML classes in XPath without custom helpers is the worst)
- arethuza 13y ago
  There has been a spec for XPath 2.0 for quite a while - though I don't think there are many implementations: http://en.wikipedia.org/wiki/XPath_2.0 http://en.wikipedia.org/wiki/XPath_2.0
  - mcburton 13y ago
    The SAXON XSLT processor implements basic XPATH 2.0 http://saxon.sourceforge.net/ http://saxon.sourceforge.net/
- yeahbutbut 13y ago
  > 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_selectors https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_s...
  - masklinn 13y ago
    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`: //*[tokenize(@class, '\s+')='foo'] but still not great. And god forbid you need to match multiple classes in the same selector. [0] or xpath 1 + exslt if your xpath implementation provides it. exslt actually does slightly better as the pattern is optional and defaults to whitespace characters
    - voltagex_ 13y ago
      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.
      - masklinn 13y ago
        > Over in .NET land we appear to be stuck on XPath 1.0 forever. I don't think it's a bad idea, most of the improvements in XPath 2 are the new standard functions which depending on your XPath implementation may be available as extensions (e.g. tokenize comes from exslt, an xpath 1.0 library) but along with that it brings significantly higher complexity and I think the spec has gone from "difficult to read" to "meaningless word-salad". I really like XPath, but I can't say I was impressed by XPath 2, it loses much of xpath's simplicity with little to show for the added complexity.
yogo 13y ago
Yep very true. Depending on what you are working on alternative approach is to strip out the namespaces before querying anything. Obviously, this can get you in trouble, and while namespaces are there for a reason, they can be a PITA when working with XML.

by fein 13y ago

masklinn 13y ago

> In every single task I do that involves munching on XML with xpath And more generally that's true of every single task involving muching on namespaced XML. Namespaces are a good idea implemented absolutely terribly. XPath is a good idea well-implemented (no, XPath 2 does not exist, there is only one XPath). One of the few I've found in XML-land. I still hate that we have to use CSS selectors rather than XPath (although that's understandable considering CSS selectors predate XPath), most of the improvements since CSS1 were in XPath day 1, and the rest (pseudo-classes) could probably have been implemented using functions. 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" (matching HTML classes in XPath without custom helpers is the worst)

arethuza 13y ago
There has been a spec for XPath 2.0 for quite a while - though I don't think there are many implementations: http://en.wikipedia.org/wiki/XPath_2.0 http://en.wikipedia.org/wiki/XPath_2.0
- mcburton 13y ago
  The SAXON XSLT processor implements basic XPATH 2.0 http://saxon.sourceforge.net/ http://saxon.sourceforge.net/
yeahbutbut 13y ago
> 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_selectors https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_s...
- masklinn 13y ago
  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`: //*[tokenize(@class, '\s+')='foo'] but still not great. And god forbid you need to match multiple classes in the same selector. [0] or xpath 1 + exslt if your xpath implementation provides it. exslt actually does slightly better as the pattern is optional and defaults to whitespace characters
  - voltagex_ 13y ago
    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.
    - masklinn 13y ago
      > Over in .NET land we appear to be stuck on XPath 1.0 forever. I don't think it's a bad idea, most of the improvements in XPath 2 are the new standard functions which depending on your XPath implementation may be available as extensions (e.g. tokenize comes from exslt, an xpath 1.0 library) but along with that it brings significantly higher complexity and I think the spec has gone from "difficult to read" to "meaningless word-salad". I really like XPath, but I can't say I was impressed by XPath 2, it loses much of xpath's simplicity with little to show for the added complexity.

yogo 13y ago

Yep very true. Depending on what you are working on alternative approach is to strip out the namespaces before querying anything. Obviously, this can get you in trouble, and while namespaces are there for a reason, they can be a PITA when working with XML.