With JSON you know immediately what kind of datatype you are dealing with. You see a { you allocate an associative array, or if you see a [ you know you're about to get an ordered list. With S-Expressions it seems like you need to parse the entire thing and then figure out what kind of data structure you have.
In fact there doesn't appear to be any indicator at. Looking at 2.2.11.3 we see in the JSON that "messages" is an ordered list, but the content of the message is an associative array, but in the S-Expression they look identical.
So in C-like land you would end up with a big nested mess of arrays that are slow to parse and even harder to figure out the address of any object. There's a ton of friction that you don't have with JSON data.
So the easiest way would be to use or code a small lisp interpreter in C and eval the S-expression. For example, one could use Chicken Scheme to do so.
And, yes, it's possible to have vulnerabilities in a JSON parser--but it is orders of magnitude easier to have them in an arbitrary language parser.
Validating a document is a complex, domain-dependant problem. It is far easier to create a secure Domain-Specific Language to handle this than to end up with an accidentally Turing complete abomination like XSLT: http://www.unidex.com/turing/utm.htm
Oh. So all you have to do is write perfectly secure code and run it in a perfectly secure environment, and nothing bad can possibly happen.
Well shit, why didn't anyone else ever think of that?
facepalm
As soon as you've decided to call an eval() function on potentially untrusted data, you've lost to an attacker.
That said, regarding JSON and the inclusion of self-describing encoding information for e.g. Base64, I created a microformat for that:
Yes, it is. People are already used that in dynamic languages (javascript, python, ruby), you can work with unknown structures in a performant way, and they will be mapped properly to the underlying data model.
They are not going to switch to something where you need to have a schema just to parse it properly.
That's actually one of my concerns with JSON: it doesn't really convey the underlying data model. Sure, it can handle numbers — but it can't handle constraints like 'age must be positive.' Sure, it can handle strings — but there's no way in JSON to differentiate between Base64-encoded bytes & a normal string.
JSON lets one play with data, but one never knows if it's actually valid. It's dynamic typing, applied to data itself.
As for data validity, this is completely separate question. I don't believe that validation should be a part of the language or data format -- my language lets me write 'age = "yellow"', and so should my data format.
2.1:
2.2.11: 2.2.11.2Note how JSON has to rely on metadata to indicate that a Base64 sequence, whereas it's natively supported by canonical S-expressions. Note also how the S-expression format natively supports types ('display hints') for its values.
2.2.11.3One might expect that S-expressions might shine when it comes to sending multiple items, and of course one would be correct.
Also note how the parallel structure of the message & message/body/message objects raises the question of whether the message/body/message schema should also be UMF.
2.2.17Note that there is a complex canonicalisation procedure for the JSON object, and that the sender must mutate the signed object; by contrast, the S-expression format is properly layered and doesn't mutate signed objects (which implies that it's possible to chain signatures cleanly).
It's not to late to switch away from JSON, it really isn't.