John Clements wrote on 12/10/2014 02:56 PM:
Possibly related: the last time I checked, there was no widely adopted
schema system for JSON, which is completely appalling. That is, it’s
not possible to document an HTTP call as “returning a JSON object with
field “timestamp” which is an integer and “value” which is a string
and no other fields thank you very much” except by writing the english
text. My impression is that in the great XML -> JSON switchover,
schemas were the baby that was thrown out with the bathwater.
Yes. XML was always a mess in many ways (even if you didn't know about
atrocities like the recursive textual substitution in DTDs that XML
inherited from SGML). But eventually, after a few attempts, XML wound
up with a not-bad schema language (Relax-NG, when its non-XML syntax
variant is used). Not that a schema language is rocket science or
something new -- I think I've seen the same simple concepts in old '70s
practical books for database developers.
The four main advantages of JSON over XML that I see are:
* JSON is easy to use from JS in Web browsers.
* The very-very simple JSON spec is not full of silly bloat, complexity,
and conflicts like the XML spec.
* JSON parsers less likely to be non-compliant with the spec than XML
parsers.
* JSON (unspecified) schemas less likely to have gratuitous nonsense
than XML ones.[*]
You can add schemas to JSON, but don't be surprised if most people
ignore them or use them wrong.
[*] Harsh-sounding footnote: It seems that most programmers defining
JSON and XML schemas (express, or not) nowadays are corporate IT/Web
programmers, the majority of whom now were brought up in cargo-cult
kludges ways of working, and who can't tell when they specify nonsense
in XML. The discipline for so much work has moved so far towards
dumbed-down clerical work, that I think pretending otherwise is
counterproductive. Most software developers will have to interoperate
with systems built in this way, and use
frameworks/toolkits/'technologies' that have evolved to suit this kind
of working and to mitigate prior bad architecture by piling atop it. I
think understanding this context informs planning and resilience.
Neil V.
____________________
Racket Users list:
http://lists.racket-lang.org/users
