es-discuss Digest, Vol 76, Issue 36

Erik Reppen erik.reppen at gmail.com
Fri Jun 7 07:18:13 PDT 2013


>From the 39-year-old curmudgeons-before-their-time camp, I'd like to point
out that comments would be bad for two reasons:

1. They're a sure sign somebody's gone and constructed something to fit
implementation/consumption of data rather than describe it which ultimately
makes modifying any system handling and constructing layered/nested JSON
about as much fun as rebuilding a house of cards on a pile of broken glass.

2. The very next version of IE would start doing something awful with them
because Microsoft engineers simply can not resist the temptation to do
neat-o things with comments.

But seriously though, let's KISS on the JSON. It ain't broke.


On Fri, Jun 7, 2013 at 8:41 AM, <es-discuss-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>    1. Re: JSON Duplicate Keys (Alexandre Morgaut)
>    2. Re: JSON specification WAS: Re: JSON Duplicate Keys (Brendan Eich)
>    3. Re: JSON Duplicate Keys (Brendan Eich)
>    4. Re: JSON Duplicate Keys (Brendan Eich)
>    5. Re: JSON specification WAS: Re: JSON Duplicate Keys (gaz Heyes)
>    6. Re: JSON Duplicate Keys (Brian Kardell)
>    7. Re: JSON Duplicate Keys (Kevin Smith)
>
>
> ---------- Forwarded message ----------
> From: Alexandre Morgaut <Alexandre.Morgaut at 4d.com>
> To: Douglas Crockford <douglas at crockford.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Date: Fri, 7 Jun 2013 11:04:58 +0200
> Subject: Re: JSON Duplicate Keys
>
> On 7 juin 2013, at 10:58, Alexandre Morgaut wrote:
> >
> > 3) Another approach could be to let the parse() and stringify() methods
> accept an additional errorCallback parameter
> >
> > It could be nice but it would force the developer to set values for the
> other optional parameters first even if he doesn't need them
> >
>
> Well, of course, the errorCallback might be set via something like
> JSON.onerror but a specific callback may easily overwrite a previously
> defined global one and integrating the whole W3C EventTarget interface in
> ECMAScript might not be easily acceptable
>
>
>
>
> Alexandre Morgaut
> Wakanda Community Manager
>
> 4D SAS
> 60, rue d'Alsace
> 92110 Clichy
> France
>
> Standard : +33 1 40 87 92 00
> Email :    Alexandre.Morgaut at 4d.com
> Web :      www.4D.com
>
>
>
>
> ---------- Forwarded message ----------
> From: Brendan Eich <brendan at mozilla.com>
> To: gaz Heyes <gazheyes at gmail.com>
> Cc: Douglas Crockford <douglas at crockford.com>, es-discuss Steen <
> es-discuss at mozilla.org>
> Date: Fri, 07 Jun 2013 11:43:07 +0100
> Subject: Re: JSON specification WAS: Re: JSON Duplicate Keys
> gaz Heyes wrote:
>
>> When ES5 introduced line/para separators for valid new lines in
>> JavaScript this broke the JSON specification
>>
>
> ES3, not ES5, way back in 1999, introduced LINE_SEPARATOR and
> PARA_SEPARATOR as line terminators. See ECMA-262 Edition 3, 7.3.
>
> /be
>
>
>
> ---------- Forwarded message ----------
> From: Brendan Eich <brendan at mozilla.com>
> To: Allen Wirfs-Brock <allen at wirfs-brock.com>
> Cc: Douglas Crockford <douglas at crockford.com>, es-discuss <
> es-discuss at mozilla.org>
> Date: Fri, 07 Jun 2013 12:13:25 +0100
> Subject: Re: JSON Duplicate Keys
> Allen Wirfs-Brock wrote:
>
> The ES5 spec. for JSON.parse requires (ie MUST accept) that duplicate keys
> are accepted and that the value associated with the last duplicated key
> wins.  A valid implementation of JSON.parse MUST not reject such JSON
> strings.
>
>
> IETF has SHOULD as well as MUST, though. Normative specs can say what must
> happen, but also what should happen in a clean-slate or ideal-world
> setting. The Internet evolved with Postel's Law falling out of the process.
>
> Previously you wrote:
>
> > I would be willing to [lose] the first sentence (containing the SHOULD)
> entirely as it doesn't add any real normative value.
>
> But normative RFCs/internet-drafts that use SHOULD not MUST still have
> value.
>
> >From http://tools.ietf.org/html/rfc2119
>
> 1 <http://tools.ietf.org/html/rfc2119#section-1>. MUST     This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
> 2 <http://tools.ietf.org/html/rfc2119#section-2>. MUST NOT     This phrase, or the phrase "SHALL NOT", mean that the
>    definition is an absolute prohibition of the specification.
> 3 <http://tools.ietf.org/html/rfc2119#section-3>. SHOULD     This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
> 4 <http://tools.ietf.org/html/rfc2119#section-4>. SHOULD NOT     This phrase, or the phrase "NOT RECOMMENDED" mean that
>    there may exist valid reasons in particular circumstances when the
>    particular behavior is acceptable or even useful, but the full
>    implications should be understood and the case carefully weighed
>    before implementing any behavior described with this label.
> 5 <http://tools.ietf.org/html/rfc2119#section-5>. MAY     This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the same item.
>    An implementation which does not include a particular option MUST be
>    prepared to interoperate with another implementation which does
>    include the option, though perhaps with reduced functionality. In the
>    same vein an implementation which does include a particular option
>    MUST be prepared to interoperate with another implementation which
>    does not include the option (except, of course, for the feature the
>    option provides.)
> 6 <http://tools.ietf.org/html/rfc2119#section-6>. Guidance in the use of these Imperatives   Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmissions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
>
>
> /be
>
>
>
> ---------- Forwarded message ----------
> From: Brendan Eich <brendan at mozilla.com>
> To: es-discuss <es-discuss at mozilla.org>
> Cc:
> Date: Fri, 07 Jun 2013 12:19:16 +0100
> Subject: Re: JSON Duplicate Keys
> Mark S. Miller wrote:
>
>> Everyone, please keep in mind that JSON does not and never has claimed to
>> be the best or last data format. No doubt many better ones have been and
>> will be created, some as variants of JSON, some not. If you'd like to
>> create a "fixed JSON" or "enhanced JSON" or whatever, feel free -- whether
>> it treats comments, duplicated keys, or \u2028 differently or whatever. But
>> please don't confuse any of these variants with JSON itself. As a data
>> format, JSON's greatest value is its stability, and the inability for
>> anyone, including us, to version it.
>>
>
> +∞
>
> "Get off my lawn!" comment (I will tag in and tag Doug out of the grumpy
> old men smackdown ring): you kids stop fiddling with JSON. It needs
> "fixing" like it needs a hole in the head.
>
> /be
>
>
>
> ---------- Forwarded message ----------
> From: gaz Heyes <gazheyes at gmail.com>
> To: Brendan Eich <brendan at mozilla.com>
> Cc: Douglas Crockford <douglas at crockford.com>, es-discuss Steen <
> es-discuss at mozilla.org>
> Date: Fri, 7 Jun 2013 12:55:09 +0100
> Subject: Re: JSON specification WAS: Re: JSON Duplicate Keys
> On 7 June 2013 11:43, Brendan Eich <brendan at mozilla.com> wrote:
>
>> ES3, not ES5, way back in 1999, introduced LINE_SEPARATOR and
>> PARA_SEPARATOR as line terminators. See ECMA-262 Edition 3, 7.3.
>>
>
> Oh that makes it better then =)
>
>
> ---------- Forwarded message ----------
> From: Brian Kardell <bkardell at gmail.com>
> To: Brendan Eich <brendan at mozilla.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Date: Fri, 7 Jun 2013 08:49:25 -0400
> Subject: Re: JSON Duplicate Keys
>
> (Snipping out everything as this is a holistic response to the whole
> thread)
>
> ....
>
> Re: MUST / last value
> Agree, codify the de facto standard.  That is what we do almost
> universally - it doesn't even actually "break" anything that already works
> - it just means those parsers aren't strictly conforming - they already
> aren't in keeping with the norm.
>
> .....
>
> Re: Should allow comments / single quotes
> Perhaps if we went back in time and were discussing creating a new format,
> you might even convince Doug of some of this - what we wouldn't know is how
> that would affect adoption/development of compatible parsers, bugs, etc -
> and that is important given the next comment...
>
> .....
>
> Re: The Web can't evolve if you can't...AND create something else, but
> don't call it JSON.. AND inventing crappy syntax
>
> JSON is maybe the single best proof that the Web can evolve without
> breaking anything... It started out competing with XML which had every
> advantage imaginable: it was a REC standard, had support from every big
> company, hundreds of libraries, had built in/native support in just about
> every language and was "technically superior".  JSON had simplicity and dev
> contributions.  It competed in the real world and won hearts and minds
> against all odds.  Now we have a standard of agreement - you can't break
> it.  The Web is an enterprise of unparalleled scale, JSON is a data
> interchange format, so even more so than something that exists only in
> browsers...Anything that breaks potentially affects people's (not
> developers) lives in real ways and has to be done with great care.   You
> can, however, follow the same model and beat it.  In this case, if you have
> minor changes, it is even easy to make something that can transform to
> existing JSON format...  If you do, we can easily make it native/standard -
> and you can expect that eventually someone will have similar criticisms and
> try to compete  - that's a good thing.
>
> #extendthewebforward :)
>
>
> ---------- Forwarded message ----------
> From: Kevin Smith <zenparsing at gmail.com>
> To: Brendan Eich <brendan at mozilla.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Date: Fri, 7 Jun 2013 09:41:48 -0400
> Subject: Re: JSON Duplicate Keys
>
> +∞
>>
>> "Get off my lawn!" comment (I will tag in and tag Doug out of the grumpy
>> old men smackdown ring): you kids stop fiddling with JSON. It needs
>> "fixing" like it needs a hole in the head.
>>
>>
> Comment syntax sure would be nice though : P
>
> { Kevin }
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130607/7697a59b/attachment-0001.html>


More information about the es-discuss mailing list