Except that, with certain caveats, XML has a slightly nicer syntax for text-heavy documents, and JSON is slightly nicer for hardcore data representation. For example, I'd much rather have a web page in HTML than JSON, but I'd rather have a config file in the latter.
You wouldn't make that same comparison with regular expressions(tool) and a text document(data) would you?
As in, the tool is not part and parcel of the data.
XPath(and JSONPath) are powerful tools for programatically pulling data from complex data structures.
There is a fairly straightforward generalization of the 'axis' concept to allow graph traversal: 'GPath'. (You have to add an annotation for a traversal kind, and an identifier for a property map.) XPath can be straightforwardly desugared to GPath. I implemented this years ago for an EDG IPR[1] back-end, hooked up a number of 'standard queries' over C++ to Todd Veldhuizen's live OpenGL force-directed graph-viewer [2], and watched EDG compile code---pretty wild stuff watching expressions 'bloom', and classes 'become referenced', etc.
For those that prefer a command line tool, jq has been around for a while and works very well.
I can't count how many times jq let me hack together a bunch of commands I normally would have had to write a small program for. e.g small script that pushes the latest semver tag from a github repo to a geckoboard text widget: https://gist.github.com/jdc0589/67df901f71d96b7649b4
14 comments
[ 2.7 ms ] story [ 49.8 ms ] threadYou could just do this with http://jsonunroller.appspot.com/ and grep.
You wouldn't make that same comparison with regular expressions(tool) and a text document(data) would you? As in, the tool is not part and parcel of the data.
XPath(and JSONPath) are powerful tools for programatically pulling data from complex data structures.
[1] https://parasol.tamu.edu/pivot/ [2] http://ubietylab.net
https://stedolan.github.io/jq/
http://stedolan.github.io/jq/