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

[Nico Williams <[e-mail]>]

On Wed, May 08, 2019 at 06:59:54PM +0200, Carsten Bormann wrote:
> 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.

The spec allows extensions, actually, but indeed, it doesn't provide for
extensibility.

(For example, jq will parse Inf and Infinity, but it will not output
such words, nor will it output NaN.)

> 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 particular "extension" we're talking about isn't an extension.

> 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.

If anything one would expect this to bring up canonicalization...
(oh no, I've mentioned that.  please no one take that as a serious
invitation to discuss canonical JSON!)

> 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.)

Yes.

> - 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…).

Oof.

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

Play stupid games...

> 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.

Maybe.

Nico
--