3 ms·

Remember, we're comparing with XML. There's no dates or numeric types in XML at all. This kind of proliferation is far worse in XML. Sure, there are corner cas

Remember, we're comparing with XML. There's no dates or numeric types in XML at all. This kind of proliferation is far worse in XML. Sure, there are corner cases and limitations with JSON. I've never experienced that as a significant issue. > Conversely, if you are writing in a language that has integral support for XML - say, XQuery, or even VB.NET... I am not using any of that stuff, nor is there any reason for me to start using it. > At the very least, if you control the format - which you have to, if you're in a position to decide what to use - then you can certainly stick to the subset of XML that is not anymore complex than JSON. ...or I can just use JSON.

int_19h 8y ago
> Remember, we're comparing with XML. There's no dates or numeric types in XML at all. This kind of proliferation is far worse in XML. XML (or rather, XDM, which is the appropriate level of abstraction to talk about this) has all those things: https://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes https://www.w3.org/TR/xmlschema-2/#built-in-primitive-dataty... Nor does it doesn't require an out-of-band schema - you can slap xsi:type on any element. And you can do that without breaking the data model, because namespaces keep data and metadata unambiguously separate, and code can easily deal with the former while being completely oblivious to the latter, unless it needs it. JSON also has similar higher-level abstraction layers with more metadata. The problem is that nobody can agree on which one to use, or even whether to use one at all, and most code that's deserializing JSON in the wild is not going to be able to distinguish metadata from data.
- gridlockd 8y ago
  XML has string attributes and text content. Sure, you can add information until you arrive at a point where a string attribute or text content will be interpreted as a certain data type, but XML itself doesn't have it. > JSON also has similar higher-level abstraction layers with more metadata. JSON has all the basic data types built right in, there's no need for more metadata to do simple things. There's a reasonable mapping to basic data types and structures for almost any language. > The problem is that nobody can agree on which one to use, or even whether to use one at all, and most code that's deserializing JSON in the wild is not going to be able to distinguish metadata from data. ...which is generally fine because of the aforementioned mapping. Your JSON library doesn't have to (and shouldn't) do any magic.

int_19h 8y ago

> Remember, we're comparing with XML. There's no dates or numeric types in XML at all. This kind of proliferation is far worse in XML. XML (or rather, XDM, which is the appropriate level of abstraction to talk about this) has all those things: https://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes https://www.w3.org/TR/xmlschema-2/#built-in-primitive-dataty... Nor does it doesn't require an out-of-band schema - you can slap xsi:type on any element. And you can do that without breaking the data model, because namespaces keep data and metadata unambiguously separate, and code can easily deal with the former while being completely oblivious to the latter, unless it needs it. JSON also has similar higher-level abstraction layers with more metadata. The problem is that nobody can agree on which one to use, or even whether to use one at all, and most code that's deserializing JSON in the wild is not going to be able to distinguish metadata from data.

gridlockd 8y ago
XML has string attributes and text content. Sure, you can add information until you arrive at a point where a string attribute or text content will be interpreted as a certain data type, but XML itself doesn't have it. > JSON also has similar higher-level abstraction layers with more metadata. JSON has all the basic data types built right in, there's no need for more metadata to do simple things. There's a reasonable mapping to basic data types and structures for almost any language. > The problem is that nobody can agree on which one to use, or even whether to use one at all, and most code that's deserializing JSON in the wild is not going to be able to distinguish metadata from data. ...which is generally fine because of the aforementioned mapping. Your JSON library doesn't have to (and shouldn't) do any magic.