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

Re: [json] Re: Internet Draft

Expand Messages
  • Martin Cooper
    ... IMHO, this would be a better - and more honest - explanation than just saying it s confusing. -- Martin Cooper Leading zeros are subject to confusion. The
    Message 1 of 17 , Jan 19, 2006
    • 0 Attachment
      On 1/19/06, Douglas Crockford <douglas@...> wrote:
      >
      > > * In section 2.5 on numbers, there is the statement "Leading zeros
      > are not
      > > allowed as that could lead to confusion". I don't understand why leading
      > > zeros would be confusing, expecially when octal and hex forms are not
      > > supported.
      >
      > In JavaScript, leading zero means octal. If JSON allowed leading zeros
      > that do not indicate octal, then it would not be a subset of
      > JavaScript. JSON seeks to be minimal, portable, and a subset of
      > JavaScript.


      IMHO, this would be a better - and more honest - explanation than just
      saying it's confusing.

      --
      Martin Cooper


      Leading zeros are subject to confusion. The public schools tell us
      > they indicate non-significance in decimal. The C languages tell us
      > they indicate octal. Since they ultimately carry no information, it is
      > best to do away with them.
      >
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Robert Cerny
      ... It would help developers, in particular those, who use JSON in many languages. More likley that the first guess is right, less time searching docs. Even on
      Message 2 of 17 , Jan 19, 2006
      • 0 Attachment
        --- In json@yahoogroups.com, "Douglas Crockford" <douglas@c...> wrote:

        > > It would help, if Generators and Parsers across implementations would
        > > use the same names for doing the same thing. A name recommendation,
        > > would go, in the respective section 3 or 4.
        > >
        >
        > How would that help?
        >
        It would help developers, in particular those, who use JSON in many
        languages. More likley that the first guess is right, less time
        searching docs. Even on completion you got better chances. So to cut
        it short: More fun working. And if that isn't something worth aspiring to.
      • Andrew Durdin
        ... A few comments: 1. Is there any reason you re specifying characters in two different styles? For example, in 2.0 you ve got: = %x7B
        Message 3 of 17 , Jan 19, 2006
        • 0 Attachment
          On 1/19/06, Douglas Crockford <douglas@...> wrote:
          > I have submitted a draft to IETF. You can see it here:
          > http://www.ietf.org/internet-drafts/draft-jsonorg-json-00.txt

          A few comments:

          1. Is there any reason you're specifying characters in two different
          styles? For example, in 2.0 you've got:

          <begin-object> = %x7B ; { left brace

          Then in 2.1, you have:

          space U+0020 Space

          Why the difference? If the declarations as per 2.1 form part of a
          grammar in the syntax expected by some common parser generator, then
          why isn't whitespace declared in the same form?


          2. Why the esoteric name "reverse virgule" (section 2.6 and
          throughout) ? The normative name in Unicode 4 for U+005C is "reverse
          solidus", with "backslash" as an alias. I recommend using the term
          "backslash" throughout (as it will be more familiar to readers) and
          mentioning the name "reverse solidus" in section 2.6 where you give
          the code point (and similarly giving the normative names for other
          characters where you give the code point -- for example U+007B is
          "left curly bracket", U+0009 is "character tabulation").


          3. In section 6, you use the vague term "safe". I think a better
          description would be useful, something along the lines of "A text
          containing only JSON tokens is safe to eval because the JSON subset of
          JavaScript does not contain any assignments, function calls, or other
          executable statements."


          Cheers,

          Andrew
        • Douglas Crockford
          Thank you everyone on your comments on the Internet Draft. I am preparing a revision. I have encorporated most of your suggestions. The current state can be
          Message 4 of 17 , Feb 2, 2006
          • 0 Attachment
            Thank you everyone on your comments on the Internet Draft. I am
            preparing a revision. I have encorporated most of your suggestions.
            The current state can be found at
            http://www.json.org/draft-crockford-jsonorg-json-01.txt
          Your message has been successfully submitted and would be delivered to recipients shortly.