6 ms·
It is more that people made comments semantically important, e.g. a tool which did not interpret comments would not correctly interpret the data in the document
by dwaite 2y ago
It is more that people made comments semantically important, e.g. a tool which did not interpret comments would not correctly interpret the data in the document.
This actually would put JSON in a worse place than XML - while XML has an overly complex infoset, that infoset is actually defined and standardized. Representing "a property with a comment on the property name and one before and after the property value" so that information is not lost in parsing would explode the complexity needed for an "interoperable" JSON library.
if someone wants to create some sort of scheme where they do "createdAt$date" as a property name to indicate the value is to be interpreted in some agreed-upon date format, that at least doesn't lose data if the JSON data doesn't understand that scheme, or require a new custom parser in order to properly interpret that data, compared to something like /* $type: date */ "createdAt" :...
- eviks 2y agowhy would you need that complex representation in the interoperable library instead of a much simpler one: a property, a comment, a comment, a value, a comment, ...? This doesn't explode anything and you don't need to lose any data, so the monstrosity of XML still has no benefit, and neither does "createdAt$date", which would need a custom library anyway, so it doesn't matter where you insert your types
- _heimdall 2y agoXML may have no benefit to you but it absolutely has benefit. A bit off topic when the only consideration here is comments, but XML allows for type definitions and structures data that simply isn't possible in JSON. People have found ways to attempt to add types to JSON but they aren't part of the spec at all and are just convention-based solutions.
- deleted 2y ago[deleted]