6 ms·

Everything XML wanted to be, JSON did better. Xml validation and namespaces were kind of half way there solutions that just made things more complex than they

Everything XML wanted to be, JSON did better. Xml validation and namespaces were kind of half way there solutions that just made things more complex than they needed to be.

murukesh_s 5y ago
>half way there solutions Care to explain more? I though they were over engineered compared to bare bones JSON. For e.g. JSON schema is still catching up to XML schema and the ecosystem it had back then (XSLT, XPATH) etc. XML is of course heavy weight, but we should compare YAML against XML, not JSON - JSON doesn't have for e.g. comments, CDATA etc.
- narrator 5y ago
  DTD validation and XML schema were overly complicated solutions that didn't cover a lot of validation cases and should have just been implemented via libraries in the target language instead of making developers maintain yet another half-baked DSL. In the end, everything is JavaScript was the better way.
thaumasiotes 5y ago
- XML starts with a version designator. - JSON allows arbitrary integers to be represented as numeric values. That works fine on its own, but it causes serious problems if you trust the name of the format, "JavaScript Object Notation". You can't do that in JavaScript objects. - JSON has no comments. Or version designators. The big problems in XML are named closing tags and the weird distinction between children and attributes. JSON did those things better, by not having them at all. But XML is a long, long way from "like JSON, but worse in every way". (Another big problem in XML-considered-as-an-ecosystem is the prevalence of people who want to deal with it by using regular expressions. As far as the technology goes, this is a non-issue -- it's a problem with the user, not the technology. But I do have to admit that the JSON equivalent appears to be loading the data into a parser that doesn't work, as opposed to loading the data into a non-parser that doesn't work.)
- lmm 5y ago
  > - XML starts with a version designator. Which has proven to have zero real-world use case. > - JSON allows arbitrary integers to be represented as numeric values. That works fine on its own, but it causes serious problems if you trust the name of the format, "JavaScript Object Notation". You can't do that in JavaScript objects. That's not a problem with JSON, that's a problem with standardized JavaScript. I believe JSON was named before there was an official standard that required JavaScript implementations to be terrible. > - JSON has no comments. Or version designators. Indeed, and it's all the better for it.
  - thaumasiotes 5y ago
    > I believe JSON was named before there was an official standard that required JavaScript implementations to be terrible. Nope. The ECMAScript standard released in 1999 already specifies: > In ECMAScript, the set of values represents the double-precision 64-bit format IEEE 754 values including the special “Not-a-Number” (NaN) values, positive infinity, and negative infinity. https://www.ecma-international.org/wp-content/uploads/ECMA-262_3rd_edition_december_1999.pdf https://www.ecma-international.org/wp-content/uploads/ECMA-2...
  - KronisLV 5y ago
    > > - JSON has no comments. Or version designators. > Indeed, and it's all the better for it. JSON5 attempts to fix the comments problem: https://json5.org/ https://json5.org/ A lack of comments is never good, especially when you want to provide a workable example of what an entity looks like, while annotating its contents, but at the same time allowing it to be parseable. Furthermore, i wouldn't scoff if i ever saw comments about non-trivial fields in web APIs actually being returned, to better explain how to use them. Of course, at the same time i believe that something like that would be better suited as a part of WSDL, WADL or XSD schemas, but JSON and the technologies around it have essentially done away with strict schemas, which makes using them about as reassuring as dynamic languages - i.e. unreliable. Far too few people do properly versioned APIs and far too few people do OpenAPI specs that are generated from code automatically and are publicly available for the above to be a moot point. Whereas with XML based services, i could open the WSDL/XSD file for a 15 year old API and know what's going on within 10 minutes. It seems like the industry has lost that bit of wisdom somewhere along the way of chasing agility - the same way that knowing how to generate code and operate with metamodels and models has also been tossed aside.
nfoz 5y ago
How do you like to express nested marked-up text in JSON?
- bonzini 5y ago
 {'style': 'bold', 'children': [ 'marked-up ', {'style': 'italic', 'children': [ 'text' ]}, ' in JSON']} In fact, Pandoc's internal format is exportable in JSON
 - cxr 5y ago
 Take the (rhetorical) question in context. The claim was that "Everything XML wanted to be, JSON did better." Of course it can be _done_. The point to defend is that doing it like this in JSON is _better_. It's self-evident that XML is better for the mixed content problem (which makes sense, given that mixed content is something that it was consciously designed for). Anyone arguing otherwise is, ironically, approaching the issue by narrowly considering only the things that JSON is good for and then evaluating XML against that—e.g. without it ever occurring to them that they should consider mixed content, as in the example given—or they're deluding themselves/being dishonest.
 - bonzini 5y ago
 Of course we agree that the JSON representation is verbose. The question is: what is harder to use in a program? A verbose JSON representation that is just dictionaries and lists, or a concise XML one that is represented and manipulated using the DOM API?
 - deleted 5y ago
 [deleted]
 - cxr 5y ago
 > The question is: what is harder to use in a program? In your imagination, maybe, but otherwise, no, it's not. The claim being prosecuted is that "Everything XML wanted to be, JSON did better." (It would be bad enough to lose sight of this once, but I explicitly repeated it for your benefit in the comment that you you are directly replying to. This iteration makes #3.)

