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

Reference Implementations

Expand Messages
  • Douglas Crockford
    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
    Message 1 of 4 , Jan 5, 2006
    • 0 Attachment
      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.
    • 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 2 of 4 , Jan 11, 2006
      • 0 Attachment
        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 3 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 4 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.