Nice article. Just as an addendum, JSON does have shortcomings in comparison to XML:
1) JSON has no standardized way of expressing type information for each node (XML has named tags for that). Some conventions do exist (e.g. a specifically named "type" property in a node that tells the reader what this object actually is) but that's a convention, not a standard.
2) JSON has no notion of identifiers, at all. XML on the other hand has standard ID- and IDRef-Types. A good validator can even tell you that an IDRef points to no other known element within the document at parse time.
3) This is a little bit related to 2). While XML can represent arbitrary object graphs, JSON natively only supports trees. Without relying on conventions again, it is not possible to convert a general object graph to JSON because it cannot deal with backreferences.
4) Vanilla JSON (i.e. not JSON5) has no comments. No big deal for data exchange, but being unable to put a comment to a dependency in a package.json is more than annoying.
Especially the first three points can be absolute dealbreakers. If you take the XStream library in Java, you pass it an arbitrary (!) object and get an XML. You pass it the XML, and get back the object. You don't specify which class you want to serialize or deserialize, because the XML data is complete. I have yet to encounter a JSON (de-)serializer which can do that. There are reasons why XML was so popular. JSON is much more lightweight, but it can get messy / ambiguous easily. It takes a lot more thougt and effort to produce a good, usable and unambiguous JSON format compared to XML. Enjoy responsibly.
1) JSON has no standardized way of expressing type information for each node
(XML has named tags for that). Some conventions do exist (e.g. a specifically
named "type" property in a node that tells the reader what this object
actually is) but that's a convention, not a standard.
json-ld.org/spec/latest/json-ld/ is a standard, though not 100% sure what you mean with the point so not 100% sure this fits your request, and it might easily exceed a lot of what you want from it too
4) Vanilla JSON (i.e. not JSON5) has no comments. No big deal for data
exchange, but being unable to put a comment to a dependency in a package.json
is more than annoying.
This just means that the person who decided to use .json format for their configuration was not particularly clever even though they probably thought they were. JSON is primarily a data transfer format, and should not be used for everything, incl. arbitrary configuration (AWS should die in a fire with their massive JSON configuration mess). XML would be (and is) also a mess for storing configuration for things.
For example YAML is MUCH better for that kind of use.
By "standard" I simply mean what the language supports on its own - not how you use it. In that regard, JSON has objects, arrays and properties. Nothing more, nothing less. XML has the concept of an identifier built natively into the language. Also, it is not uncommon to see an element reference another one by means of an XPath expression within the XML document itself. Yes, JSON can emulate all of that, no doubt about it, but I rarely ever encounter such cases in practice. I assume that people simply try to avoid these scenarios when working with JSON, or switch to a different format when they are inevitable. Even as a data interchange format, JSON does have its limitations. As a Java programmer, I would much rather work with XML, but in the web world, I guess that JavaScript devs prefer JSON.
I agree that using .json for the package configuration was not a very smart decision ;-) That's exactly what I meant with "enjoy responsibly".
One advantage that JSON definitly has over XML is that it is much easier to write manually than XML, and also more lightweight to read. I never worked with YAML so far, but it seems like a middle ground between XML and JSON.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article. Just as an addendum, JSON does have shortcomings in comparison to XML:
1) JSON has no standardized way of expressing type information for each node (XML has named tags for that). Some conventions do exist (e.g. a specifically named "type" property in a node that tells the reader what this object actually is) but that's a convention, not a standard.
2) JSON has no notion of identifiers, at all. XML on the other hand has standard ID- and IDRef-Types. A good validator can even tell you that an IDRef points to no other known element within the document at parse time.
3) This is a little bit related to 2). While XML can represent arbitrary object graphs, JSON natively only supports trees. Without relying on conventions again, it is not possible to convert a general object graph to JSON because it cannot deal with backreferences.
4) Vanilla JSON (i.e. not JSON5) has no comments. No big deal for data exchange, but being unable to put a comment to a dependency in a package.json is more than annoying.
Especially the first three points can be absolute dealbreakers. If you take the XStream library in Java, you pass it an arbitrary (!) object and get an XML. You pass it the XML, and get back the object. You don't specify which class you want to serialize or deserialize, because the XML data is complete. I have yet to encounter a JSON (de-)serializer which can do that. There are reasons why XML was so popular. JSON is much more lightweight, but it can get messy / ambiguous easily. It takes a lot more thougt and effort to produce a good, usable and unambiguous JSON format compared to XML. Enjoy responsibly.
Quick couple of comments:
json-ld.org/spec/latest/json-ld/ is a standard, though not 100% sure what you mean with the point so not 100% sure this fits your request, and it might easily exceed a lot of what you want from it too
This just means that the person who decided to use
.jsonformat for their configuration was not particularly clever even though they probably thought they were. JSON is primarily a data transfer format, and should not be used for everything, incl. arbitrary configuration (AWS should die in a fire with their massive JSON configuration mess). XML would be (and is) also a mess for storing configuration for things.For example YAML is MUCH better for that kind of use.
By "standard" I simply mean what the language supports on its own - not how you use it. In that regard, JSON has objects, arrays and properties. Nothing more, nothing less. XML has the concept of an identifier built natively into the language. Also, it is not uncommon to see an element reference another one by means of an XPath expression within the XML document itself. Yes, JSON can emulate all of that, no doubt about it, but I rarely ever encounter such cases in practice. I assume that people simply try to avoid these scenarios when working with JSON, or switch to a different format when they are inevitable. Even as a data interchange format, JSON does have its limitations. As a Java programmer, I would much rather work with XML, but in the web world, I guess that JavaScript devs prefer JSON.
I agree that using
.jsonfor the package configuration was not a very smart decision ;-) That's exactly what I meant with "enjoy responsibly".One advantage that JSON definitly has over XML is that it is much easier to write manually than XML, and also more lightweight to read. I never worked with YAML so far, but it seems like a middle ground between XML and JSON.