[racket] Issue with require/typed and the json library

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.