
After XML, JSON. Then What? - draegtun
http://www.drdobbs.com/web-development/after-xml-json-then-what/240151851
======
PuercoPop
S-expressions of course. See: <http://www.schnada.de/grapt/eriknaggum-
xmlrant.html>

~~~
draegtun
Yep. Or alternatively go for Rebol which JSON was originally influenced by -
<http://www.rebol.com/cgi-bin/blog.r?view=0423>

------
kls
I do like the syntax of TOML quite a bit, but it has the same issue that XML
once had in that it is not natively supported in the browser. Things have
changed a lot and non-native document parsing is a lost faster but one of
JSON's primary advantages was an still is, is that it is a native browser
format.

~~~
Millennium
Native parsing is a red herring; even in the bad old days, it was quick enough
to be unnoticeable unless you were working on Big Data in the browser. Moving
to native-code parsing for the sake of performance is a major case of
premature optimization.

JSON's big advantage was that you didn't have to do any work. One function
call, with a single argument, would take you from a blob of text to a fully
populated data structure, and that function was already built into every
browser. The name of the function has changed (eval() to JSON.parse()), and
some genuine security enhancements went with that, but the form of the API
hasn't, and there's a reason for that: anything more than one monadic function
call is too much work.

Some formats, like TOML, have gone so far as to explicitly specify the data
structure they describe. You could make a no-work API like JSON's for that:
TOML.parse() and TOML.stringify() would take up more code space than their
corresponding JSON APIs, but using the APIs would still involve no work. Less
work, in fact, because TOML has a date literal, which even JSON doesn't.
Something like that could catch on.

------
rpedela
Why don't we just change the JSON spec to include ISO 8601 date, time,
timestamp, and comments?

~~~
Millennium
The problem comes from the fact that JSON is explicitly defined in terms of
JavaScript, and as a strict subset of JavaScript. You could add comments
without much trouble, because JavaScript has comments. But JavaScript has no
date literal, so neither does JSON, and adding one becomes problematic. You'd
have to either decouple JSON from JavaScript, or you'd have to convince the
ECMAScript folks to adopt a date literal syntax.

It could be argued that decoupling JSON from JavaScript might be a good idea.
It would force developers to stop parsing JSON as JavaScript (through eval()
or script tags), and this alone would eliminate whole classes of bugs. But the
logistics would be nothing short of nightmarish.

------
dragonwriter
HTML: sure, its a little heavier than JS, but lighter than XML, popular
languages have libraries to parse it (and doing it consistently is better
since HTML5), and exposing an HTML-based API makes things easy to interact
with.

------
EdgarVerona
Protocol buffers!

