6 ms·

Is JSON XML yet? Nearly! I’m going to invent Baz’s 11th law of computing here: any data format that isn’t XML will evolve into a badly specified version of XML

by baz00 3y ago

Is JSON XML yet? Nearly! I’m going to invent Baz’s 11th law of computing here: any data format that isn’t XML will evolve into a badly specified version of XML over time.

heresie-dabord 3y ago
Corollary: The number (N) of ad hoc support tools needed to do any serious work with a given mark-up language is proportional to the naivety of the implementation (Y).
- baz00 3y ago
  I like this one a lot.
kevingadd 3y ago
With respect for the pain everyone has suffered through due to XML... at this point I prefer XML with a good schema to JSON any day, even if it's more verbose and more awkward to hand-edit. It's just so much easier to validate it or generate code to handle it, and you get things like XSLT or XPath if you want them.
- Deukhoofd 3y ago
  I mean, you can use JSON Schema as well to have similar functionality to XML Schema.
  - znpy 3y ago
    That's exactly the point being made: json is becoming xml.
    - tgv 3y ago
      The point also feels like passive-aggressively ignoring the reason why people use JSON and not XML.
      - Devasta 3y ago
        Honestly for a lot of people they use JSON because thats what they have always used; XMLs heyday was like 15 years ago, you could be a very senior engineer now and have never touched XML.
      - w23j 3y ago
        Can you name some of these reasons? Or give me link? Honest question!
        alpaca128 3y ago
        One reason would be massively reduced syntax overhead and better readability. I've seen plenty of XML files where XML syntax makes up more than 50% of the file's content, and trying to read the actual content is tedious. Now JSON isn't ideal either - technically you could get rid of all commas, colons, and the quotes around most keys - but I sure prefer `{"foo": "some \"stuff\""}` over something like `<foo><![CDATA[some <stuff>]]></foo>`
        w23j 3y ago
        I agree, I would prefer JSON (or YAML) for example for configuration files. That is for stuff that humans actually read. I was thinking about using JSON/XML as a data exchange format between computers, because the context of this discussion has revolved about things like JSON/XML-Schema, JSON/XPath and SOAP/OpenAPI. There is a large trend to replace XML with JSON as data format for inter machine communication, and it is confusing to me.
        tgv 3y ago
        XML is too unwieldy for human consumption. Editing it is error-prone, and those schema-directed editors are even worse, because everything requires clicking and clicking and clicking. For machine-to-machine communication, it's very well suited, but most data is simple enough, and the XML libraries I've used tended to be --let's say-- over-engineered, while there are no hoops to jump through when you want to parse JSON. And one thing I always disliked about XML was the CDATA section: it makes the message even harder to read, and it's not like you're going to use that binary data unparsed/unchecked. XML just tried to formalize data transfer and description prematurely, which made it rigid and not even sufficiently powerful. I must say that XSLT and XPath were great additions, though.
  - w23j 3y ago
    I haven't looked at JSON Schema in detail so please correct me if I am wrong, but I had the impression that the JSON Schema specification is still largely unfinished and evolving. That means you need to know which version the tool you use supports. And when I was looking for JSON Schema validators for Java all I found were projects on GitHub, which often were abandoned and referred the user to another GitHub project which was also abandoned. There does not seem to be support from an established project or vendor. Compare that to XML where we have a plethora of established tools (Woodstoxx, JAXB, etc.). What I have trouble to understand, which everybody else just seems to accept as obvious, is why one would take on these problems? Is JSON Schema more powerful than XML Schema? Does the use of JSON have advantages over using XML? When we are talking about a client program calling a server API with JSON/XML, why do we care about the format of data exchanged? What advantages does JSON have in this case in contrast to XML (or for that matter a binary format like Protocol Buffers)? Isn't this the most boring part of the application, which you would want to just get out of the way and work? What are the advantages of JSON over XML that would lead me to deal with the problems of evolving specifications and unreliable tooling? (And just to repeat, since everybody seems to have a different opinion about this than me, I must be missing something and really would like to learn what!)
    - pydry 3y ago
      All schema languages are a bit like that. You can almost always add another layer on top of the validation and screw down the validation a bit harder. The strictest validation will only be achievable using a turing complete language. OpenAPI is probably used a bit more than json schema, but it's contextually limited to APIs (which, to be fair, is mostly what JSON is used for).
      - w23j 3y ago
        I probably phrased my question poorly. Why would I use a tool which is not or poorly maintained for a probably already outdated version of a specs, when I can use something else, that has been used for years by countless companies in productions? The advantages must be huge. And I don't know what they are. OpenAPI is another example. There are threads on hacker news about generating code from OpenAPI specs. These always seem to say "oh, yes don't use tool X, use tool Y it does not have that problem, although it also doesn't support Z". The consensus seems to be to not generate code from an OpenAPI specification but to just use it as documentation, since all generators are more or less broken. Contrast that with for example JAXB (which is not an exact replacement I know), which has been battle tested for years.
