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

[Carsten Bormann <[e-mail]>]

Hi Nico,

> On May 8, 2019, at 20:31, Nico Williams <[e-mail]> wrote:
> 
> 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.)

Huh?  RFC 8259 is very outspoken here:

   Numeric values that cannot be represented in the grammar below (such
   as Infinity and NaN) are not permitted.

So you have a superset of JSON as your jq input grammar, which is fine for me (it just isn’t JSON anymore).  Maybe you mean the sentence in the section about Parsers:

   A JSON parser MAY accept non-JSON forms or extensions.

Yep, non-JSON.  JSON has no extensibility points.

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

Extending the data model to enable expressing two different kinds of numbers, which are identical in numeric value (i.e., JSON semantics), but have different semantics in the data model defined by the extension (distinguishing integer 3 from floating point 3), definitely is an extension.  The fact that only instances are communicated that are also valid under (by definition unextended) JSON semantics doesn’t change this.

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

C14n is a different thing: It reduces the number of different representations allowed for a specific instance in the data model.  There is no new semantics.  A generic decoder will have no problem with inputting a c14nized serialization.  A generic encoder won’t always spit out a c14nized instance (and we don’t expect it to), but a step can be added to convert the JSON instance into the equivalent c14nized instance without breaking that generic JSON encoder.  This is all fairly innocuous.  (It is also hard, and the specific proposal pushed here neither has fully demonstrated that it has nailed the hard parts nor does it use reasonable taste — principle of least surprise — in some other places.  Convert to UTF-16-BE before sorting?  Oof.  But sure, sorting Hittite characters between hangul Jamo and private use can be made interoperable, if it rocks your boat.)  More importantly, C14n ensures that there is no appetite for interpreting two lexically different instances that have the same semantics in JSON as different — at least one of them couldn’t be C14nal!

> […]

Grüße, Carsten