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

Internet Draft

Expand Messages
  • Douglas Crockford
    I have submitted a draft to IETF. You can see it here: http://www.ietf.org/internet-drafts/draft-jsonorg-json-00.txt
    Message 1 of 17 , Jan 18, 2006
    View Source
    • 0 Attachment
      I have submitted a draft to IETF. You can see it here:
      http://www.ietf.org/internet-drafts/draft-jsonorg-json-00.txt
    • Robert Cerny
      This is a big step. I am very happy about it. After all an RFC will be a good weapon in XML-JSON battles :-) Thank you for all your work.
      Message 2 of 17 , Jan 18, 2006
      View Source
      • 0 Attachment
        This is a big step. I am very happy about it. After all an RFC will be
        a good weapon in XML-JSON battles :-)

        Thank you for all your work.

        --- 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
        >
      • Martin Cooper
        A couple of comments: * There is a typo in the 2nd sentence of section 6, ... [Non-text portions of this message have been removed]
        Message 3 of 17 , Jan 18, 2006
        View Source
        • 0 Attachment
          A couple of comments:

          * There is a typo in the 2nd sentence of section 6, "

          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
          >
          >
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          >
          >


          [Non-text portions of this message have been removed]
        • Martin Cooper
          Oops! Let s try that again... * In section 2.5 on numbers, there is the statement Leading zeros are not allowed as that could lead to confusion . I don t
          Message 4 of 17 , Jan 18, 2006
          View Source
          • 0 Attachment
            Oops! Let's try that again...

            * 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.

            * Section 3 talks about all parsers having to handle all valid JSON, and
            also allows implementations to not support it all. Shouldn't something be
            said about what the expected behaviour would be in these situations?

            * It's not too clear on whether all implementations must support characters
            beyond Basic Multilingual Plane. What is the intent?

            * There is a typo in the 2nd sentence of section 6, "This should only done".

            --
            Martin Cooper


            On 1/18/06, Martin Cooper <martinc@...> wrote:
            >
            > A couple of comments:
            >
            > * There is a typo in the 2nd sentence of section 6, "
            >
            > 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
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > > Yahoo! Groups Links
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            >


            [Non-text portions of this message have been removed]
          • MPCM
            I ll second Robet s comments, minus the xml battles. This is a wonderful news and a step in the right direction. I m so grateful of the day I stumbled onto
            Message 5 of 17 , Jan 18, 2006
            View Source
            • 0 Attachment
              I'll second Robet's comments, minus the xml battles.

              This is a wonderful news and a step in the right direction. I'm so
              grateful of the day I stumbled onto json. It's funny how much cleaner
              json makes web apps, compared to the old xml/iframe remote-scripting
              days.

              Douglas Crockford, thank you for all your time and effort with json.

              --
              Matthew P. C. Morley
              MPCM Technologies Inc.
            • Mark S. Miller
              ... I suggest adding to section 4 Generators: A JSON generator SHOULD output a space after a (a colon) or a (a comma). From
              Message 6 of 17 , Jan 18, 2006
              View Source
              • 0 Attachment
                Douglas Crockford wrote:
                > I have submitted a draft to IETF. You can see it here:
                > http://www.ietf.org/internet-drafts/draft-jsonorg-json-00.txt

                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. Is this really all that's necessary?

                If so, and if it would be acceptable to the JSON community, we may want to
                strengthen the above language to MUST. Otherwise, I'm happy with SHOULD.

                Does YAML need a space per se, or just whitespace there?

                Btw, the E term-tree generator, when given a term-tree using only
                JSON-compatible data, conforms to the spec + the above suggested recommendation.

                --
                Text by me above is hereby placed in the public domain

                Cheers,
                --MarkM
              • Mark S. Miller
                ... I d guess: because JSON is a subset of several other languages, and some of these other languages interpret leading zeros to indicate an octal number.
                Message 7 of 17 , Jan 18, 2006
                View Source
                • 0 Attachment
                  Martin Cooper wrote:
                  > Oops! Let's try that again...
                  >
                  > * 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.

                  I'd guess: because JSON is a subset of several other languages, and some of
                  these other languages interpret leading zeros to indicate an octal number.

                  Doug, if this is indeed the rationale, you may want to say this more explicitly.


                  > * Section 3 talks about all parsers having to handle all valid JSON, and
                  > also allows implementations to not support it all. Shouldn't something be
                  > said about what the expected behaviour would be in these situations?

                  I agree -- perhaps

                  When presented with valid JSON input, a valid parser MUST either accept it
                  or signal that the input has exceeded some implementation limit.


                  > * It's not too clear on whether all implementations must support characters
                  > beyond Basic Multilingual Plane. What is the intent?

                  E currently supports neither characters beyond the BMP, nor does it support
                  the surrogate code points with which one would encode these in UTF16. For now,
                  E supports only BMP characters.
                  <http://www.erights.org/data/common-syntax/baking-chars.html#only_bmp>

                  Therefore, I request that the JSON spec continue to allow implementations to
                  impose such limits.

                  --
                  Text by me above is hereby placed in the public domain

                  Cheers,
                  --MarkM
                • 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 8 of 17 , Jan 19, 2006
                  View Source
                  • 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 9 of 17 , Jan 19, 2006
                    View Source
                    • 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 10 of 17 , Jan 19, 2006
                      View Source
                      • 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 11 of 17 , Jan 19, 2006
                        View Source
                        • 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 12 of 17 , Jan 19, 2006
                          View Source
                          • 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 13 of 17 , Jan 19, 2006
                            View Source
                            • 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 14 of 17 , Jan 19, 2006
                              View Source
                              • 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 15 of 17 , Jan 19, 2006
                                View Source
                                • 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 16 of 17 , Jan 19, 2006
                                  View Source
                                  • 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 17 of 17 , Feb 2, 2006
                                    View Source
                                    • 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.