Soon we'll have JSLT. JSON Query, JSON Pointer, JSON signatures etc are already there.
And I say that as a conscious XML user. We are going in circles. At least XML has comments.
And I say that as a conscious XML user. We are going in circles. At least XML has comments.
That said, there are plenty of examples. JSONPath, JQ, Jolt...
I am not claiming that this is not useful. Just amused to see the wheel go around.
For a simple, most frequently used subset of jq a more modest, non-Turing-complete language of transforming strings could be created, so that for many useful cases one just need to provide such a string. Strictly for JSON -> JSON.
XPath really started to show the warts here - it leveraged namespaces as an axis, where your XPath could utilize namespaces which were defined at a particular element in the XSLT. However, this went against generalized tooling, as you had to understand which attributes or text were paths in order to know if namespaces had semantic value beyond the XML syntax itself.
IMHO, Canonical XML and XML Infosets were an effort to ret-con the new behavior back in - that namespaces and prefixes were not just used to serialize XML arbitrarily, but were semantically important parts of the XML itself. But at this point XML was too large to evolve - even XML 1.1 had relatively little market uptake.
On top of that, you had issues with how e.g. Microsoft Internet Explorer had divergent behavior for XSLT from other browsers/the spec.
<{http://my.example.com/ns/fruit}citrus> ... </{http://my.example.com/ns/fruit}citrus>
Sure, it's textual bloat, but XML was already verbose and already compressed well with gzip, and it's a lot simpler to process.
The problem with the xmlns:alias="url" rewriting thing was that 1) most things didn't bother implementing it in full, and ended up e.g. relying on the name of the chosen alias 2) it had a special case of changing the current default namespace, which caused even more bad implementations.
I guess you could do something like that with redis but at the time it was magic.
JSON Schema is something that address stability guarantees for JSON - where JSON was invented to be easy to change so it skips heavy XML stuff that was giving stability guarantees.
Now people involved in JSON Schema have problem with decision on stability guarantees - if they skip those or keep it backwards compatible...
because one thing is for sure, json schema and openapi are not really nicely readable, even if written as yaml