- From: John Cowan <cowan@mercury.ccil.org>
- Date: Thu, 21 Nov 2013 11:56:15 -0500
- To: Henri Sivonen <hsivonen@hsivonen.fi>
- Cc: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, Paul Hoffman <paul.hoffman@vpnc.org>, Pete Cordell <petejson@codalogic.com>, JSON WG <json@ietf.org>, es-discuss <es-discuss@mozilla.org>
Henri Sivonen scripsit:
> Why not? Surely existing still deployed producers should be what
> matters when deciding what needs to be ingested--not previous specs.
> That is, compatibility should be considered in terms of what's out
> there--not in terms of what unreasonable things were written down in a
> previous RFC.
In principle, maybe. But testing a dozen browsers isn't enough here.
We simply don't know how much non-browser traffic involves JSON (though
we know there are many such interactions), or what representations they
are using. We have therefore decided in the 4627bis effort not to say
that anything that was previously valid is now invalid. At least, that
is what I understand us to be doing.
> UTF-32 harms JSON interchange, because Gecko removed all UTF-32
> support throughout the engine (other engines probably did, too, but
> I'm too busy to check) and, therefore, XHR responseType = "json"
> doesn't support UTF-32.
That has about as much weight as "XYZ implementation only supports
ASCII, so the use of non-ASCII characters harms JSON interchange" or "ABC
implementation only supports 32-bit integers, so the use of decimal points
harms JSON interchange." An implementation's self-imposed limitations
don't affect the standard.
--
John Cowan http://www.ccil.org/~cowan cowan@ccil.org
if if = then then then = else else else = if;
Received on Thursday, 21 November 2013 16:56:43 UTC