5 ms·

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 leas

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.

taeric 4y ago
I legit saw a team asking for a tool that does JSON -> JSON transformations at work. The XSLT for JSON vibes were almost too strong.
- avmich 4y ago
  That's jq. At least useful for a lot of transformations.
  - taeric 4y ago
    A little different, but yeah. (If I'm not mistaken, xslt had a bit more of a defined language and way more formalism.) 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.
    - avmich 4y ago
      Oh, it absolutely goes around in this industry. 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.
  - silon42 4y ago
    yes, jq is XSLT (and more) for JSON
    - taeric 4y ago
      and more?
avmich 4y ago
It's not "at least", it's arguably a different approach to a similar, but not equal, problem of having data structure.
throwawaymaths 4y ago
JSONschema uses jsonpointer.
lmm 4y ago
The problem with XSLT wasn't that it was a fundamentally bad design, the problem was the horrible syntax. Well, and namespaces.
- smrtinsert 4y ago
  what was the problem? there's templates and queries and it seemed pretty clear once you read a quick intro.
  - hyperthesis 4y ago
    syntax < semantics
  - dwaite 4y ago
    Namespaces in XML was a bit of a bolt-on, and really showed the difference between the crowd who wanted to create XML to simplify defining new markup languages like HTML (the originators) and the XML as data crowd who wanted generalized tooling to support all XML data. 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.
    - yencabulator 4y ago
      They really should have made namespaces just be {url} prefixes on element and attribute names. <{http://my.example.com/ns/fruit}citrus http://my.example.com/ns/fruit}citrus> ... </{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.
halfmatthalfcat 4y ago
Trying to figure out how to get from XSD to anything else in order to work with a huge dataset. Wish there was an easier way to go from XSD -> JSONSchema -> Language Model so I could go from XML straight to my language of choice (Typescript in this instance). There don’t seem to be a ton of choices from XSD -> Language either.
gleenn 4y ago
The jq cli tool/language is awesome already. The person who wrote it was also interestingly very competitive in Advent if Code with it too.
outworlder 4y ago
At this rate, we'll be back to S-expressions in 50 years or so.
- peterkelly 4y ago
  Some of us never left :)
smackeyacky 4y ago
I miss working with xslt - I was once handed an API specified in xsd and we wrote an xslt script that turned it into an SQL script that built all the tables and insert/update/delete stored procedures so we could log all the calls. I guess you could do something like that with redis but at the time it was magic.
dathinab 4y ago
next is using a (subset) of typescript for human consumption and concert that to json for machine consumption because one thing is for sure, json schema and openapi are not really nicely readable, even if written as yaml
ozim 4y ago
You know what is funniest part is? 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...

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.

taeric 4y ago

I legit saw a team asking for a tool that does JSON -> JSON transformations at work. The XSLT for JSON vibes were almost too strong.

avmich 4y ago
That's jq. At least useful for a lot of transformations.
- taeric 4y ago
  A little different, but yeah. (If I'm not mistaken, xslt had a bit more of a defined language and way more formalism.) 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.
  - avmich 4y ago
    Oh, it absolutely goes around in this industry. 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.
- silon42 4y ago
  yes, jq is XSLT (and more) for JSON
  - taeric 4y ago
    and more?

avmich 4y ago

It's not "at least", it's arguably a different approach to a similar, but not equal, problem of having data structure.

throwawaymaths 4y ago

JSONschema uses jsonpointer.

lmm 4y ago

The problem with XSLT wasn't that it was a fundamentally bad design, the problem was the horrible syntax. Well, and namespaces.

smrtinsert 4y ago
what was the problem? there's templates and queries and it seemed pretty clear once you read a quick intro.
- hyperthesis 4y ago
  syntax < semantics
- dwaite 4y ago
  Namespaces in XML was a bit of a bolt-on, and really showed the difference between the crowd who wanted to create XML to simplify defining new markup languages like HTML (the originators) and the XML as data crowd who wanted generalized tooling to support all XML data. 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.
  - yencabulator 4y ago
    They really should have made namespaces just be {url} prefixes on element and attribute names. <{http://my.example.com/ns/fruit}citrus http://my.example.com/ns/fruit}citrus> ... </{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.

halfmatthalfcat 4y ago

Trying to figure out how to get from XSD to anything else in order to work with a huge dataset. Wish there was an easier way to go from XSD -> JSONSchema -> Language Model so I could go from XML straight to my language of choice (Typescript in this instance). There don’t seem to be a ton of choices from XSD -> Language either.

gleenn 4y ago

The jq cli tool/language is awesome already. The person who wrote it was also interestingly very competitive in Advent if Code with it too.

outworlder 4y ago

At this rate, we'll be back to S-expressions in 50 years or so.

peterkelly 4y ago
Some of us never left :)

smackeyacky 4y ago

I miss working with xslt - I was once handed an API specified in xsd and we wrote an xslt script that turned it into an SQL script that built all the tables and insert/update/delete stored procedures so we could log all the calls. I guess you could do something like that with redis but at the time it was magic.

dathinab 4y ago

next is using a (subset) of typescript for human consumption and concert that to json for machine consumption because one thing is for sure, json schema and openapi are not really nicely readable, even if written as yaml

ozim 4y ago

You know what is funniest part is? 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...