The 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
JMESPath – A query language for JSON
11–20 of 131 posts
Re: JMESPath – A query language for JSON
#12May 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/
How do this query language compares to jq?
Re: JMESPath – A query language for JSON
#13I'm rather disappointed its not called JPath.
Re: JMESPath – A query language for JSON
#14The example on the front page seems equivalent to (and only marginally less verbose than): locations .filter(l => l.state === 'WA') .map(l => l.name) .sort() .join(', ')
Your example however will not support dynamic or user-configurable paths without eval(). Alternatively, instead of eval you could run expressions through a JS parser, but it'll be more code than your example. The library we're discussing also defines a grammar for the query language.
If we're talking about JS, it would seem to me to be trivial to accomplish, by simply decomposing paths and using bracket notation to access nested props, just like lodash _.get does.
Re: JMESPath – A query language for JSON
#15The 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 still need XSLT for JSON to complete the circle.
Though it seems like XSLT should support JSON:
Re: JMESPath – A query language for JSON
#16I'm rather disappointed its not called JPath.
Unsurprisingly there are already multiple projects called JPath
Re: JMESPath – A query language for JSON
#17The example on the front page seems equivalent to (and only marginally less verbose than): locations .filter(l => l.state === 'WA') .map(l => l.name) .sort() .join(', ')
The benefit of a query language is that it can be described declaratively (i.e. in a non-executable text file, perhaps within JSON itself), and then programs written in any language can execute its query logic using a standard interpreter written in that specific programming language.
So you get reusability of queries across the stack, in all languages that implement a parser against the spec. Your example only provides re-usability in JavaScript, and requires evaluating code at run-time so may not be suitable for queries based on user-submitted data in multi-tenant environments.
Re: JMESPath – A query language for JSON
#18The 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
But can you store XML in a database that is Web Scale?? /s
Re: JMESPath – A query language for JSON
#19The 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
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.
Re: JMESPath – A query language for JSON
#20The 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
But can you store XML in a database that is Web Scale?? /s
Marklogic.... sort of.