I think it would help a lot with languages such as Haskell, where you need to either model the whole JSON tree (when in reality you might only care for 5% of what's in it), or deal with "lenses"....
I think it would help a lot with languages such as Haskell, where you need to either model the whole JSON tree (when in reality you might only care for 5% of what's in it), or deal with "lenses". Here you would express what you care about as one JMESPath query, and only parse the output of the query. And sure enough there is a Haskell module for it:
This looks great. I feel like it's something data scientists and the like would benefit a lot for data extraction and structuration when digging in large data sets.
This looks great. I feel like it's something data scientists and the like would benefit a lot for data extraction and structuration when digging in large data sets.
This seems very similar to the jq tool in terms of query structure. Has anyone played with both of them and would care to comment on the differences? I would expect that the jq query language...
This seems very similar to the jq tool in terms of query structure. Has anyone played with both of them and would care to comment on the differences? I would expect that the jq query language isn't formally verified (assuming it is different).
Well, jq is one tool, this is a specification that can be implemented as libraries or independent tools. I've read that jq is more powerful than this, but if this can become ubiquitous, I think...
Well, jq is one tool, this is a specification that can be implemented as libraries or independent tools.
I've read that jq is more powerful than this, but if this can become ubiquitous, I think it's even more interesting.
It looks pretty cool. Though I am not sure if it will gain any traction like XMLQuery. Even more so since Json is usually directly parsed into models.
I think it would help a lot with languages such as Haskell, where you need to either model the whole JSON tree (when in reality you might only care for 5% of what's in it), or deal with "lenses". Here you would express what you care about as one JMESPath query, and only parse the output of the query. And sure enough there is a Haskell module for it:
https://github.com/gcapizzi/jamespath-hs
How interesting, I've struggled with this before in a few different languages and this could help out massively in terms of overhead
This looks great. I feel like it's something data scientists and the like would benefit a lot for data extraction and structuration when digging in large data sets.
I would try to avoid JSON for large datasets, though.
I agree, but I see pretty much everyday people working with huge geoJson sets, I was thinking about them!
This seems very similar to the
jqtool in terms of query structure. Has anyone played with both of them and would care to comment on the differences? I would expect that the jq query language isn't formally verified (assuming it is different).Well,
jqis one tool, this is a specification that can be implemented as libraries or independent tools.I've read that
jqis more powerful than this, but if this can become ubiquitous, I think it's even more interesting.