5 ms·

My thoughts exactly. JSON is great for Javascript clients, but if you're dealing with clients written in multiple languages then there is already a good languag

My thoughts exactly. JSON is great for Javascript clients, but if you're dealing with clients written in multiple languages then there is already a good language-neutral serialisation format: XML. Just because it's not fashionable (with some) doesn't mean it doesn't work. Edit: So why the downvotes? How about a conversation instead?

rjbwork 11y ago
I used to agree, but I've lately come over to the JSON side, I think. It's easier to read by a human, and it doesn't have this weird "should it be a node or an attribute" thing. Single things are properties, many things are arrays. And now with Schemas and editor support for them, I think it is an acceptable replacement personally.
- andyjohnson0 11y ago
  Nodes for data, attributes for metadata. I think you made a good argument, although I personally prefer the more mature XML tooling and metadata support for versioning.
  - HolyHaddock 11y ago
    That's fine in theory, but it's not a universal heuristic, and even then, different smart well-intentioned people independently applying it won't necessarily come to the same result.
  - krick 11y ago
    It's hardly answers the question, as strictly speaking there's no such thing as "metadata". Everything you can pass to another person can be described as "data", whether it is a color of your coat or the statement that you are describing the color of your coat. Basically, you can think of any attribute of an object as "metadata" as long as it can be only one per object and doesn't have any attributes itself, and both things can change easily and depend on the point of view. On the contrary, I don't remember one single case when the object was described easily using "node/attribute" separation, but couldn't be described as easily using JSON. In fact, I don't even think it's possible, as you can always make two children for each object: "attributes" and "nodes". So I guess it actually is unnecessary complication and not the benefit of using XML over JSON.
  - dragonwriter 11y ago
    > Nodes for data, attributes for metadata. Its a nice soundbite, but it ends up being less than useful in practice, because all metadata is data, and almost any data can be viewed as metadata, a distinction which is both subjective and strongly influenced by the use to which a consumer is putting the data rather than being determined on the basis solely of the inherent nature of the data.
    - andyjohnson0 11y ago
      Its a rule of thumb (heuristic). Judgement is still required. (A soundbite is something altogether different.)
- xg15 11y ago
  Also whitespace handling. XML is still based on SGML and its idea that a document is basically a single string of text with certain substrings "marked up" with metadata. This assumption is of course completely false for the overwhelming majority of XML use cases. Yet, it still influences many design decisions and processing steps in the XML toolchain, the most prominent being that simply formatting an XML document may change its contents. JSON is a lot more "honest" in this respect, in that it's core data model is already useful for many applications, even without additional standards bolted on top of it. (Though those exist, this article being one of them)
- usrusr 11y ago
  Explicit arrays are what I consider the most important advantage of JSON over XML. In XML, every element is repeatable by default and only out-of-band specification can restrict cardinality. Two bytes extra per array, that convey so much structural self-documentation that is just not there in an XML document. So JSON succeeded because XML is not verbose enough? Really did not see that one coming.
creshal 11y ago
JSON is pretty great to parse in a variety of (web-relevant) languages. And it's a good data exchange format if you're okay with its loose typing. But if I need a strongly-typed, extensible markup language, I'd think really hard about inventing my own…
- wtbob 11y ago
  Sure, XML may be decent as an extensible markup language, but what if you need a strongly-typed data exchange format?
  - icebraining 11y ago
    Turtle! Well, I can dream..
  - dec0dedab0de 11y ago
    I'm going to risk sounding thick here, but why would you need a strongly-typed data exchange format? I always thought the beauty of JSON was that it forced the sender to organize the data in a generic way, which allowed the receiver to interpret it however needed.
    - prodigal_erik 11y ago
      Without a strongly-typed data exchange format, you constantly have to write code that makes assumptions you hope the sender followed. Timestamps are ISO formatted. No, timestamps are seconds since 1970. No, they're floats including milliseconds. Blobs are base64. No, hex. Money is a string. No, it's a float. No, it's an int in micros. An empty array is different than an omitted field. No, they're the same. No, multiple values are comma-delimited strings.
      - creshal 11y ago
        > Money is a string. No, it's a float. No, it's an int in micros No, it's a decimal number with attribute-dependant accuracy settings, with at least three different accuracy levels used in the same object used for different purposes. (Just something I came across today at work. Thankfully, my SOAP library handles that automatically…)
