To improve JSON interoperability the IETF should not define a more
restricted version of JSON than defined by Ecma-404.
Parsers exist that can parse "42" today and parsers that cannot parse
"42" today can be meaningfully upgraded to do so too. This would not
break those parsers, unless they depend on parsing 42 as an error,
which is a far more unlikely scenario than parsing it as 42 given
(Worth pondering about: what to do about a leading BOM, which
XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404
On Tue, Nov 12, 2013 at 3:01 PM, Anne van Kesteren <[hidden email]> wrote:
> To improve JSON interoperability the IETF should not define a more
> restricted version of JSON than defined by Ecma-404.
> Parsers exist that can parse "42" today and parsers that cannot parse
> "42" today can be meaningfully upgraded to do so too. This would not
> break those parsers, unless they depend on parsing 42 as an error,
> which is a far more unlikely scenario than parsing it as 42 given
> (Worth pondering about: what to do about a leading BOM, which
> XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404
Re: JSON: remove gap between Ecma-404 and IETF draft
On Tue, Nov 12, 2013 at 5:20 PM, "Martin J. Dürst"
<[hidden email]> wrote:
> If XMLHttpRequest has reasons to continue allowing it, I'd suggest that:
> 1) It strongly discurages it, and
> 2) It defines processing as something roughly like
> a) If the first few bytes look like a BOM, ignore them
> b) Process the rest according to rfc4627bis or ECMA-404 (whichever works
> better if they are not in full alignment).
> That will make sure that variation is confined as locally as possible.
So that is roughly how it is defined. Using the web's "utf-8 text
resource decode" method that removes a BOM and then passing the rest
to something equivalent to JSON.parse(). However, if we are defining a
new text transport format I think it would make sense to allow a
leading BOM similar to how text/css, text/html, etc. allow for that.
To do this, I think the draft requires these changes:
- Remove the trailing section of section 1.2, starting with “ECMAscript 5.1 enumerates...” [because the difference no longer exists]
- In section 2:
-- remove “A JSON text is a serialized object or array.”
-- Insert: “A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array. Implementations which generate only objects or arrays where a JSON text is called for will be interoperable in the sense that all implementations will accept these as conforming JSON texts.”
-- Change the JSON-text production to read:
JSON-text = value
On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) <[hidden email]> wrote:
There appears to be consensus to change JSON-text to allow for any JSON value -- not just object / array -- while noting that object or array as the top-level is the most interoperable.
We will ask the Document Editor to make this change to draft-ietf-json-rfc4627bis.
Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
On Nov 27, 2013, at 7:29 PM, Paul Hoffman wrote:
> <no hat>
> On Nov 27, 2013, at 5:00 PM, Alex Russell <[hidden email]> wrote:
>> Will you also be citing ECMA-404 normatively to avoid this sort of divergence in the future?
> If you believe that ECMA-404 will change in the future, that would indicate that ECMA might break interoperability with current implementations, even for what they perceive as "good reasons". In general, the IETF tries not to have its long-lived standards normatively latch on to moving targets for this very reason. Even when other SDOs have assured us that they will not make backwards-incompatible changes, they have done so anyway (cue the Klensin-esqe theme music...), and that has caused serious interoperability problems for the IETF specs.
Stability of ECMA-404 should not be a concern. As far as I can observe TC39 has absolutely no interest in every changing or extending the JSON grammar. I'm confident TC39 would record that as a statement of policy if asked. In fact, the reason TC39 chose to issue ECMA-404 was because there was concern that the JSON WG was on a path to modify and possibly extend JSON syntax. The only sort of changes to ECAM-404 I ever expect to see would be technical corrections to errors found in the current specification language or the addition of informative material to help clarify understanding of the specification. For example, if there was sufficient public interest we might consider adding an informative Annex that restates the grammar using ABNF notation.
The JSON syntax has its roots in the ECMAScript syntax but is not at all linked to the ECMAScript syntax. The ECMAScript object and array literal constructs were the inspiration for JSON. But even in the beginning, the JSON syntax was only a subset set of the full syntax of those ECMAScript language features. ECMAScript object literal syntax has been significantly extended in both the ECMA-262 5th Edition(2009) and the forthcoming 6th Edition. But those extensions have and will not ever be added to the JSON syntax defined in ECMA-404.
On Mon, Dec 2, 2013 at 1:30 PM, Phillip Hallam-Baker <[hidden email]> wrote:
On Wed, Nov 27, 2013 at 11:51 PM, Tim Berners-Lee <[hidden email]> wrote:
JSON is interesting in being a subset of ECMAscript. That is a big dependency -- will it be preserved?
However as it is unwise to feed JSON into an ECMAscript processor for security reasons, that dependency may not affect code, just mean that JSON and ECMAscript parsers can share parts at the moment.
As I see it, encoding X is a subset of encoding Y if and only if an encoder for X will only produce outputs that are valid inputs of encoding Y.
If an issue was to occur it would be because encoding Y has changed or the definition of Y has changed.
One could imagine that the arc of ECMAscript's evolution could end up
having all kinds of impact on the data structure syntax and semantics.
(unordered sets as alternative to lists? who knows). So in that case one
could imagine pressure to make a new version of JSON to match.
Since we are talking about a serialization format, the distinction between unordered sets and lists cannot occur at the wire level and this is where we need interoperation.
I do in fact have a schema compiler for JSON that allows an interface to specify a set of entries rather than a list. But they are only ever serialized as lists.
Yes, literal ISO dates and dateTimes -- I added them to my own N3/turtle parsers without much fanfare, wish they had been put in the Turtle language too. Maybe they will.
And you probably do exactly what I do and represent a DateTime representation as a subset of String just as byte, int16, int32, int64, uint* are all subsets of Integer.
One of the things I think we have learned from JSON is that a self-describing format only needs to specify the abstract type of the datum and not the representation.
For convenience, I allow a schema to specify the size of an integer and whether it is signed or unsigned so that the code generator can create appropriate code bindings. But none of that shows up on the wire, nor is that particularly helpful.
What we are doing at this point is to fix a version of the JSON encoding in time so that when a client and server are negotiating use of JSON encoding, both sides know what is being negotiated.
So hopefully JSON does not change in future, only the description of JSON.
That is not the same as saying that JSON meets all possible current and future protocol needs. It does not. It is not possible to pass binary data efficiently for a start and using decimal for floating point representation is likely to make the format unacceptable for serious data applications since it introduces conversion errors.
The next question is whether those unmet needs should be addressed by an entirely new encoding with a completely new syntax and structure or whether we could extend the JSON model. My view is that we should do the second.
This seems entirely reasonable, so long as this extension is not called "JSON" (assuming it adds new grammar productions). Hence the request to normatively cite ECMA-404 and re-name any IETF-produced spec to reflect that it is intended to be a media-type registration (or extension document for protocol authoring, etc.), not an alternate (and therefore perhaps extensible) definition of JSON.
XML is fine for documents but it is not meeting my needs as a protocol designer. I find XML Schema to be unnecessarily confusing and baroque, the schema validation features supported don't help me in application protocols. XML does not support binary encoding of cryptographic data or floating point.
There are many data encodings on offer but I would like to be able to write one decoder that can consume a data stream that contains basic JSON data and JSON with extensions. This makes negotiating an encoding in a Web service easy, the consumer states which encodings are acceptable and the sender makes sure what is sent is compatible, downgrading the encoding to the level accepted if necessary.