3 ms·

XML has XPath. JSON and YAML do not have xpath. They have those lame language-specific constructs that aren't recursive, aren't traversable and throw null point

XML has XPath. JSON and YAML do not have xpath. They have those lame language-specific constructs that aren't recursive, aren't traversable and throw null pointer errors when they can't match. You can format XML with xmllint and query it with xmlstarlet. You can't do that for json - good luck if you've got unformatted json. Tooling is everything.

specialist 15y ago
I added lightweight path expressions to LOX (Lightweight Objects for XML). It's a modern XML object model, that's easy to inspect, with built in support for xpath-like expressions (globbing, really), without all the suckage. http://code.google.com/p/lox/ http://code.google.com/p/lox/ Here's some example of path expressions. http://code.google.com/p/lox/source/browse/trunk/test/lox/test/Expression.java http://code.google.com/p/lox/source/browse/trunk/test/lox/te... Works fantastically. I use LOX for all my own XML work. My ARON project doesn't support path expressions in the same way. ARON's grammar only supports drill down dot notation, like "parent.child.grandchild". And, thus far, I've only used ARON to loft Java object graphs, so I haven't needed an object model with path expressions. I'd love to see a high level, statically typed language with built-in path expression. Groovy's GPath is closest to the mark that I've seen. (I really need to polish these open source side projects. And publicize them.)
- guard-of-terra 15y ago
  Making your own is cool, but where's the value added compared to XPath?
  - specialist 15y ago
    Thanks! It was a lot of fun and proven very useful. Biggest reason is conciseness (less code), followed by ease of debugging. When using JXPath or Jaxen, you have to use contexts. Pseudo code (from memory): Node n = new Node( "ugh" ); // add some children here JXPathContext c = new JXPathContext( n ); NodeList list = c.eval( "child" ); for( int i = 0; i < list.length(); i++ ) { Node m = (Node) list.get( i ); ... } Whereas LOX does it like this: Element e = new Element( "ugh" ); // Add some children here for( Element e : e.find( "child" )) { ... } I do a lot of ETL work (XML -> SQL). The ability to debug (interactive inspection) speeds development. I'm sure you've tried to debug XPath expressions. Not easy. Happily, all of the LOX's object implement toString() method to render their XML content. And the evaluation of path expressions, while not easy, is feasible. Whereas with JXPath or Jaxen, it's damned near impossible. (I've written a few object adapters for JXPath; getting them right is black magic.)
    - guard-of-terra 15y ago
      No you don't. Please look up Dom4j which simply lets you do List<Element> nodes = element.selectNodes(XPATH) Element singleNode = element.selectSingleNode(XPATH) it also has .valueOf(XPATH) and even .numberValueOf(XPATH)
      - specialist 15y ago
        But then I'd have to use DOM4j. More seriously, I didn't even think to look at DOM4j again, so didn't know it wrapped JXPath. I had been using XOM for a while, a HUGE improvement over JDOM and DOM4j. Elliot Harold's FAQ and slides explain his improvements. LOX has an even more simple object model, uses JDK 1.5 idioms, and is MUCH easier to interactively debug. (LOX also doesn't recognize namespaces, which keeps it simple.) When it came time to do path expressions, I initially used JXPath and then Jaxen. Both are very hard to debug. After a hard rethink, wanting an API that supports how I like to work, I dropped XPath and came up something a lot more simple, a lot smaller, and closer to how I work. LOX's path expressions have only 1-axis (to use a XPath-ism), parent to child. I've never used any of the other axis, so no big loss. LOX also supports globbing (wildcarding) syntax, which is a huge win over XPath.

specialist 15y ago

I added lightweight path expressions to LOX (Lightweight Objects for XML). It's a modern XML object model, that's easy to inspect, with built in support for xpath-like expressions (globbing, really), without all the suckage. http://code.google.com/p/lox/ http://code.google.com/p/lox/ Here's some example of path expressions. http://code.google.com/p/lox/source/browse/trunk/test/lox/test/Expression.java http://code.google.com/p/lox/source/browse/trunk/test/lox/te... Works fantastically. I use LOX for all my own XML work. My ARON project doesn't support path expressions in the same way. ARON's grammar only supports drill down dot notation, like "parent.child.grandchild". And, thus far, I've only used ARON to loft Java object graphs, so I haven't needed an object model with path expressions. I'd love to see a high level, statically typed language with built-in path expression. Groovy's GPath is closest to the mark that I've seen. (I really need to polish these open source side projects. And publicize them.)

guard-of-terra 15y ago
Making your own is cool, but where's the value added compared to XPath?
- specialist 15y ago
  Thanks! It was a lot of fun and proven very useful. Biggest reason is conciseness (less code), followed by ease of debugging. When using JXPath or Jaxen, you have to use contexts. Pseudo code (from memory): Node n = new Node( "ugh" ); // add some children here JXPathContext c = new JXPathContext( n ); NodeList list = c.eval( "child" ); for( int i = 0; i < list.length(); i++ ) { Node m = (Node) list.get( i ); ... } Whereas LOX does it like this: Element e = new Element( "ugh" ); // Add some children here for( Element e : e.find( "child" )) { ... } I do a lot of ETL work (XML -> SQL). The ability to debug (interactive inspection) speeds development. I'm sure you've tried to debug XPath expressions. Not easy. Happily, all of the LOX's object implement toString() method to render their XML content. And the evaluation of path expressions, while not easy, is feasible. Whereas with JXPath or Jaxen, it's damned near impossible. (I've written a few object adapters for JXPath; getting them right is black magic.)
  - guard-of-terra 15y ago
    No you don't. Please look up Dom4j which simply lets you do List<Element> nodes = element.selectNodes(XPATH) Element singleNode = element.selectSingleNode(XPATH) it also has .valueOf(XPATH) and even .numberValueOf(XPATH)
    - specialist 15y ago
      But then I'd have to use DOM4j. More seriously, I didn't even think to look at DOM4j again, so didn't know it wrapped JXPath. I had been using XOM for a while, a HUGE improvement over JDOM and DOM4j. Elliot Harold's FAQ and slides explain his improvements. LOX has an even more simple object model, uses JDK 1.5 idioms, and is MUCH easier to interactively debug. (LOX also doesn't recognize namespaces, which keeps it simple.) When it came time to do path expressions, I initially used JXPath and then Jaxen. Both are very hard to debug. After a hard rethink, wanting an API that supports how I like to work, I dropped XPath and came up something a lot more simple, a lot smaller, and closer to how I work. LOX's path expressions have only 1-axis (to use a XPath-ism), parent to child. I've never used any of the other axis, so no big loss. LOX also supports globbing (wildcarding) syntax, which is a huge win over XPath.