pjc50 11y ago
http://programmers.stackexchange.com/questions/61198/if-xml-is-so-bad-why-do-so-many-people-use-it http://programmers.stackexchange.com/questions/61198/if-xml-... http://blog.codinghorror.com/xml-the-angle-bracket-tax/ http://blog.codinghorror.com/xml-the-angle-bracket-tax/ http://nothing-more.blogspot.co.uk/2004/10/where-xml-goes-astray.html http://nothing-more.blogspot.co.uk/2004/10/where-xml-goes-as... SOAP's serialisation of RPC predated the popularity of JSON, and has largely been replaced by JSON for web-RPC through REST APIs. Why? Because it's needlessly verbose and complicated. (I do worry that new serialisation formats are being developed in a vacuum, and we'll reinvent ASN1 or something)
oskarth 11y ago
The downvotes are because it comes across as a shallow, middlebrow dismissal. An interesting and useful criticism would first engage with the strongest arguments of Rich Hickey (creator of Transit and edn). If you find something in his Language of the System talk (https://www.youtube.com/watch?v=ROor6_NGIWU https://www.youtube.com/watch?v=ROor6_NGIWU) that you either (a) disagree with (b) think XML solves already, I and many others would certainly be interested in having that conversation. Note that this doesn't mean the exposition of "Why Transit" can't be better, but that calls for constructive criticism on how explain the ideas better, or a question made in qood faith. What it doesn't call for is a hostile reply saying in effect "pff, already been done already, stop reinventing the wheel".
- calibraxis 11y ago
  Transcript of that talk: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/LanguageSystem.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
hyperpallium 11y ago
XML is eXtensible (via DTD or XS), but JSON is a better Object Notation than any Markup Language.
vvanders 11y ago
Every XML parser I've seen is garbage on the performance side of things. Personally I'm a fan of YAML for both being fast and human readable.

rjbwork 11y ago

I used to agree, but I've lately come over to the JSON side, I think. It's easier to read by a human, and it doesn't have this weird "should it be a node or an attribute" thing. Single things are properties, many things are arrays. And now with Schemas and editor support for them, I think it is an acceptable replacement personally.

andyjohnson0 11y ago
Nodes for data, attributes for metadata. I think you made a good argument, although I personally prefer the more mature XML tooling and metadata support for versioning.
- HolyHaddock 11y ago
  That's fine in theory, but it's not a universal heuristic, and even then, different smart well-intentioned people independently applying it won't necessarily come to the same result.
- krick 11y ago
  It's hardly answers the question, as strictly speaking there's no such thing as "metadata". Everything you can pass to another person can be described as "data", whether it is a color of your coat or the statement that you are describing the color of your coat. Basically, you can think of any attribute of an object as "metadata" as long as it can be only one per object and doesn't have any attributes itself, and both things can change easily and depend on the point of view. On the contrary, I don't remember one single case when the object was described easily using "node/attribute" separation, but couldn't be described as easily using JSON. In fact, I don't even think it's possible, as you can always make two children for each object: "attributes" and "nodes". So I guess it actually is unnecessary complication and not the benefit of using XML over JSON.
- dragonwriter 11y ago
  > Nodes for data, attributes for metadata. Its a nice soundbite, but it ends up being less than useful in practice, because all metadata is data, and almost any data can be viewed as metadata, a distinction which is both subjective and strongly influenced by the use to which a consumer is putting the data rather than being determined on the basis solely of the inherent nature of the data.
  - andyjohnson0 11y ago
    Its a rule of thumb (heuristic). Judgement is still required. (A soundbite is something altogether different.)
xg15 11y ago
Also whitespace handling. XML is still based on SGML and its idea that a document is basically a single string of text with certain substrings "marked up" with metadata. This assumption is of course completely false for the overwhelming majority of XML use cases. Yet, it still influences many design decisions and processing steps in the XML toolchain, the most prominent being that simply formatting an XML document may change its contents. JSON is a lot more "honest" in this respect, in that it's core data model is already useful for many applications, even without additional standards bolted on top of it. (Though those exist, this article being one of them)
usrusr 11y ago
Explicit arrays are what I consider the most important advantage of JSON over XML. In XML, every element is repeatable by default and only out-of-band specification can restrict cardinality. Two bytes extra per array, that convey so much structural self-documentation that is just not there in an XML document. So JSON succeeded because XML is not verbose enough? Really did not see that one coming.

creshal 11y ago

JSON is pretty great to parse in a variety of (web-relevant) languages. And it's a good data exchange format if you're okay with its loose typing. But if I need a strongly-typed, extensible markup language, I'd think really hard about inventing my own…

wtbob 11y ago
Sure, XML may be decent as an extensible markup language, but what if you need a strongly-typed data exchange format?
- icebraining 11y ago
  Turtle! Well, I can dream..
- dec0dedab0de 11y ago
  I'm going to risk sounding thick here, but why would you need a strongly-typed data exchange format? I always thought the beauty of JSON was that it forced the sender to organize the data in a generic way, which allowed the receiver to interpret it however needed.
  - prodigal_erik 11y ago
    Without a strongly-typed data exchange format, you constantly have to write code that makes assumptions you hope the sender followed. Timestamps are ISO formatted. No, timestamps are seconds since 1970. No, they're floats including milliseconds. Blobs are base64. No, hex. Money is a string. No, it's a float. No, it's an int in micros. An empty array is different than an omitted field. No, they're the same. No, multiple values are comma-delimited strings.
    - creshal 11y ago
      > Money is a string. No, it's a float. No, it's an int in micros No, it's a decimal number with attribute-dependant accuracy settings, with at least three different accuracy levels used in the same object used for different purposes. (Just something I came across today at work. Thankfully, my SOAP library handles that automatically…)

pjc50 11y ago

http://programmers.stackexchange.com/questions/61198/if-xml-is-so-bad-why-do-so-many-people-use-it http://programmers.stackexchange.com/questions/61198/if-xml-... http://blog.codinghorror.com/xml-the-angle-bracket-tax/ http://blog.codinghorror.com/xml-the-angle-bracket-tax/ http://nothing-more.blogspot.co.uk/2004/10/where-xml-goes-astray.html http://nothing-more.blogspot.co.uk/2004/10/where-xml-goes-as... SOAP's serialisation of RPC predated the popularity of JSON, and has largely been replaced by JSON for web-RPC through REST APIs. Why? Because it's needlessly verbose and complicated. (I do worry that new serialisation formats are being developed in a vacuum, and we'll reinvent ASN1 or something)

oskarth 11y ago

The downvotes are because it comes across as a shallow, middlebrow dismissal. An interesting and useful criticism would first engage with the strongest arguments of Rich Hickey (creator of Transit and edn). If you find something in his Language of the System talk (https://www.youtube.com/watch?v=ROor6_NGIWU https://www.youtube.com/watch?v=ROor6_NGIWU) that you either (a) disagree with (b) think XML solves already, I and many others would certainly be interested in having that conversation. Note that this doesn't mean the exposition of "Why Transit" can't be better, but that calls for constructive criticism on how explain the ideas better, or a question made in qood faith. What it doesn't call for is a hostile reply saying in effect "pff, already been done already, stop reinventing the wheel".

calibraxis 11y ago
Transcript of that talk: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/LanguageSystem.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

hyperpallium 11y ago

XML is eXtensible (via DTD or XS), but JSON is a better Object Notation than any Markup Language.

vvanders 11y ago

Every XML parser I've seen is garbage on the performance side of things. Personally I'm a fan of YAML for both being fast and human readable.