May also be interested in the `jq` CLI, which on first glance appears to use a similar but not identical query language. https://stedolan.github.io/jq/
Also this tool is pretty interesting: https://github.com/chrisdone/jl
JMESPath – A query language for JSON
31–40 of 131 posts
Re: JMESPath – A query language for JSON
#32Earlier quoted context omitted.
Is that a bad thing? For cases where the document is at least partially written by hand it makes sense to replace XML with something more friendly, such as JSON or YAML.
Wasn't the basic idea of JSON to be small and unstructured to be sent between applications? Shoehorning everything into JSON that is already solved by XML seems illogical, as GP already said. It reeks of NIH. People shouldn't use JSON for anything hand-written. YAML or even the older INI format are way better suited for configuration files for one reason alone: they allow comments.
Small, or smaller than XML, yes. Unstructured — why?
Re: JMESPath – A query language for JSON
#33The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc
We can create first-class arrays in JSON.
Re: JMESPath – A query language for JSON
#34There is also JSON Pointer ( https://tools.ietf.org/html/rfc6901 ) from IETF. Very simple standard and easy to implement, but not as powerful as jmespath nor jq.
To say that it’s “from IETF” is sort of a misnomer I think. RFCs are submitted to IETF by others, not by IETF itself.
Re: JMESPath – A query language for JSON
#35May also be interested in the `jq` CLI, which on first glance appears to use a similar but not identical query language. https://stedolan.github.io/jq/
I'd rather use App::RecordStream.
Re: JMESPath – A query language for JSON
#36I love JMESPath. I first discovered it when using the AWS CLI `--query` option[0].
I then realized that using it in my code would make things much more declarative and easy to grok than a bunch of maps, filters etc. Here's a real example which I think illustrates it[1]. It has libraries for lots of languages with a clear specification/compliance test[2].
The cherry on the top is the interactive query on the website. You can tweak any of the examples (both queries and data) and get results instantly. Extremely useful for playing around, building queries to work with JSON data (webhooks, API responses etc)
[0] https://docs.aws.amazon.com/cli/latest/userguide/controlling...
[1] https://gist.github.com/gingerlime/757c7b4778c1ab68605dfce66...
Re: JMESPath – A query language for JSON
#37The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc
The "reinvention" is not complete and will never be necessary. The difference is that XPath is necessary to query XML because it's a botched horribly overcomplicated, designed-by-committee markup language. Except for tools like jq no such language is actually required for JSON because it maps on to language structures that always exist. Neither JSON schema or XML schema are particularly popular - and for good reason.…
That ability to use outside canonical sources is really interesting. Are there some existing examples of schema languages with that feature?
Re: JMESPath – A query language for JSON
#38The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc
JSON still doesn’t support comments though, they need to work on that.
Re: JMESPath – A query language for JSON
#39Does this have any mathematical foundation like the relational algebra for SQL? Or more generally, does a mathematical framework exist to treat this or similar constructs and that goes beyond what relational algebra provides and that, for example, also handles aggregate functions?
The reason I am asking is that I am currently trying to build a tool to analyze a kind of time series data, think log file entries, in order to look for anomalies and visualize them. I could of course just build all the transformations I am interested in in an ad hoc fashion but it would be nice to have a mathematical framework in order to start out with a small set of basic operations and then compose those while having some guarantees about the expressiveness of that the basic operations and ideally also a rigorous foundation for transforming them, for example for performance optimizations.
But so far I was unable to find something that seems fitting, everything I am aware of is either to limited like relational algebra or way to general like general functions. It feels like what I am looking for should exist but I am unable to find it.
Re: JMESPath – A query language for JSON
#40The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc
Isn't that what we want? I would think that solving the same problems for a less verbose format is a good thing. And looking at the examples and the library support ( http://jmespath.org/libraries.html ) I would say this solves a real problem. I can already think of several use cases for my own system. The fact that a solution is treading familiar ground does not invalidate its utility.
It's not very much less verbose, really. You still need a key and a value. The only thing you lose, really, is the end tag. For a complex text document in say TEI or Docbook, I don't see how this is much of an advantage.