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

Re: Strings

Expand Messages
  • 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 1 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 2 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 3 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 4 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.