Everything XML wanted to be, JSON did better. Xml validation and namespaces were kind of half way there solutions that just made things more complex than they needed to be.

murukesh_s 5y ago

>half way there solutions Care to explain more? I though they were over engineered compared to bare bones JSON. For e.g. JSON schema is still catching up to XML schema and the ecosystem it had back then (XSLT, XPATH) etc. XML is of course heavy weight, but we should compare YAML against XML, not JSON - JSON doesn't have for e.g. comments, CDATA etc.

narrator 5y ago
DTD validation and XML schema were overly complicated solutions that didn't cover a lot of validation cases and should have just been implemented via libraries in the target language instead of making developers maintain yet another half-baked DSL. In the end, everything is JavaScript was the better way.

thaumasiotes 5y ago

- XML starts with a version designator. - JSON allows arbitrary integers to be represented as numeric values. That works fine on its own, but it causes serious problems if you trust the name of the format, "JavaScript Object Notation". You can't do that in JavaScript objects. - JSON has no comments. Or version designators. The big problems in XML are named closing tags and the weird distinction between children and attributes. JSON did those things better, by not having them at all. But XML is a long, long way from "like JSON, but worse in every way". (Another big problem in XML-considered-as-an-ecosystem is the prevalence of people who want to deal with it by using regular expressions. As far as the technology goes, this is a non-issue -- it's a problem with the user, not the technology. But I do have to admit that the JSON equivalent appears to be loading the data into a parser that doesn't work, as opposed to loading the data into a non-parser that doesn't work.)

lmm 5y ago
> - XML starts with a version designator. Which has proven to have zero real-world use case. > - JSON allows arbitrary integers to be represented as numeric values. That works fine on its own, but it causes serious problems if you trust the name of the format, "JavaScript Object Notation". You can't do that in JavaScript objects. That's not a problem with JSON, that's a problem with standardized JavaScript. I believe JSON was named before there was an official standard that required JavaScript implementations to be terrible. > - JSON has no comments. Or version designators. Indeed, and it's all the better for it.
- thaumasiotes 5y ago
  > I believe JSON was named before there was an official standard that required JavaScript implementations to be terrible. Nope. The ECMAScript standard released in 1999 already specifies: > In ECMAScript, the set of values represents the double-precision 64-bit format IEEE 754 values including the special “Not-a-Number” (NaN) values, positive infinity, and negative infinity. https://www.ecma-international.org/wp-content/uploads/ECMA-262_3rd_edition_december_1999.pdf https://www.ecma-international.org/wp-content/uploads/ECMA-2...
- KronisLV 5y ago
  > > - JSON has no comments. Or version designators. > Indeed, and it's all the better for it. JSON5 attempts to fix the comments problem: https://json5.org/ https://json5.org/ A lack of comments is never good, especially when you want to provide a workable example of what an entity looks like, while annotating its contents, but at the same time allowing it to be parseable. Furthermore, i wouldn't scoff if i ever saw comments about non-trivial fields in web APIs actually being returned, to better explain how to use them. Of course, at the same time i believe that something like that would be better suited as a part of WSDL, WADL or XSD schemas, but JSON and the technologies around it have essentially done away with strict schemas, which makes using them about as reassuring as dynamic languages - i.e. unreliable. Far too few people do properly versioned APIs and far too few people do OpenAPI specs that are generated from code automatically and are publicly available for the above to be a moot point. Whereas with XML based services, i could open the WSDL/XSD file for a 15 year old API and know what's going on within 10 minutes. It seems like the industry has lost that bit of wisdom somewhere along the way of chasing agility - the same way that knowing how to generate code and operate with metamodels and models has also been tossed aside.

nfoz 5y ago

How do you like to express nested marked-up text in JSON?

bonzini 5y ago
{'style': 'bold', 'children': [ 'marked-up ', {'style': 'italic', 'children': [ 'text' ]}, ' in JSON']} In fact, Pandoc's internal format is exportable in JSON
- cxr 5y ago
  Take the (rhetorical) question in context. The claim was that "Everything XML wanted to be, JSON did better." Of course it can be _done_. The point to defend is that doing it like this in JSON is _better_. It's self-evident that XML is better for the mixed content problem (which makes sense, given that mixed content is something that it was consciously designed for). Anyone arguing otherwise is, ironically, approaching the issue by narrowly considering only the things that JSON is good for and then evaluating XML against that—e.g. without it ever occurring to them that they should consider mixed content, as in the example given—or they're deluding themselves/being dishonest.
  - bonzini 5y ago
    Of course we agree that the JSON representation is verbose. The question is: what is harder to use in a program? A verbose JSON representation that is just dictionaries and lists, or a concise XML one that is represented and manipulated using the DOM API?
    - deleted 5y ago
      [deleted]
    - cxr 5y ago
      > The question is: what is harder to use in a program? In your imagination, maybe, but otherwise, no, it's not. The claim being prosecuted is that "Everything XML wanted to be, JSON did better." (It would be bad enough to lose sight of this once, but I explicitly repeated it for your benefit in the comment that you you are directly replying to. This iteration makes #3.)