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

For those working in dynamic languages (JavaScript, Python, Perl, Ruby, etc.) JSON maps directly onto built-in language data types and structures making it trivial to work with.

With XML you usually end up needing custom code to convert to and from the parsed XML representation and the language's built-in data types and structures.

This is less of a concern for statically typed languages where you usually have to marshal data to and from your own structs/classes whether it's XML or JSON.



XMLRPC[0] defined a trivial mapping of the same data structures (structs, arrays, scalars) in the '90s.

The real advantage of JSON was (IMHO) that it didn't let you do _anything else_.

[0] http://xmlrpc.com/spec.md


It's trivial until you run into a date-field. I've connected some JSON based exchanges to each other and just created an XML intermediary format to have a single canonical model and do the various translations to/from the other systems from there.


Why are dates better in XML? You can still have:

ISO 8601, as used by XML Schema:

<foo>2020-09-04T00:00:00Z</foo>

or

Unix date output format (not sure this has an actual name)

<foo>Fri 04 Sep 2020 00:00:00 GMT</foo>

or

some sort of destructured date

<foo> <year>2020</year> <month>09</month> <day>04</day> <!-- ... --> </foo>

or

some sort of destructured date with 0 based months because Java

<foo> <year>2020</year> <month>08</month> <day>04</day> <!-- ... --> </foo>

Your app still needs to know what is coming in, and convert that to its internal format.

Even if you want to get everyone to agree on XML Schema's datetime format, it's not always sufficient because sometimes you need the actual time zone (e.g. America/New_York ) rather than the UTC offset especially when dealing with recurring/far off events.




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

Search: