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

RE: [json] Re: Comments

Expand Messages
  • Atif Aziz
    I am assuming the order of reasons list was not significant. ... This is always rather subjective. When you consider that all text formats strive for and boast
    Message 1 of 42 , Dec 27, 2005
    • 0 Attachment
      I am assuming the order of reasons list was not significant.

      > First, comments turned out to not be very useful.

      This is always rather subjective. When you consider that all text
      formats strive for and boast about human readability (heck, even XML was
      sold that way in the beginning) as well as the possibility for
      fabrication by hand, then the justification for comments follows
      naturally. There are countless examples ranging from making
      illustrations easier (comments in documentation samples or classrooms),
      testing and debugging where portions of an object graph may need to be
      temporarily muted, to simply aiding with data entry. I think YAML
      specification says it pretty nicely with a good example at the end (see
      below) and I am hoping for a similar mention in the JSON spec:

      >>
      Comments are a presentation detail and must not have any effect on the
      serialization tree or representation graph. In particular, comments are
      not associated with a particular node. The usual purpose of a comment is
      to communicate between the human maintainers of a file. A typical
      example is comments in a configuration file.
      <<

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

      >>
      Third, removing comments aligns JSON more closely with YAML, allowing
      YAML to become a JSON superset. Generally, standards tend to splinter.
      It is interesting to see these two merging.
      <<

      This is interesting, but not as much as how this has impacted JSON.
      Somehow, it seems clear to me now that this is the crux of the matter
      rather than the single topic of comments. It seems that in an effort the
      merge the two, JSON has made some compromises in its JavaScript
      heritage, which for me was the single biggest charm and genius of JSON
      besides its sheer simplicity. More than just comments, JSON has done
      away with single-quoted strings to get closer to YAML but at the cost
      making JSON even a smaller subset of JavaScript. Are the differences
      gone, though? I admit I know little about YAML (and I guess we are
      talking about YAML 1.1 here), but it seems that albeit the
      aforementioned modifications to JSON since its inception, JSON is still
      not yet YAML. According to a November 21st, 2055, entry on Ajaxian.com
      (http://shrinkster.com/adw), JSON isn't YAML unless the colon that
      separates the string and value of an object member is suffixed with at
      least a single space. For this to work then, every JSON encoder whose
      output will be fed into a YAML decoder has to be made aware of this.

      But all this begs the real question...What's the importance of the
      JavaScript heritage and interoperability left within JSON as it
      stabilizes to 1.0? It seems that somewhere along time, interoperability
      with YAML codecs became enough of a priority to warrant cutbacks in
      JSON. Perhaps it's my limited vision, but I can only see how this
      benefits YAML decoders who can now enjoy a service emitting JSON. YAML
      is far more complicated and richer than JSON at present and I can't
      imagine that anyone who buys into YAML is going to stick to the JSON
      subset even for the sake interoperability because anyone sticking to the
      lowest common denominator of the two is doing plain JSON. Period.

      >>
      As I have said before, I don't anticipate any further changes to JSON.
      I think stability is now the most important feature.
      <<

      It would have been nice to see the original JSON, as simply the
      JavaScript subset, stabilize as 1.0 and then perhaps JSON-over-YAML
      (JOY; sorry, couldn't resist :-)) as something coming out of YAML 1.x or
      a joined effort.

      >>
      Fourth, I saw examples of comments used to carry information, with an
      expectation that applications would have to have custom comment parsers
      and generators. That was not a pattern that I wanted to encourage.
      <<

      As I said, you can only warn people so much. After that, if they still
      want go shoot themselves in the foot then you can't help them anymore.
      Like the YAML spec, my only wish is that there be a mention with an
      example of use (or abuse). This, of course, implies a re-entry into the
      syntax and so requires majority consent.

      -----Original Message-----
      From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
      Douglas Crockford
      Sent: Monday, December 26, 2005 3:14 PM
      To: json@yahoogroups.com
      Subject: [json] Re: Comments

      These were the reasons for removing comments:

      First, comments turned out to not be very useful.

      Second, comments were the most difficult feature to support in JSON
      parsers. By removing comments, support for JSON in other languages
      became much easier.

      Third, removing comments aligns JSON more closely with YAML, allowing
      YAML to become a JSON superset. Generally, standards tend to splinter.
      It is interesting to see these two merging.

      Fourth, I saw examples of comments used to carry information, with an
      expectation that applications would have to have custom comment
      parsers and generators. That was not a pattern that I wanted to
      encourage.

      As I have said before, I don't anticipate any further changes to JSON.
      I think stability is now the most important feature.







      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.