4 ms·

JSON syntax is more familiar for people who have not been exposed to XML for long. Parsing and walking a JSON structure is much easier and less ambiguous. It's

by dgb23 5y ago

JSON syntax is more familiar for people who have not been exposed to XML for long. Parsing and walking a JSON structure is much easier and less ambiguous. It's often very clear how to represent/deserialize/serialize JSON (as-is). The benefits of using schema are clear, you can add validation and semantics to parse (JSON) into a richer and more consistent data structure. JSON-schema is in large parts a well designed and clear language that is meant to be read and written by humans. Compare that to DTD, XML schema. I think in terms of raw functionality, there are very strong parallels. And even though I'm not an XML hater, I find JSON simply more pleasant to work with. The only fundamental advantage that I would give XML over JSON is the fact that you can encode meta data in XML in a more idiomatic, standard way via attributes. But we all know that is not how XML is being used. If the ecosystem around XML wasn't abusing attributes to encode core/primary data, then there would be a stronger argument for the language IMO.

da_chicken 5y ago
> The only fundamental advantage that I would give XML over JSON is the fact that you can encode meta data in XML in a more idiomatic, standard way via attributes. But we all know that is not how XML is being used. If the ecosystem around XML wasn't abusing attributes to encode core/primary data, then there would be a stronger argument for the language IMO. Attributes are absolutely one of the reasons for XML's failure. They seem so innocuous, until you encounter a schema where the developer created: <Entity ID="12345" Type="Person"> <Property Name="FirstName" Value="Harry" Type="String" /> <Property Name="LastName" Value="Potter" Type="String" /> <Property Name="DateOfBirth" Value="1/1/1980" Type="DateTime" /> </Entity> And you just want to hunt those people down and slap them. Nevermind if you've ever encountered XML with mixed namespaces. Then again, reading the article the bit at the end is exactly the same sort of nastiness.
- dgb23 5y ago
  That's a very illustrative example. It completely and utterly destroys the benefit of having attributes and makes the structure less clear in context of the XML ecosystem. I imagine if there was discipline around attributes being only used for meta-data and maybe explicit (de-normalized) references (which is arguably meta data, happy to discuss), then XML would be semantically richer by default. However like this we are left guessing the semantics if we encounter some XML. Somewhat in contrast, HTML is generally, but not consistently, better at making this distinction, which enables clearer semantics around accessibility, HATEOAS and so on. Ironically we are kicking that value proposition into the can when driving web application rendering with JSON (like popular SPA frameworks do), so we have to re-invent meta data and communicate that with JSON-schema.
oaiey 5y ago
XSD is not as bad as everyone claims. JSON Schema vs. XSD complexity is IMHO pretty much the same. Working with both over years. DTD however, let us not talk about that. Let us just forget it. I think the drama in XML usage was basically that a simple RPC (or resource query) had at least a dozen namespaces, standards and very long element names. But that is not the fault of XML but of SOAP/WS-*. XML itself can be very beautiful and simple. Oh, and horrible DOM Apis ;). When working in semi-modern .NET parsing XML/JSON is super easy. Doing the same in JavaScript (out-of-the-box) is a drama.
- easrng 5y ago
  It's easy in JS too, just use a DOMParser
  - no_wizard 5y ago
    That is not a JavaScript API, that’s a DOM only API, meaning it’s not reproduced in the language spec. This is important because it won’t work in Node, for example, without a 3rd party library or someone implementing it in Node core. JSON however is supported in the language spec
    - oaiey 5y ago
      And DOM API is an example of bad API design. Compare that to a modern XML API (like .NET System.Xml.XDocument) and you never want to see Dom again
- meltedcapacitor 5y ago
  Namespaces killed xml. Such a bad design. It may have worked out better with every schema required to explicitly flatten in whatever they need from sub-grammars. I see this json schema thing also seems to use long intricate URLs that you can only copy-paste to identify things... at least in this day and age if one does ID with unwieldy blobs, it'd be good to at least use some hash to get the benefits of content addressing.
- staticassertion 5y ago

by dgb23 5y ago

da_chicken 5y ago

> The only fundamental advantage that I would give XML over JSON is the fact that you can encode meta data in XML in a more idiomatic, standard way via attributes. But we all know that is not how XML is being used. If the ecosystem around XML wasn't abusing attributes to encode core/primary data, then there would be a stronger argument for the language IMO. Attributes are absolutely one of the reasons for XML's failure. They seem so innocuous, until you encounter a schema where the developer created: <Entity ID="12345" Type="Person"> <Property Name="FirstName" Value="Harry" Type="String" /> <Property Name="LastName" Value="Potter" Type="String" /> <Property Name="DateOfBirth" Value="1/1/1980" Type="DateTime" /> </Entity> And you just want to hunt those people down and slap them. Nevermind if you've ever encountered XML with mixed namespaces. Then again, reading the article the bit at the end is exactly the same sort of nastiness.

dgb23 5y ago
That's a very illustrative example. It completely and utterly destroys the benefit of having attributes and makes the structure less clear in context of the XML ecosystem. I imagine if there was discipline around attributes being only used for meta-data and maybe explicit (de-normalized) references (which is arguably meta data, happy to discuss), then XML would be semantically richer by default. However like this we are left guessing the semantics if we encounter some XML. Somewhat in contrast, HTML is generally, but not consistently, better at making this distinction, which enables clearer semantics around accessibility, HATEOAS and so on. Ironically we are kicking that value proposition into the can when driving web application rendering with JSON (like popular SPA frameworks do), so we have to re-invent meta data and communicate that with JSON-schema.

oaiey 5y ago

XSD is not as bad as everyone claims. JSON Schema vs. XSD complexity is IMHO pretty much the same. Working with both over years. DTD however, let us not talk about that. Let us just forget it. I think the drama in XML usage was basically that a simple RPC (or resource query) had at least a dozen namespaces, standards and very long element names. But that is not the fault of XML but of SOAP/WS-*. XML itself can be very beautiful and simple. Oh, and horrible DOM Apis ;). When working in semi-modern .NET parsing XML/JSON is super easy. Doing the same in JavaScript (out-of-the-box) is a drama.

easrng 5y ago
It's easy in JS too, just use a DOMParser
- no_wizard 5y ago
  That is not a JavaScript API, that’s a DOM only API, meaning it’s not reproduced in the language spec. This is important because it won’t work in Node, for example, without a 3rd party library or someone implementing it in Node core. JSON however is supported in the language spec
  - oaiey 5y ago
    And DOM API is an example of bad API design. Compare that to a modern XML API (like .NET System.Xml.XDocument) and you never want to see Dom again
meltedcapacitor 5y ago
Namespaces killed xml. Such a bad design. It may have worked out better with every schema required to explicitly flatten in whatever they need from sub-grammars. I see this json schema thing also seems to use long intricate URLs that you can only copy-paste to identify things... at least in this day and age if one does ID with unwieldy blobs, it'd be good to at least use some hash to get the benefits of content addressing.
staticassertion 5y ago