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

RE: [json] Reference Implementations

Expand Messages
  • Atif Aziz
    I think you are contradicting yourself and proving my point. :-) ... But in some cases, you might want to be looser. There are lots of data representations out
    Message 1 of 4 , Jan 11, 2006
      I think you are contradicting yourself and proving my point. :-)

      >>
      But in some cases, you might want to be looser. There are lots of data
      representations out there. Many of them are very similar to JSON, but
      not strictly JSON. 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? Those
      implementations that wish to be anal will simply not cut it in the real
      world. I think it's wiser to allow the user of a parser to determine the
      trade-off policies rather than enforce them.

      > JSON is a strict subset of...YAML

      Can you absolutely confirm this? Is it true today? I have not seen this
      claim anywhere. In fact, I have read that it has the potential to become
      a subset if some adjustments are made to the YAML specs or otherwise if
      care is observed during encoding.

      > The latitude allowed parsers is not given to encoders.

      Yes, yes!

      - Atif

      -----Original Message-----
      From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
      Douglas Crockford
      Sent: Thursday, January 05, 2006 5:44 PM
      To: json@yahoogroups.com
      Subject: [json] Reference Implementations

      The Java implementation at JSON.org is very liberal in the texts that
      it will accept. The JavaScript implementation is very strict. A JSON
      encoder must generate strictly conforming texts. So there is the
      question, why would we want a liberal parser?

      In some cases we don't, which is why the JavaScript version is strict,
      and why JSON_checker is strict.

      But in some cases, you might want to be looser. There are lots of data
      representations out there. Many of them are very similar to JSON, but
      not strictly JSON. A loose parser makes it easy to import such data
      into a JSON system.

      It also allows JSON to be a subset of other formats. JSON is a strict
      subset of JavaScript and YAML, and perhaps other languages as well.
      Anything that accepts strict JSON text is a JSON parser.

      The latitude allowed parsers is not given to encoders.






      Yahoo! Groups Links
    • 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 2 of 4 , Jan 11, 2006
        > > 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 3 of 4 , Jan 12, 2006
          >>
          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.