Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Additionally, XML, with its nesting and attributes, doesn't map particularly well to a specific programming construct. Also, you can represent an object in a lot of ways.

JSON, on the other hand, is dead simple: You have your list/array, dict/object and four value types. Representing JSON in your favorite language is straight-foward and how the serialized version of a hierarchy looks is immediately obvious in nearly all cases.



Depends on the language. XML maps nicely to C/C++/Java/Rust/... structures, that you can generate from a schema at compile time. Dealing with arbitrarily typed arrays and objects is painful in some languages because you need to use variants and dynamic-cast every access to the document.


How is it "nice" when any struct member could map to either an attribute or a child element?

XML is a markup language. It's in the name even. Trying to use it for serialization is weird.


You declare which one it should be in the schema (used to generate the struct and its (de)serialization code)

> XML is a markup language. It's in the name even.

It can be used for markup, but isn't limited to that.


That's exactly the problem I was going for - feature richness is the enemy of simplicity. The fact that you need to read a schema (and learn one of the schema languages) makes starting out with XML just much harder than JSON.


You implicitly need a schema in JSON too: it's the API documentation.

Then, every implementer in a statically typed language needs to translate the JSON format into structures in their own language. And this is impossible to automate, unless the JSON API uses a formally defined schema (eg. OpenAPI or GraphQL schemas), but then we're back to square 1.

If you don't care about that (eg. in dynamically typed languages), you can parse XML just like you parse JSON, using something like https://github.com/martinblech/xmltodict




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: