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

Re: [json] Re: Comments

Expand Messages
  • Martin Cooper
    ... It s a shame that neither the previous version nor the current version aren t versioned... ;-) -- Martin Cooper (luckily I have a copy on disk) or that the
    Message 1 of 42 , Jan 3, 2006
      On 1/3/06, Atif Aziz <atif.aziz@...> wrote:
      >
      > Jim has said it sweetly what pretty much everyone has been saying on
      > this thread (perhaps just in too many words). He's also hit my points
      > right on.
      >
      > >>
      > If comments are not mentioned in the JSON specification, a parser might
      > reasonably decline to parse the code at all.
      > <<
      >
      > This is really the heart of the problem and I think it's just been
      > proven as we discuss. The latest version of JSON.js over at
      > http://www.crockford.com/JSON/json.js does not parse and ignore
      > comments. As per message 157 [1], the parse function now uses a regular
      > expression to check for a safe character stream, which does not take
      > comments into consideration. Consequently, this...
      >
      > JSON.parse("[1,/*2,3,*/4]")
      >
      > ...does not return the array [1,4] because the commented portion is
      > considered unsafe or just not JSON.
      >
      > It's also shame that the previous version of JSON.js was not archived


      It's a shame that neither the previous version nor the current version
      aren't versioned... ;-)

      --
      Martin Cooper


      (luckily I have a copy on disk) or that the newer parse function was not
      > added in a more compatible way.
      >
      > -Atif
      >
      > [1] http://groups.yahoo.com/group/json/message/157
      >
      > -----Original Message-----
      > From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
      > Jim Washington
      > Sent: Tuesday, January 03, 2006 7:00 PM
      > To: json@yahoogroups.com
      > Subject: Re: [json] Re: Comments
      >
      > Douglas Crockford wrote:
      >
      > >>I don't want to fight too hard on this subject and I hope my
      > intentions
      > >>are not being misunderstood. It's hard to encourage decoders to
      > >>recognize and ignore comments when a future implementation will base
      > >>itself on the contents of what's written presently at
      > >>http://www.json.org Otherwise it's JSON with comments, but not pure
      > and
      > >>legal JSON and who wants two camps there? In most cases, however, a
      > new
      > >>implementation will certainly start from one of the now many JSON
      > >>bindings than go from scratch. Chances are then that most of them will
      > >>include support for comments (at least on the parsing end). It worries
      > >>me when I read things on the net along the lines of, "Yeah, some old
      > >>JSON parsers support C-style comments."
      > >>
      > >>
      > >
      > >I would like to understand your intentions. Where commentary is
      > >important, it can be encoded directly in JSON, where the outermost
      > >object resembles a COBOL IDENTIFICATION DIVISION.
      > >
      > >Why specifically do you feel the need for C-style comments?
      > >
      > >
      > It can be useful to comment-out sections of hand-coded JSON for
      > development/testing, and to have inline human-readable comments about
      > what is going on. A JSON parser should know to simply ignore these. If
      >
      > comments are not mentioned in the JSON specification, a parser might
      > reasonably decline to parse the code at all.
      >
      > Perhaps a note in the specification to allow this would suffice,
      > something like: Single-line and multi-line comments as defined in
      > ECMA-262 may be used in JSON. Contents of comments shall be ignored by
      > JSON parsers.
      >
      > -Jim Washington
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Peter Ring
      Funny thing is, YAML was designed for human consumption as much as a language-neutral serializing format. And JSON s ancestry (JavaScript) is more in the LISP
      Message 42 of 42 , Jan 5, 2006
        Funny thing is, YAML was designed for human consumption as much as a
        language-neutral serializing format. And JSON's ancestry (JavaScript) is
        more in the LISP camp than the C camp [1], i.e., designed for expressive
        power rather than bit-munging.

        Programmers spend half their time looking at code. Ergonomics matter.

        If line speed is a premium, why allow insignificant whitespace at all?

        If line speed was a premium (and human consumption irrelevant), I'd be
        using ASN.1 anyway; it is well established in the telecom world, and
        there are tons of software and utilities that will help you with the
        dirty details.

        Think of comments as something that belong to a separate namespace. The
        JSON parser should have no other business with comments than ignoring
        them. If ECMAScript syntax for comments is too loose for easy parsing,
        restrict it.

        The alternative is an informal standard for comment properties that in
        effect turns me into a carbon-based compiler and requires applications
        to share a notation for comments anyway.

        [1] http://www.crockford.com/javascript/little.html

        Kind regards
        Peter Ring

        Atif Aziz wrote:
        >>I think the real crux...
        >
        >
        > As I said, I have a sneaking hunch that the real issue stems from tying
        > JSON to YAML. With the comments debate generating some traffic, I feel
        > less daring at this point to open up the disappearing of single-quoted
        > strings gone as well as unquoted member names (at least on the decoding
        > end). I am hoping Douglas will provide some insight so everyone can
        > build a better understanding of the decisions that lead to several
        > cutbacks in the specs. I think focusing the discussion too much on
        > comments is really just avoiding a more fundamental issue. Does anyone
        > agree or am I just rambling here?
        >
        > -----Original Message-----
        > From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
        > MPCM
        > Sent: Tuesday, January 03, 2006 8:03 PM
        > To: json@yahoogroups.com
        > Subject: Re: [json] Re: Comments
        >
        > I think the real crux of this is simply, you cannot create a json
        > format string through encoding from existing data that would contain
        > comments (IIRC). It is only from people creating a json format string
        > by hand.
        >
        > It is a fairly weak argument that the standard should support
        > something that is not going to be used by the majority of people and
        > probably not in production, from an early version of the standard,
        > especially given that there are other ways get the same information
        > across using the current standard.
        >
        > If you want to block out sections of json for ease of testing, then
        > comment out the properties of the objects you are encoding, not /**/
        > in some hand edited string.
        >
        > If you want to include comments about an object, include it in a
        > property of the object.
        >
        > If you feel a need to include very detailed breakdowns, write a spec
        > for the object your passing, it shouldn't be in the data stream.
        >
        > Your suggestion on wording is really avoiding the issue of why it
        > should remain when there are other workable alternatives, and
        > suggesting that it remain part of the standard just because it was
        > once thought to be useful.
        >
        > --
        > Matt
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.