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

RE: [json] Re: Comments

Expand Messages
  • Atif Aziz
    As Martin already said, JSON used to have comments. I don t know what led to the stringent opinion (perhaps from field experience) that they are so harmful as
    Message 1 of 42 , Dec 25, 2005
    • 0 Attachment
      As Martin already said, JSON used to have comments. I don't know what
      led to the stringent opinion (perhaps from field experience) that they
      are so harmful as to warrant their complete removal from the spec.
      There's no question that comments should ever be used to transmit
      anything meaningful, but who is? My only case in point was debugging and
      possibly comments for human consumption, none of which should be
      expected to survive to the production environment. If an encoder MUST
      NOT output comments then there is no need for a decoder to ever have to
      accept comments. It simply isn't legal JSON anymore if any mention of
      comments is absent from the specification. Does the following sound
      unreasonable?

      A given JSON encoder implementation MAY allow for output of comments. A
      JSON decoder SHOULD accept and ignore comments. In any event, comments
      MUST NOT be used to communicate anything meaningful that changes or
      enhances the semantics and interpretation of the data in programs
      producing and consuming JSON.

      The last remark is really a warning and you can only warn people so
      much. After that, if they still want go ahead and shoot themselves in
      the foot then so be it. :-)

      -----Original Message-----
      From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
      Douglas Crockford
      Sent: Saturday, December 24, 2005 9:32 PM
      To: json@yahoogroups.com
      Subject: [json] Re: Comments

      JSON does not have comments. A JSON encoder MUST NOT output comments.
      A JSON decoder MAY accept and ignore comments.

      Comments should never be used to transmit anything meaningful. That is
      what JSON is for.








      Yahoo! Groups Links
    • 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
      • 0 Attachment
        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.