Re: [Json] Nudging the English-language vs. formalisms discussion forward

[Nico Williams <[e-mail]>]

On Wed, Feb 19, 2014 at 10:05 AM, Tim Bray <[e-mail]> wrote:

> This is why I deplored the recent (but vanishing, thank goodness) trend to
> offer APIs in XML-or-JSON-take-your-pick.

First this objection: indeed, no one should want that.  The only such
conversion that makes sense is JSON->HTML for BUIs, and that should
happen mostly on the client side (except for dumb clients, if the
service wants to reach them).

Even if the conversion can be completely automatic.  Why would anyone
want to burn cycles/energy running such conversions (except perhaps
for the JSON->HTML for dumb clients case)?

> I feel that successful Internet interoperation is achieved at the level of
> syntax; clear specification of which bytes should be sent and which
> returned.  Many times over the years I’ve heard assertions that if you get
> the data model right, then the syntax is ephemeral: JSON or XML or ASN.1,
> who cares? I’ve never found that notion remotely plausible, as there always
> impedence mismatches.  You end up having to fight over another syntax to
> describe the model before you can fight about the syntax you’re going to
> send over the wire.

The syntax is no more ephemeral than the RFC is (where there's an RFC).

Sometimes there's just no need for an RFC.  Most services out there
that define HTTP+JSON APIs don't bother publishing I-Ds for them, much
less RFCs, _even when then promise API stability_.  Yet even then,
syntax can help others implement clients for those APIs -- that's the
point of publishing an API: to help others implement clients for them,
to increase the popularity of the service.

> So, I find Phil’s arguments here (as with most schema-centric arguments)
> entirely unpersuasive.

Phil proposed that conversions to ASN.1 be feasible to please certain
people, not to allow services to serve JSON-or-DER or anything of the
sort.  Your argument about the latter is therefore a non-sequitur.

My proposal is that the WG take all comers for JSON schema languages
as Informational and leave it at that (well, all proposals for which
there's enough authors and reviewers, enough interest).  That can't
even be an irritant for you: you can ignore them...

...unless you think that formal languages used by others will impair
your ability to understand their specs, unless you really prefer
English prose to the max.  That'd be an argument I'd want to hear, if
you were making it.  I'm prepared to buy into a strong such argument,
even though you can probably tell that biased in favor of simple
schema languages.

Nico
--