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

RE: [json] Re: Reference Implementations

Expand Messages
  • 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 1 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.