Traubenfuchs 3y ago
As someone who greatly enjoyed the rigidity of SOAP/xml, which made proper architectural planning and careful deprecation mandatory, I wonder where we went so wrong. I feel like it's all connected to the impreciseness and typelessness of JavaScript. SOAP/xml to generate well defined client and server entry points in Java is how things should be done and SoapUI was a pleasure to use.
- Devasta 3y ago
  Honestly, I think a big reason is that Stack Overflow didn't exist at XMLs peak, so you had people generating XML by concatenation, to predictably disastrous results. One of the first XSLT transforms I was ever given to maintain generated XML by the same method. <xsl:text><PRICE></xsl:text><xsl:value-of select="PRICE"/><xsl:text></PRICE></xsl:text> and so on.
- pjc50 3y ago
  > made proper architectural planning and careful deprecation mandatory That's why it never caught on. The ability of JSON/Javascript to tape together kinda-working solutions before and instead of any kind of specification works is hugely powerful, because it allows iterating on the requirements by having actual users use the app.
  - touisteur 3y ago
    I mean I've always found this enlightening, when hearing json is 'simple': https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
- aidos 3y ago
  The S stands for Simple http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
  - PhilipRoman 3y ago
    Thanks for sharing this, somehow I missed this while reading cat-v. Definitely applicable to a couple of other technologies too...
nine_k 3y ago
I'd say there must exist a more ancient law, stating that a representation of s-expressions is reinvented whenever a need arises for a generic data format. S-expressions are the most direct representation of a tree: (root node node ...). Trees are everywhere, they represent any nested structure; lists are logically a subset of trees. XML is a tree. It has the weird "attribute" node types, a legacy of SGML text markup notation. JSON is a tree, obviously. So is protobuf, thrift, etc. They all could be serialized as s-expressions. Now, a schema that destined a tree is also a tree. Hence XML Schema, JSONSchema, etc. More, an abstract program that describes a transformation of a tree is also a tree; this products homoiconic languages, from XSLT to Lisps. There is nothing special about XML; it's just a particular case of a generic law.
- baz00 3y ago
  Completely agree on all points. But there is something special about XML: everyone has failed to make something better.
  - dragonwriter 3y ago
    > Completely agree on all points. But there is something special about XML: everyone has failed to make something better. XML’s decline from its peak of adoption mean lots of people working with data disagree with you.
  - alpaca128 3y ago
    If you said nothing better became an industry standard I could see your point, but how exactly is XML better than s-expressions? Or, if you want something less generalized, KDL (which is roughly XML with 90% less syntax overhead)?
    - baz00 3y ago
      XML has superset defined functionality of standardised schemas, transformations and query. The same is not true for s-expressions. I've not looked at KDL before but a quick scan suggests it's interesting. I will look into it.
tannhaeuser 3y ago
JSON can be parsed using SGML [1], by instructing SGML to interpret JSON tokens such as colons, quotation marks, and curly braces as markup. The underlying technique for custom lightweight markup is called SHORTREF and can be applied to markdown etc. as well. So considering XML is subsetted from SGML, I guess the answer is closer to yes than thought. Though probably it's worth citing the following quote from that paper: > If the sweet spot for XML and SGML is marking up “prose documents”, the sweet spot for JSON is collections of atomic values. [1]: https://www.balisage.net/Proceedings/vol17/html/Walsh01/BalisageVol17-Walsh01.html https://www.balisage.net/Proceedings/vol17/html/Walsh01/Bali...
- lifthrasiir 3y ago
  > JSON can be parsed using SGML, [...]. So considering XML is subsetted from SGML, I guess the answer is closer to yes than thought. In the other words, SGML was way too powerful than what we actually needed. Of course we are with the benefit of hindsight though.
  - tannhaeuser 3y ago
    > SGML was way too powerful The widespread use of markdown and other lightweight markup rather than rigid XML-style fully tagged markup for authoring tells otherwise though. And so does the continued use of HTML chock full of SGMLisms such as tag inference and attribute shortforms that weren't included in the XML subset/profile when XML (XHTML) was created to replace HTML. So while XML isn't used as an authoring format on the web (nor as delivery format), it's still useful as canonical archival format I guess.
    - lifthrasiir 3y ago
      SGML is a meta-language unlike every other example in your reply, so the prevalence of such semi-structured languages (including SGML applications) doesn't justify SGML itself. Even HTML is not exactly an SGML application (except for HTML 4), and in my knowledge implementing HTML with a generic SGML implementation was rarely done. So the fact that SGML is a near superset of both JSON and XML doesn't mean much.
