[Json] Adding integers to JSON (Re: JSON Schema Language)

[Carsten Bormann <[e-mail]>]

On May 8, 2019, at 18:07, Nico Williams <[e-mail]> wrote:
> 
> That's an interop bug.  They should fix it.

It also nicely demonstrates the law of inevitable extensibility.

JSON was designed not to provide extensibility.  Ever.
Radical, but a well motivated idea at the time.

Now people did not want to accept that.
They wanted to extend the JSON data model with the distinction between two number types.

The law of inevitable extensibility says:

# If you don’t provide an extension point, somebody will.
# They will shove their extension into any crevice available.
# (And your up to now rock-solid design breaks.)

The crevice here was that there are many ways to express the number 3: 3, 3.0, 3e0, 0.03e2, 300e-2 etc.  We can give some of these expressions different semantics than the other.  Voila.  Extensibility achieved.  Brittleness added.

I have seen the law of inevitable extensibility applied to:

— duplicate map keys for adding comments to JSON.  Some people believe:

  { “postcode”: “This is a comment about the post code 4711”,
    “postcode”: 4711 }

  is a valid way to extend JSON with comments.  (Because their implementation happens to ignore map keys that are invalidly used again later, which is not a given.)

- unnecessary escaping for ascribing some special semantics.  Say, if a string starts with “\u0073” and not with the equivalent “s”, this is supposed to mean the string has some different semantics (e.g., the rest is a base64url encoded byte string as opposed to what would normally be a text string, or a type tag, or…).

— millions of ways of interpreting whitespace or the lack thereof.  I’ve lost count.


I do not think any longer that anything that is meant to see significant usage can be designed without designing in extensibility points from the start.  At least if it is supposed to last.

Grüße, Carsten