JSON Query - a small, flexible, and expandable JSON query language
15 points by wofo
15 points by wofo
The word "expand" appears on this page twice, once in the heading and once in the first paragraph: https://jsonquerylang.org/docs/
Does anyone know what is the expansion story?
I don't know, but that might refer to the JSON array "intermediate" form of queries.
Or maybe it's about using custom functions, as I see in the Python implementation README.
JMESPath, JSONPath, jq, I'm sure there are others. Can the body that standardizes JSON also standardize a query language for it that everything else can implement and build on top of?
I’ve tried the others but I wish we could standardize a subset of jq
Except for the formality of ECMA or ISO, there already are multiple implementations, which is one of the hallmarks of "can normal people implement this?" and "is the 'specification' clear enough?" I appreciate that for the 2nd one, it's very, very likely that the other implementations read the "reference implementation" source code, since I'm not aware of a specified grammar nor SDK but jq's man page is pretty decent as far as reference text goes
I don't find "special characters" problematic in languages, so long as their behavior is very well defined, as is certainly the case in both regex and jq, so I will never be the target audience for these "simpler," yet demonstrably less expressive, other languages
"Body" 😂
It’s just Crockford. He put up a website one day and that was the standard.
I had heard something like the first versions of JSON had comments, but "they were removed" in subsequent versions to dissuade users from building DSLs in comments. Not sure if that's true, but I just assumed "they" was more than a single guy. This explains a lot about JSON query language proliferation.
The linked video clip reminds me of Michael Scott "declaring" bankruptcy in The Office, except Douglas Crockford "declared" a JSON standard and it worked!
Having recently implemented a SQL-like query engine for IndexedDB, I’m tempted to add a JSON Query front-end — it’s actually similar to the execution engine that I compile queries into. And I do like this functional LINQ-ish syntax compared to the antique syntax of SQL.
Having once worked with / contributed to XML Query (far too late to help save it from itself), I was honestly expecting to see a disaster of complexity when I clicked on this.
This looks almost tempting to try. There's some nice simplicity here that is hard to achieve without some real effort.
I like this! Looks much more intuitive than jq.
I was going to say "pfft It's basically the same as jq!" but then I converted example 1 and ...
[[.friends[]|select(.city=="New York")]|sort_by(.age)[]|{name:.name, age:.age}]
Example 2 isn't -quite- as egregious but, yeah, JSON Query is definitely winning here.
[.[]|select(.city=="New York" and .age > 30)]
(But stuff like this could/should be addressed by jq - e.g. select works on an array; if it's the first thing in the expression, you can obviously insert an implicit .[]| before it. If it's not the first thing, you add an implicit [] to the previous step. etc. Same for expressions that must output a list - implicitly wrap it in [...]; the output of select being a great example here.)
In the course of translating one of the other examples, it turns out that you can use map (which can take an array) at the top level without having to faff around with .[]. Bloody annoying inconsistence.
e.g. echo [1,2,3,4,5,6] | jq -c 'map(. * 100)' gives [100,200,300,400,500,600] but select(. % 2 == 1) is an error without the leading .[].