On Tue, Feb 5, 2019 at 2:17 AM Konrad Hinsen <konrad.hin...@fastmail.net> wrote: > > David Storrs <david.sto...@gmail.com> writes: > > > > I was specifically thinking of JSON. It allows for encoding all the > > essential structure of XML in far fewer characters, meaning there's > > less data to send over the wire. It's more human-readable. There are > > JSON is basically a serialization notation for nested lists and hash > maps. What it lacks compared to XML is tags and namespaces. You have to > add a layer of conventions on top of JSON to get some form of data > identification, and since that layer is not standardized, it's likely to > get messy once you need to work with data from different sources. > > JSON is probably a good choice if all software working with your data is > under your control. Less so if the client software pool is open-ended or > if the data may be archived for an indefinite future with different > software tools.
At the risk of sounding snarky, there are a ton of major services that provide JSON interfaces to their APIs. Most provide XML as well, but people are still going to prefer reading the documentation to poring over the DTD in order to figure out what's required, optional, and how to type things. In addition, most developers that I've worked / talked with will typically reach for the JSON API before the XML one given the choice. I think the ground truth suggests that JSON is a perfectly fine choice for open-ended services that are being consumed by software not under your control. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