dgellow 3y ago
XML has other abominations such as XSLT.
- baz00 3y ago
  I'd definitely rather write XSLT than YAML festering in the same pot as go-template.
  - dgellow 3y ago
    Fair, yaml + go templates is it’s own horror… nightmares of generating k8s manifests…
strken 3y ago
People say this, and yet XML's origins as a markup language make it baffling as a data format. No sane human being should choose a data format with such confusion between properties that no user knows whether to go with <Foo> <Shininess>HIGH</Shininess> <Luck>7</Luck> </Foo> or <Foo shininess="HIGH" luck="7" /> and yet countless thousands decided to do just that, for reasons that are totally inexplicable to me. Obviously as a markup language this is fine; as a data format it's bizarre, since the division between attribute vs child doesn't match most in-memory data structures.
- pydry 3y ago
  Yeah, it's a weird attitude. XML died out because it was an overcomplicated design-by-committee mess. Quite apart from the fact that meant it wouldn't map cleanly to lists and hashmaps, necessitating a query language it also led to embarrassing debacles like the billion laughs vulnerability - problem in the very core of XML. With some niche exceptions where it has clung on, XML basically died. It's time to move on. The fact that we do similar sorts of stuff with JSON like data transformations and schema validation does not, in any way, shape or form, invalidate its flaws.
  - baz00 3y ago
    XML is fine. The overcomplicated mess was the WS-* garbage.
- smikhanov 3y ago
  no user knows The described problem literally doesn't exist in XML. Your XML-validating editor will check your document against the schema and will not allow for an attribute where the sub-element is required and vice versa.
  - tyingq 3y ago
    I believe they mean for designing the schema in the first place. Meaning the impedance match between JSON and their chosen language is usually more natural.
crabmusket 3y ago
I see this take often and I think it's pretty bad. JSON (data format) and XML (markup format) are very different. Building tools for JSON doesn't change that in any way. And it turns out that both JSON and XML are used for data interchange, and when people have data interchange problems, they build tooling to help solve those problems (like schema validation). That doesn't make JSON "like XML", it just means they're discovering the same problem and solving it for the format they're using.

by baz00 3y ago

Is JSON XML yet? Nearly! I’m going to invent Baz’s 11th law of computing here: any data format that isn’t XML will evolve into a badly specified version of XML over time.

heresie-dabord 3y ago

Corollary: The number (N) of ad hoc support tools needed to do any serious work with a given mark-up language is proportional to the naivety of the implementation (Y).

baz00 3y ago
I like this one a lot.

kevingadd 3y ago

With respect for the pain everyone has suffered through due to XML... at this point I prefer XML with a good schema to JSON any day, even if it's more verbose and more awkward to hand-edit. It's just so much easier to validate it or generate code to handle it, and you get things like XSLT or XPath if you want them.

Deukhoofd 3y ago
I mean, you can use JSON Schema as well to have similar functionality to XML Schema.
- znpy 3y ago
  That's exactly the point being made: json is becoming xml.
  - tgv 3y ago
    The point also feels like passive-aggressively ignoring the reason why people use JSON and not XML.
    - Devasta 3y ago
      Honestly for a lot of people they use JSON because thats what they have always used; XMLs heyday was like 15 years ago, you could be a very senior engineer now and have never touched XML.
    - w23j 3y ago
      Can you name some of these reasons? Or give me link? Honest question!
      - alpaca128 3y ago
        One reason would be massively reduced syntax overhead and better readability. I've seen plenty of XML files where XML syntax makes up more than 50% of the file's content, and trying to read the actual content is tedious. Now JSON isn't ideal either - technically you could get rid of all commas, colons, and the quotes around most keys - but I sure prefer `{"foo": "some \"stuff\""}` over something like `<foo><![CDATA[some <stuff>]]></foo>`
        w23j 3y ago
        I agree, I would prefer JSON (or YAML) for example for configuration files. That is for stuff that humans actually read. I was thinking about using JSON/XML as a data exchange format between computers, because the context of this discussion has revolved about things like JSON/XML-Schema, JSON/XPath and SOAP/OpenAPI. There is a large trend to replace XML with JSON as data format for inter machine communication, and it is confusing to me.
      - tgv 3y ago
        XML is too unwieldy for human consumption. Editing it is error-prone, and those schema-directed editors are even worse, because everything requires clicking and clicking and clicking. For machine-to-machine communication, it's very well suited, but most data is simple enough, and the XML libraries I've used tended to be --let's say-- over-engineered, while there are no hoops to jump through when you want to parse JSON. And one thing I always disliked about XML was the CDATA section: it makes the message even harder to read, and it's not like you're going to use that binary data unparsed/unchecked. XML just tried to formalize data transfer and description prematurely, which made it rigid and not even sufficiently powerful. I must say that XSLT and XPath were great additions, though.
