Loading ...
Sorry, an error occurred while loading the content.

Strings

Expand Messages
  • Douglas Crockford
    JSON has a string notation which is similar to that used in the C family languages. Strings are bounded by double quote characters. Escapement is provided by
    Message 1 of 12 , Jan 3, 2006
    • 0 Attachment
      JSON has a string notation which is similar to that used in the C
      family languages. Strings are bounded by double quote characters.
      Escapement is provided by the backslash. The spec specifically allows
      the slash to be escaped so that JSON can be delivered in HTML documents.

      The single quote convention is not included in JSON because it is not
      needed. All strings can be represented with the double quote notation.
      C itself does not have single quote strings. Many PHP programmers are
      confused by JavaScript's single quote strings.

      JSON requires that keys be quoted because of an error in the
      ECMAScript spec that disallows the use of unquoted reserved words as
      keys. The list of reserved words is surprisingly long and difficult to
      remember. The best practice is to always quote keys.

      As an historical note, the very first JSON message contained as one of
      its keys the word "do". It was not quoted, and it caused a syntax error.
    • Martin Cooper
      ... These statements have me really wondering about what JSON is supposed to be. The reasoning behind removing comments was that it would more closely align
      Message 2 of 12 , Jan 3, 2006
      • 0 Attachment
        On 1/3/06, Douglas Crockford <douglas@...> wrote:
        >
        > JSON has a string notation which is similar to that used in the C
        > family languages. Strings are bounded by double quote characters.
        > Escapement is provided by the backslash. The spec specifically allows
        > the slash to be escaped so that JSON can be delivered in HTML documents.


        These statements have me really wondering about what JSON is supposed to be.
        The reasoning behind removing comments was that it would "more closely align
        JSON with YAML and Python". Now we have double quoted strings only, which is
        "similar to that used in the C family language", and so that it "can be
        delivered in HTML documents".

        And here was me blithely thinking JSON was supposed to be a "JavaScript
        Object Notation". What happened to the JavaScript focus? With all due
        respect, it's beginning to seem like JSON is supposed to be a minimalist
        object notation that's compatible with JavaScript and as many other
        languages as possible. Perhaps it should be renamed "MON" for Minimal Object
        Notation? ;-) The "JSON" moniker is seeming less and less appropriate.

        The single quote convention is not included in JSON because it is not
        > needed.


        It wasn't "needed" in JavaScript / ECMAScript either, but they still
        included it. It's convenient because it frequently allows you to avoid
        backslashes / escapes in string literals.

        All strings can be represented with the double quote notation.
        > C itself does not have single quote strings. Many PHP programmers are
        > confused by JavaScript's single quote strings.


        Add PHP to the list of non-JavaScript languages JSON is trying to cater
        to... (... and add PHP programmers to my list of not-so-smart-folks if they
        can't understand string quoting... ;)

        JSON requires that keys be quoted because of an error in the
        > ECMAScript spec that disallows the use of unquoted reserved words as
        > keys. The list of reserved words is surprisingly long and difficult to
        > remember. The best practice is to always quote keys.


        That is a good reason to document a "best practice". It is in no way a
        reason to ban people from using unquoted key names.

        As an historical note, the very first JSON message contained as one of
        > its keys the word "do". It was not quoted, and it caused a syntax error.


        Not a good start, huh? ;-)

        --
        Martin Cooper


        Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Douglas Crockford
        ... That is correct. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of
        Message 3 of 12 , Jan 4, 2006
        • 0 Attachment
          > And here was me blithely thinking JSON was supposed to be a "JavaScript
          > Object Notation". What happened to the JavaScript focus? With all due
          > respect, it's beginning to seem like JSON is supposed to be a minimalist
          > object notation that's compatible with JavaScript and as many other
          > languages as possible.

          That is correct.

          JSON is a text format that is completely language independent but uses
          conventions that are familiar to programmers of the C-family of
          languages, including C, C++, C#, Java, JavaScript, Perl, Python, and
          many others. These properties make JSON an ideal data-interchange
          language.

          JSON is built on two structures:

          * A collection of name/value pairs. In various languages, this is
          realized as an object, record, struct, dictionary, hash table, keyed
          list, or associative array.
          * An ordered list of values. In most languages, this is realized
          as an array, vector, list, table, or sequence.

          These are universal data structures. Virtually all modern programming
          languages support them in one form or another. It makes sense that a
          data format that is interchangable with programming languages also be
          based on these structures.

          See http://www.JSON.org
        • George
          I agree 100% with you. Do as I do and use Javascript Object Literals as they are specified in the Javascript or ECMAScript Reference. Anything the JS parser
          Message 4 of 12 , Jan 4, 2006
          • 0 Attachment
            I agree 100% with you.
            Do as I do and use Javascript Object Literals as they are specified in
            the Javascript or ECMAScript Reference.

            Anything the JS parser allows is considered valid:
            - Comments
            - Quoted/Unquoted keys
            - Numbered Keys
            - Single/Double Quotes
            - Scientific Notation
            - Unicode

            It is up to the coder to define 'best practices' not the format to
            impose or restrict them.

            Then again, it is a 'subset' of JavaScript Object Literals, lowest
            common denominator to be compatible with other languages.

            If your target are web apps, HTML and JS, just go and use the whole
            set and more.

            Crockford knows I always opposed his stubbornness ;-)

            George

            --- In json@yahoogroups.com, Martin Cooper <mfncooper@g...> wrote:
            >
            > On 1/3/06, Douglas Crockford <douglas@c...> wrote:
            > >
            > > JSON has a string notation which is similar to that used in the C
            > > family languages. Strings are bounded by double quote characters.
            > > Escapement is provided by the backslash. The spec specifically allows
            > > the slash to be escaped so that JSON can be delivered in HTML
            documents.
            >
            >
            > These statements have me really wondering about what JSON is
            supposed to be.
            > The reasoning behind removing comments was that it would "more
            closely align
            > JSON with YAML and Python". Now we have double quoted strings only,
            which is
            > "similar to that used in the C family language", and so that it "can be
            > delivered in HTML documents".
            >
            > And here was me blithely thinking JSON was supposed to be a "JavaScript
            > Object Notation". What happened to the JavaScript focus? With all due
            > respect, it's beginning to seem like JSON is supposed to be a minimalist
            > object notation that's compatible with JavaScript and as many other
            > languages as possible. Perhaps it should be renamed "MON" for
            Minimal Object
            > Notation? ;-) The "JSON" moniker is seeming less and less appropriate.
            >
            > The single quote convention is not included in JSON because it is not
            > > needed.
            >
            >
            > It wasn't "needed" in JavaScript / ECMAScript either, but they still
            > included it. It's convenient because it frequently allows you to avoid
            > backslashes / escapes in string literals.
            >
            > All strings can be represented with the double quote notation.
            > > C itself does not have single quote strings. Many PHP programmers are
            > > confused by JavaScript's single quote strings.
            >
            >
            > Add PHP to the list of non-JavaScript languages JSON is trying to cater
            > to... (... and add PHP programmers to my list of not-so-smart-folks
            if they
            > can't understand string quoting... ;)
            >
            > JSON requires that keys be quoted because of an error in the
            > > ECMAScript spec that disallows the use of unquoted reserved words as
            > > keys. The list of reserved words is surprisingly long and difficult to
            > > remember. The best practice is to always quote keys.
            >
            >
            > That is a good reason to document a "best practice". It is in no way a
            > reason to ban people from using unquoted key names.
            >
            > As an historical note, the very first JSON message contained as one of
            > > its keys the word "do". It was not quoted, and it caused a syntax
            error.
            >
            >
            > Not a good start, huh? ;-)
            >
            > --
            > Martin Cooper
            >
            >
            > Yahoo! Groups Links
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            >
            >
            > [Non-text portions of this message have been removed]
            >
          • Michal Migurski
            ... Beginning to? I thought this was the idea all along? Syntax that s valid Javascript, Python, and easy to write parsers for other languages. I m already
            Message 5 of 12 , Jan 4, 2006
            • 0 Attachment
              > And here was me blithely thinking JSON was supposed to be a
              > "JavaScript
              > Object Notation". What happened to the JavaScript focus? With all due
              > respect, it's beginning to seem like JSON is supposed to be a
              > minimalist
              > object notation that's compatible with JavaScript and as many other
              > languages as possible.

              Beginning to? I thought this was the idea all along? Syntax that's
              valid Javascript, Python, and easy to write parsers for other
              languages. I'm already using it in a number of situations where
              Javascript plays no role whatsoever (e.g., interprocess communication
              between Python and PHP), and its simplicity makes me quite happy.

              > Add PHP to the list of non-JavaScript languages JSON is trying to
              > cater
              > to... (... and add PHP programmers to my list of not-so-smart-folks
              > if they
              > can't understand string quoting... ;)

              !

              Honestly, I don't understand the desire to gum up the works here.
              Comments, quoting options - use raw Javascript or XOXO for strings,
              lists and dictionaries if you need such extras. JSON as a spec is
              simple, elegant, and complete.

              ----------------------------------------------------------------
              michal migurski- contact info and pgp key:
              sf/ca http://mike.teczno.com/contact.html





              [Non-text portions of this message have been removed]
            • Martin Cooper
              ... Then can you please explain why it is called JavaScript Object Notation? -- Martin Cooper but uses ... [Non-text portions of this message have been
              Message 6 of 12 , Jan 4, 2006
              • 0 Attachment
                On 1/4/06, Douglas Crockford <douglas@...> wrote:
                >
                > > And here was me blithely thinking JSON was supposed to be a "JavaScript
                > > Object Notation". What happened to the JavaScript focus? With all due
                > > respect, it's beginning to seem like JSON is supposed to be a minimalist
                > > object notation that's compatible with JavaScript and as many other
                > > languages as possible.
                >
                > That is correct.
                >
                > JSON is a text format that is completely language independent


                Then can you please explain why it is called JavaScript Object Notation?

                --
                Martin Cooper


                but uses
                > conventions that are familiar to programmers of the C-family of
                > languages, including C, C++, C#, Java, JavaScript, Perl, Python, and
                > many others. These properties make JSON an ideal data-interchange
                > language.
                >
                > JSON is built on two structures:
                >
                > * A collection of name/value pairs. In various languages, this is
                > realized as an object, record, struct, dictionary, hash table, keyed
                > list, or associative array.
                > * An ordered list of values. In most languages, this is realized
                > as an array, vector, list, table, or sequence.
                >
                > These are universal data structures. Virtually all modern programming
                > languages support them in one form or another. It makes sense that a
                > data format that is interchangable with programming languages also be
                > based on these structures.
                >
                > See http://www.JSON.org
                >
                >
                >
                >
                >
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
                >
                >
                >


                [Non-text portions of this message have been removed]
              • Douglas Crockford
                ... JSON is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. See http://www.JSON.org/
                Message 7 of 12 , Jan 4, 2006
                • 0 Attachment
                  > Then can you please explain why it is called JavaScript Object Notation?

                  JSON is based on a subset of the JavaScript Programming Language,
                  Standard ECMA-262 3rd Edition - December 1999.

                  See http://www.JSON.org/
                • Atif Aziz
                  ... It is up to the coder to define best practices not the format to impose or restrict them.
                  Message 8 of 12 , Jan 5, 2006
                  • 0 Attachment
                    >>
                    It is up to the coder to define 'best practices' not the format to
                    impose or restrict them.
                    <<

                    Agreed. The problem lies in some of the inconsistencies surrounding
                    the goals, purpose and application of JSON and which I am interested
                    in seeing disambiguated. As it stands, right now, the contents of
                    the specification are, without a doubt, really good enough for a
                    machine encoder. There is little information in there to guide the
                    decoders. A human encoder is only at the mercy of the decoder's
                    flexibility and there's even more trouble if the implementation
                    swaps from underneath his or her feet. Why are humans such a big
                    issue? Well, it's right there as the second claim in the
                    specification: "It is easy for humans to read and write." The rules
                    about strings and unquotable member names is less of a concern for
                    humans because allowing a smaller subset means remembering fewer
                    rules. However, the resistance to mention comments whatsoever is
                    just incomprehensible and beyond me.

                    >>
                    Then again, it is a 'subset' of JavaScript Object Literals, lowest
                    common denominator to be compatible with other languages.
                    <<

                    Incidentally, what is a data format doing concerning itself with
                    lanugages and bindings? I can understand leveraging familiarity with
                    existing syntax across the C-family of languages, but that can only
                    be used with grain of salt in the design of the data format. The
                    lowest common denominator argument is only good enough while things
                    remain simple.

                    --- In json@yahoogroups.com, "George" <georgenava@y...> wrote:
                    >
                    > I agree 100% with you.
                    > Do as I do and use Javascript Object Literals as they are
                    specified in
                    > the Javascript or ECMAScript Reference.
                    >
                    > Anything the JS parser allows is considered valid:
                    > - Comments
                    > - Quoted/Unquoted keys
                    > - Numbered Keys
                    > - Single/Double Quotes
                    > - Scientific Notation
                    > - Unicode
                    >
                    > It is up to the coder to define 'best practices' not the format to
                    > impose or restrict them.
                    >
                    > Then again, it is a 'subset' of JavaScript Object Literals, lowest
                    > common denominator to be compatible with other languages.
                    >
                    > If your target are web apps, HTML and JS, just go and use the whole
                    > set and more.
                    >
                    > Crockford knows I always opposed his stubbornness ;-)
                    >
                    > George
                    >
                    > --- In json@yahoogroups.com, Martin Cooper <mfncooper@g...> wrote:
                    > >
                    > > On 1/3/06, Douglas Crockford <douglas@c...> wrote:
                    > > >
                    > > > JSON has a string notation which is similar to that used in
                    the C
                    > > > family languages. Strings are bounded by double quote
                    characters.
                    > > > Escapement is provided by the backslash. The spec specifically
                    allows
                    > > > the slash to be escaped so that JSON can be delivered in HTML
                    > documents.
                    > >
                    > >
                    > > These statements have me really wondering about what JSON is
                    > supposed to be.
                    > > The reasoning behind removing comments was that it would "more
                    > closely align
                    > > JSON with YAML and Python". Now we have double quoted strings
                    only,
                    > which is
                    > > "similar to that used in the C family language", and so that
                    it "can be
                    > > delivered in HTML documents".
                    > >
                    > > And here was me blithely thinking JSON was supposed to be
                    a "JavaScript
                    > > Object Notation". What happened to the JavaScript focus? With
                    all due
                    > > respect, it's beginning to seem like JSON is supposed to be a
                    minimalist
                    > > object notation that's compatible with JavaScript and as many
                    other
                    > > languages as possible. Perhaps it should be renamed "MON" for
                    > Minimal Object
                    > > Notation? ;-) The "JSON" moniker is seeming less and less
                    appropriate.
                    > >
                    > > The single quote convention is not included in JSON because it
                    is not
                    > > > needed.
                    > >
                    > >
                    > > It wasn't "needed" in JavaScript / ECMAScript either, but they
                    still
                    > > included it. It's convenient because it frequently allows you to
                    avoid
                    > > backslashes / escapes in string literals.
                    > >
                    > > All strings can be represented with the double quote notation.
                    > > > C itself does not have single quote strings. Many PHP
                    programmers are
                    > > > confused by JavaScript's single quote strings.
                    > >
                    > >
                    > > Add PHP to the list of non-JavaScript languages JSON is trying
                    to cater
                    > > to... (... and add PHP programmers to my list of not-so-smart-
                    folks
                    > if they
                    > > can't understand string quoting... ;)
                    > >
                    > > JSON requires that keys be quoted because of an error in the
                    > > > ECMAScript spec that disallows the use of unquoted reserved
                    words as
                    > > > keys. The list of reserved words is surprisingly long and
                    difficult to
                    > > > remember. The best practice is to always quote keys.
                    > >
                    > >
                    > > That is a good reason to document a "best practice". It is in no
                    way a
                    > > reason to ban people from using unquoted key names.
                    > >
                    > > As an historical note, the very first JSON message contained as
                    one of
                    > > > its keys the word "do". It was not quoted, and it caused a
                    syntax
                    > error.
                    > >
                    > >
                    > > Not a good start, huh? ;-)
                    > >
                    > > --
                    > > Martin Cooper
                    > >
                    > >
                    > > Yahoo! Groups Links
                    > > >
                    > > >
                    > > >
                    > > >
                    > > >
                    > > >
                    > > >
                    > >
                    > >
                    > > [Non-text portions of this message have been removed]
                    > >
                    >
                  • Atif Aziz
                    ... And who took away single quoted strings and unquoted member names?! Hell yes, I d like to see the reasoning for changes like that, too.
                    Message 9 of 12 , Jan 5, 2006
                    • 0 Attachment
                      Dave said [1]:

                      >>
                      And who took away single quoted strings and unquoted member names?!
                      Hell yes, I'd like to see the reasoning for changes like that, too.<<
                      <<

                      I'd like apologize for this misconception and correct where I have
                      been wrong. It appears that the spec never actually endorsed
                      unquoted keys or single-quote strings. I went back and looked at the
                      earliest version of the spec [2] I could find (dated Apr 17, 2003)
                      and there's no mention of it in there. So technically speaking, it
                      was never removed (unlike comments, which were). Whether they should
                      be added is another story altogether. Right now, I'd just like to
                      stick to clarification.

                      The confusion came from two sources. First of all, the JSON spec
                      seemed small enough to keep in the head. In fact, the easiest rule
                      to remember was that, aside from expressions, JSON is really just a
                      formalization of JavaScript's literal notation for dictionaries,
                      arrays and primitives like strings, numbers, booleans and null. It
                      turns out that it's a little less than that, but this detail fades
                      away as you spend time in the various implementations; therein lies
                      the second problem. Most implementations seem to be exercising (and
                      rightly so) a good axiom of the web, "Be liberal in what you require
                      but conservative in what you do." So the spec is clear and thorough
                      from the encoding perspective (conservative) and no one has
                      questioned that (some have been calling it "best practices"). The
                      decoding end, however, varies a lot and leads to confusion
                      (including my own rearding quotes). I originally started my C#
                      implementation as a re-factoring of the Java version 0.1 [3]. At the
                      time, this is what was said about the parser's level of tolerance:

                      ========================================
                      The texts produced by the toString() methods are very strict. The
                      constructors are more forgiving in the texts they will accept.

                      - An extra comma may appear just before the closing brace.
                      - Strings may be quoted with single quotes.
                      - Strings do not need to be quoted at all if they do not contain
                      leading or trailing spaces, and if they do not contain any of these
                      characters: { } [ ] / \ : ,
                      - Numbers may have the 0- (octal) or 0x- (hex) prefix.
                      ========================================

                      The second and third point had somehow ruined my memory of the spec
                      as I started spending more time in unit-testing and bootstrapping
                      the parser with hand-coded JSON samples. The original JavaScript
                      implementation [4] was on par with the above level of acceptance. In
                      fact, both allowed more JavaScript literals to be expressed than
                      JSON permits (which you could argue was reasonable). Today, version
                      2.0 of the Java implementation [4] has gone considerably more
                      liberal:

                      ========================================
                      The constructors are more forgiving in the texts they will accept:

                      - An extra , (comma) may appear just before the closing brace.
                      - Strings may be quoted with ' (single quote).
                      - Strings do not need to be quoted at all if they do not begin with
                      a quote or single quote, and if they do not contain leading or
                      trailing spaces, and if they do not contain any of these characters:
                      { } [ ] / \ : , = ; # and if they do not look like numbers and if
                      they are not the reserved words true, false, or null.
                      - Keys can be followed by = or => as well as by :.
                      - Values can be followed by ; (semicolon) as well as by , (comma).
                      - Numbers may have the 0- (octal) or 0x- (hex) prefix.
                      - Comments written in the slashshlash, slashstar, and hash
                      conventions will be ignored.
                      ========================================

                      Fine, so these are the decisions of merely one implementation. What
                      is disturbing, however, is that the JavaScript version has gone
                      completely in the opposite direction in favor of speed; so as to be
                      able to benefit from native parsing provided strict adherence to the
                      JSON token space. Consequently, it's gone intolerant and sticks to
                      the encoding specification, bit-by-bit. So much so, that a JSON
                      sample (incidentally with comments) on the site [6] won't pass it.
                      Again, if this was done in a compatible manner then it would be less
                      of a problem, but I consider these to be *reference* implementations
                      of the standard!

                      My comments on comments (pun intended), however, still stand in face
                      of weak and subjective arguments that they are not needed. It is
                      precisely in the light of such concerns that I was hoping that
                      comments warrant a mention!

                      -Atif

                      ----------

                      [1] http://shrinkster.com/ahp ;
                      http://groups.yahoo.com/group/json/message/186
                      [2] http://shrinkster.com/ahq ;
                      http://web.archive.org/web/*/http://www.crockford.com/JSON/
                      [3] http://shrinkster.com/ahr ;
                      http://web.archive.org/web/20050306024809/http://www.crockford.com/JS
                      ON/javadoc/org/json/JSONObject.html
                      [4] http://shrinkster.com/ahs ;
                      http://www.raboof.com/Projects/Jayrock/json.js
                      [5] http://shrinkster.com/aht ;
                      http://www.crockford.com/JSON/javadoc/org/json/JSONObject.html
                      [6] http://shrinkster.com/ahu ;
                      http://www.crockford.com/JSON/example.html

                      --- In json@yahoogroups.com, "Douglas Crockford" <douglas@c...>
                      wrote:
                      >
                      > JSON has a string notation which is similar to that used in the C
                      > family languages. Strings are bounded by double quote characters.
                      > Escapement is provided by the backslash. The spec specifically
                      allows
                      > the slash to be escaped so that JSON can be delivered in HTML
                      documents.
                      >
                      > The single quote convention is not included in JSON because it is
                      not
                      > needed. All strings can be represented with the double quote
                      notation.
                      > C itself does not have single quote strings. Many PHP programmers
                      are
                      > confused by JavaScript's single quote strings.
                      >
                      > JSON requires that keys be quoted because of an error in the
                      > ECMAScript spec that disallows the use of unquoted reserved words
                      as
                      > keys. The list of reserved words is surprisingly long and
                      difficult to
                      > remember. The best practice is to always quote keys.
                      >
                      > As an historical note, the very first JSON message contained as
                      one of
                      > its keys the word "do". It was not quoted, and it caused a syntax
                      error.
                      >
                    • Douglas Crockford
                      ... I used to agree what comments would be useful. But since I started using JSON, I never discovered what that use was. I have seen them used very badly. I
                      Message 10 of 12 , Jan 5, 2006
                      • 0 Attachment
                        > My comments on comments (pun intended), however, still stand in face
                        > of weak and subjective arguments that they are not needed. It is
                        > precisely in the light of such concerns that I was hoping that
                        > comments warrant a mention!

                        I used to agree what comments would be useful. But since I started
                        using JSON, I never discovered what that use was. I have seen them
                        used very badly. I have asked several times what the value is that
                        requires that support be added to every implementation. I am still
                        listening.
                      • Martin Cooper
                        ... You re not convinced that saving developers time is valuable? OK, then, how about compatibility? There are lots of JSON implementations out there already,
                        Message 11 of 12 , Jan 5, 2006
                        • 0 Attachment
                          On 1/5/06, Douglas Crockford <douglas@...> wrote:
                          >
                          > > My comments on comments (pun intended), however, still stand in face
                          > > of weak and subjective arguments that they are not needed. It is
                          > > precisely in the light of such concerns that I was hoping that
                          > > comments warrant a mention!
                          >
                          > I used to agree what comments would be useful. But since I started
                          > using JSON, I never discovered what that use was. I have seen them
                          > used very badly. I have asked several times what the value is that
                          > requires that support be added to every implementation. I am still
                          > listening.


                          You're not convinced that saving developers' time is valuable?

                          OK, then, how about compatibility? There are lots of JSON implementations
                          out there already, and I'm sure most of them already support comments, my
                          own included. Interoperability between those and new ones would be reduced
                          by eliminating comments from the spec now. The cat is already out of the
                          bag.

                          --
                          Martin Cooper


                          Yahoo! Groups Links
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >


                          [Non-text portions of this message have been removed]
                        • jemptymethod
                          ... I don t think this is an error in the ... spec .... I can think of at least one other language that disallows unquoted reserved words as keys (Lua), and
                          Message 12 of 12 , Jan 14, 2006
                          • 0 Attachment
                            --- In json@yahoogroups.com, "Douglas Crockford" <douglas@c...> wrote:
                            >
                            > JSON requires that keys be quoted because of an error in the
                            > ECMAScript spec that disallows the use of unquoted reserved words as
                            > keys. The list of reserved words is surprisingly long and difficult to
                            > remember. The best practice is to always quote keys.

                            I don't think this is "an error in the ... spec" .... I can think of
                            at least one other language that disallows unquoted reserved words as
                            keys (Lua), and there are others I'm certain
                          Your message has been successfully submitted and would be delivered to recipients shortly.