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

Re: Internet Draft

Expand Messages
  • Robert Cerny
    One suggestion: It would help, if Generators and Parsers across implementations would use the same names for doing the same thing. A name recommendation, would
    Message 1 of 17 , Jan 19, 2006
    • 0 Attachment
      One suggestion:

      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.

      At the moment there is quite a number of names for the same thing!
      "decode", "encode", "stringify", "eval", "load" and "dump" to name
      just a few.

      It would make sense to have one to naming conventions
      --- In json@yahoogroups.com, "Douglas Crockford" <douglas@c...> wrote:
      >
      > I have submitted a draft to IETF. You can see it here:
      > http://www.ietf.org/internet-drafts/draft-jsonorg-json-00.txt
      >
    • Douglas Crockford
      ... (a colon) ... that the ... would be ... The significance of spaces is YAML s problem. They need to develop a transition plan away from it. JSON s position
      Message 2 of 17 , Jan 19, 2006
      • 0 Attachment
        > I suggest adding to section 4 Generators:
        >
        > A JSON generator SHOULD output a space after a <name-separator>
        (a colon)
        > or a <value-separator> (a comma).
        >
        > From what you've said about YAML compatibility issues, I take it
        that the
        > output of a JSON generator which follows the above recommendation
        would be
        > valid YAML input.

        The significance of spaces is YAML's problem. They need to develop a
        transition plan away from it. JSON's position on space after comma is
        an implied MAY, and I think it can stay that way.
      • Douglas Crockford
        ... are not ... 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.
        Message 3 of 17 , Jan 19, 2006
        • 0 Attachment
          > * 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.

          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.
        • Douglas Crockford
          ... How would that help?
          Message 4 of 17 , Jan 19, 2006
          • 0 Attachment
            > One suggestion:
            >
            > 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.
            >
            > At the moment there is quite a number of names for the same thing!
            > "decode", "encode", "stringify", "eval", "load" and "dump" to name
            > just a few.
            >
            > It would make sense to have one to naming conventions

            How would that help?
          • Josh Sled
            ... [Sorry to reply to this rather than the original, but I never received it. :/] In Section 5 you assert that the MIME media type is text/json ... is that
            Message 5 of 17 , Jan 19, 2006
            • 0 Attachment
              On Wed, 2006-01-18 at 15:03 -0800, Martin Cooper wrote:
              > On 1/18/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

              [Sorry to reply to this rather than the original, but I never received
              it. :/]

              In Section 5 you assert that the MIME media type is "text/json" ... is
              that true? I can't find evidence of this.

              --
              ...jsled
              http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
            • Douglas Crockford
              ... My intention is to have IANA bless text/json . They first want to see an IETF RFC. The first step in creating an RFC is the submission of an Internet
              Message 6 of 17 , Jan 19, 2006
              • 0 Attachment
                > In Section 5 you assert that the MIME media type is "text/json" ... is
                > that true? I can't find evidence of this.

                My intention is to have IANA bless "text/json". They first want to see
                an IETF RFC. The first step in creating an RFC is the submission of an
                Internet Draft to IETF. That is where we are now.
              • 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 7 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 8 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 9 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 10 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.