- w23j 3y ago
  I haven't looked at JSON Schema in detail so please correct me if I am wrong, but I had the impression that the JSON Schema specification is still largely unfinished and evolving. That means you need to know which version the tool you use supports. And when I was looking for JSON Schema validators for Java all I found were projects on GitHub, which often were abandoned and referred the user to another GitHub project which was also abandoned. There does not seem to be support from an established project or vendor. Compare that to XML where we have a plethora of established tools (Woodstoxx, JAXB, etc.). What I have trouble to understand, which everybody else just seems to accept as obvious, is why one would take on these problems? Is JSON Schema more powerful than XML Schema? Does the use of JSON have advantages over using XML? When we are talking about a client program calling a server API with JSON/XML, why do we care about the format of data exchanged? What advantages does JSON have in this case in contrast to XML (or for that matter a binary format like Protocol Buffers)? Isn't this the most boring part of the application, which you would want to just get out of the way and work? What are the advantages of JSON over XML that would lead me to deal with the problems of evolving specifications and unreliable tooling? (And just to repeat, since everybody seems to have a different opinion about this than me, I must be missing something and really would like to learn what!)
  - pydry 3y ago
    All schema languages are a bit like that. You can almost always add another layer on top of the validation and screw down the validation a bit harder. The strictest validation will only be achievable using a turing complete language. OpenAPI is probably used a bit more than json schema, but it's contextually limited to APIs (which, to be fair, is mostly what JSON is used for).
    - w23j 3y ago
      I probably phrased my question poorly. Why would I use a tool which is not or poorly maintained for a probably already outdated version of a specs, when I can use something else, that has been used for years by countless companies in productions? The advantages must be huge. And I don't know what they are. OpenAPI is another example. There are threads on hacker news about generating code from OpenAPI specs. These always seem to say "oh, yes don't use tool X, use tool Y it does not have that problem, although it also doesn't support Z". The consensus seems to be to not generate code from an OpenAPI specification but to just use it as documentation, since all generators are more or less broken. Contrast that with for example JAXB (which is not an exact replacement I know), which has been battle tested for years.

Traubenfuchs 3y ago

As someone who greatly enjoyed the rigidity of SOAP/xml, which made proper architectural planning and careful deprecation mandatory, I wonder where we went so wrong. I feel like it's all connected to the impreciseness and typelessness of JavaScript. SOAP/xml to generate well defined client and server entry points in Java is how things should be done and SoapUI was a pleasure to use.

Devasta 3y ago
Honestly, I think a big reason is that Stack Overflow didn't exist at XMLs peak, so you had people generating XML by concatenation, to predictably disastrous results. One of the first XSLT transforms I was ever given to maintain generated XML by the same method. <xsl:text><PRICE></xsl:text><xsl:value-of select="PRICE"/><xsl:text></PRICE></xsl:text> and so on.
pjc50 3y ago
> made proper architectural planning and careful deprecation mandatory That's why it never caught on. The ability of JSON/Javascript to tape together kinda-working solutions before and instead of any kind of specification works is hugely powerful, because it allows iterating on the requirements by having actual users use the app.
- touisteur 3y ago
  I mean I've always found this enlightening, when hearing json is 'simple': https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
aidos 3y ago
The S stands for Simple http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
- PhilipRoman 3y ago
  Thanks for sharing this, somehow I missed this while reading cat-v. Definitely applicable to a couple of other technologies too...

nine_k 3y ago

I'd say there must exist a more ancient law, stating that a representation of s-expressions is reinvented whenever a need arises for a generic data format. S-expressions are the most direct representation of a tree: (root node node ...). Trees are everywhere, they represent any nested structure; lists are logically a subset of trees. XML is a tree. It has the weird "attribute" node types, a legacy of SGML text markup notation. JSON is a tree, obviously. So is protobuf, thrift, etc. They all could be serialized as s-expressions. Now, a schema that destined a tree is also a tree. Hence XML Schema, JSONSchema, etc. More, an abstract program that describes a transformation of a tree is also a tree; this products homoiconic languages, from XSLT to Lisps. There is nothing special about XML; it's just a particular case of a generic law.

