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

Re: Reference Implementations

Expand Messages
  • Douglas Crockford
    ... I have been incrementally improving the speed of the JavaScript parser in response to complaints that it was not optimal. My intention was to make it as
    Message 1 of 4 , Jan 11, 2006
    • 0 Attachment
      > > A loose parser makes it easy to import such data
      > > into a JSON system.

      > So why doesn't the same argument fly for any JSON parser implementation,
      > including the JavaScript one that used to be indeed once liberal?

      I have been incrementally improving the speed of the JavaScript parser
      in response to complaints that it was not optimal. My intention was to
      make it as fast as possible while still conforming to the standard. I
      believe that it does that.

      But it is just one possible implementation. If you want to write one
      that is bigger and slower that responds to non-JSON texts as well as
      JSON texts, you are certainly allowed to do so.

      > > JSON is a strict subset of...YAML

      > Can you absolutely confirm this? Is it true today? I have not seen
      > this claim anywhere.

      The statement is not true...yet. YAML has two productions in which
      spaces are significant where in JSON they are not. I hope they can
      resolve that soon.
    • Atif Aziz
      ... My intention was to make it as fast as possible while still conforming to the standard. But it is just one possible implementation. If you want to write
      Message 2 of 4 , Jan 12, 2006
      • 0 Attachment
        >>
        My intention was to
        make it as fast as possible while still conforming to the standard.
        But it is just one possible implementation. If you want to write one
        that is bigger and slower that responds to non-JSON texts as well as
        JSON texts, you are certainly allowed to do so.
        <<

        I completely understand and appreciate the effort. My only feedback was
        that you could have left the older, slower and fatter JavaScript version
        hanging around as a reference implementation as well for those who
        wished to work with not only a more liberal version, but an extensible
        one too. Right now, if someone just grabs a newer version off json.org
        then they're in for a bit of shock when their application suddenly
        starts breaking. You could argue why this would ever happen if their
        encoders were producing strict JSON? Well, that's precisely what
        happened to me. In my test pages for a JSON service, I allow a person to
        walk up to the service and test it from a web page using a hand-coded
        JSON request. The previous version helped here for 4 reasons. One, the
        source (a human being) or where that source obtained the JSON text from
        could not be trusted. Two, speed was not an issue. Three, comments could
        be supported. Four, if an error was encountered during parsing then the
        error contained more accurate and digestible information than what
        various JavaScript implementations may have to offer.

        In short, here's the feedback and suggestion. Archive the older version
        somewhere if you don't wish to make the new one backward compatible.
        Alternatively, if you don't mind making the reference implementation
        file a little fatter, then put both versions (the new strict and fast
        plus the old liberal and slow) in one place and let the caller decide.
        If you opt to keep them in separate files then add a version property in
        addition to JSON.copyright and JSON.license. The version value should
        reflect the revision of the implementation and not the spec.

        - Atif

        -----Original Message-----
        From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
        Douglas Crockford
        Sent: Wednesday, January 11, 2006 11:30 PM
        To: json@yahoogroups.com
        Subject: [json] Re: Reference Implementations

        > > A loose parser makes it easy to import such data
        > > into a JSON system.

        > So why doesn't the same argument fly for any JSON parser
        implementation,
        > including the JavaScript one that used to be indeed once liberal?

        I have been incrementally improving the speed of the JavaScript parser
        in response to complaints that it was not optimal. My intention was to
        make it as fast as possible while still conforming to the standard. I
        believe that it does that.

        But it is just one possible implementation. If you want to write one
        that is bigger and slower that responds to non-JSON texts as well as
        JSON texts, you are certainly allowed to do so.

        > > JSON is a strict subset of...YAML

        > Can you absolutely confirm this? Is it true today? I have not seen
        > this claim anywhere.

        The statement is not true...yet. YAML has two productions in which
        spaces are significant where in JSON they are not. I hope they can
        resolve that soon.






        Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.