Hacker News Reader

Comment by andyjohnson0 | Hacker News Reader

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?

View on HN

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) 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".

Transcript of that talk: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

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.

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.

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.

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.

> 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.

Its a rule of thumb (heuristic). Judgement is still required.

(A soundbite is something altogether different.)

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)

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.

http://programmers.stackexchange.com/questions/61198/if-xml-...

http://blog.codinghorror.com/xml-the-angle-bracket-tax/

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)

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.

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…

Sure, XML may be decent as an extensible markup language, but what if you need a strongly-typed data exchange format?

Turtle!

Well, I can dream..

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.

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.

> 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…)

But no matter what format any bit of data is in, it should still be documented. Then any consumers of the data are going to have to convert it into a format that suits their language and application.

> But no matter what format any bit of data is in, it should still be documented.

That's what types are: enforced documentation.

That's what types are: enforced documentation.

That's an interesting way to think about it, but I'm not sure it applies here. From the example given about money being a string or a float. A type would just enforce either or, but the consumer of the data would still need to know what it is, and convert it to whatever is necessary for them.

> what if you need a strongly-typed data exchange format

I'm not convinced that "strongly-typed" is an attribute that can meaningfully be possessed by a data exchange format. "Strongly-typed" is about allowed actions in processing data, not about the inherently-static format of data exchange or serialization.

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

Reply on news.ycombinator.com