baz00 3y ago
Completely agree on all points. But there is something special about XML: everyone has failed to make something better.
- dragonwriter 3y ago
  > Completely agree on all points. But there is something special about XML: everyone has failed to make something better. XML’s decline from its peak of adoption mean lots of people working with data disagree with you.
- alpaca128 3y ago
  If you said nothing better became an industry standard I could see your point, but how exactly is XML better than s-expressions? Or, if you want something less generalized, KDL (which is roughly XML with 90% less syntax overhead)?
  - baz00 3y ago
    XML has superset defined functionality of standardised schemas, transformations and query. The same is not true for s-expressions. I've not looked at KDL before but a quick scan suggests it's interesting. I will look into it.

tannhaeuser 3y ago

JSON can be parsed using SGML [1], by instructing SGML to interpret JSON tokens such as colons, quotation marks, and curly braces as markup. The underlying technique for custom lightweight markup is called SHORTREF and can be applied to markdown etc. as well. So considering XML is subsetted from SGML, I guess the answer is closer to yes than thought. Though probably it's worth citing the following quote from that paper: > If the sweet spot for XML and SGML is marking up “prose documents”, the sweet spot for JSON is collections of atomic values. [1]: https://www.balisage.net/Proceedings/vol17/html/Walsh01/BalisageVol17-Walsh01.html https://www.balisage.net/Proceedings/vol17/html/Walsh01/Bali...

lifthrasiir 3y ago
> JSON can be parsed using SGML, [...]. So considering XML is subsetted from SGML, I guess the answer is closer to yes than thought. In the other words, SGML was way too powerful than what we actually needed. Of course we are with the benefit of hindsight though.
- tannhaeuser 3y ago
  > SGML was way too powerful The widespread use of markdown and other lightweight markup rather than rigid XML-style fully tagged markup for authoring tells otherwise though. And so does the continued use of HTML chock full of SGMLisms such as tag inference and attribute shortforms that weren't included in the XML subset/profile when XML (XHTML) was created to replace HTML. So while XML isn't used as an authoring format on the web (nor as delivery format), it's still useful as canonical archival format I guess.
  - lifthrasiir 3y ago
    SGML is a meta-language unlike every other example in your reply, so the prevalence of such semi-structured languages (including SGML applications) doesn't justify SGML itself. Even HTML is not exactly an SGML application (except for HTML 4), and in my knowledge implementing HTML with a generic SGML implementation was rarely done. So the fact that SGML is a near superset of both JSON and XML doesn't mean much.

dgellow 3y ago

XML has other abominations such as XSLT.

baz00 3y ago
I'd definitely rather write XSLT than YAML festering in the same pot as go-template.
- dgellow 3y ago
  Fair, yaml + go templates is it’s own horror… nightmares of generating k8s manifests…

strken 3y ago

People say this, and yet XML's origins as a markup language make it baffling as a data format. No sane human being should choose a data format with such confusion between properties that no user knows whether to go with <Foo> <Shininess>HIGH</Shininess> <Luck>7</Luck> </Foo> or <Foo shininess="HIGH" luck="7" /> and yet countless thousands decided to do just that, for reasons that are totally inexplicable to me. Obviously as a markup language this is fine; as a data format it's bizarre, since the division between attribute vs child doesn't match most in-memory data structures.

pydry 3y ago
Yeah, it's a weird attitude. XML died out because it was an overcomplicated design-by-committee mess. Quite apart from the fact that meant it wouldn't map cleanly to lists and hashmaps, necessitating a query language it also led to embarrassing debacles like the billion laughs vulnerability - problem in the very core of XML. With some niche exceptions where it has clung on, XML basically died. It's time to move on. The fact that we do similar sorts of stuff with JSON like data transformations and schema validation does not, in any way, shape or form, invalidate its flaws.
- baz00 3y ago
  XML is fine. The overcomplicated mess was the WS-* garbage.
smikhanov 3y ago
no user knows The described problem literally doesn't exist in XML. Your XML-validating editor will check your document against the schema and will not allow for an attribute where the sub-element is required and vice versa.
- tyingq 3y ago
  I believe they mean for designing the schema in the first place. Meaning the impedance match between JSON and their chosen language is usually more natural.

crabmusket 3y ago

I see this take often and I think it's pretty bad. JSON (data format) and XML (markup format) are very different. Building tools for JSON doesn't change that in any way. And it turns out that both JSON and XML are used for data interchange, and when people have data interchange problems, they build tooling to help solve those problems (like schema validation). That doesn't make JSON "like XML", it just means they're discovering the same problem and solving it for the format they're using.