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

Re: Data Models of 63 JSON libraries

Expand Messages
  • rkalla123
    Milo this is a staggering amount of research. Thank you for compiling it all and sharing!
    Message 1 of 3 , Sep 28, 2011
    • 0 Attachment
      Milo this is a staggering amount of research. Thank you for compiling it all and sharing!

      --- In json@yahoogroups.com, Milo Sredkov <miloslav@...> wrote:
      >
      > Hello, JSON Groups Members!
      >
      > As I already mentioned, I recently finished analysing some large
      > number of JSON libraries linked from json.org about the data models
      > (or meta-models, information models, etc.) they use or assume. These
      > analyses are done for the needs of the evaluation part of a JSON data
      > model paper I am currently working on, but I think that they may be
      > useful for someone else to. Here is what I have done:
      > * All 72 links from http://json.org/ in the sections C++, C, Java,
      > Python, Haskell, JavaScript, Ruby, C#, PHP, and Lisp were included â€" I
      > picked these 10 languages because they are the most discussed ones
      > according to http://langpop.com/ .
      > * For each of these libraries, a quick analysis was performed based
      > on its source code, documentation, unit-tests or actual hands-on
      > experiments, in attempt to determine what information model is implied
      > for JSON (most often, what the of parsing JSON is).
      > * For each of these 72 libraries (minus 9, which were skipped) the
      > information was summarised and reduced to several columns in the
      > resulting table.
      >
      > Keep in mind that:
      > * The result may contain errors because the libraries were analysed in
      > about one hour on average only.
      > * The data considers only the (actual or intended) data-model, i.e.
      > how the JSON syntax is interpreted. It does not give any details about
      > the quality of the implementations (which actually varied very
      > dramatically), its usability, or even whether it works at all.
      >
      > So here is the link:
      > https://docs.google.com/spreadsheet/ccc?key=0AsfskDziXAR6dEpVUk9iT2RrODJ1amt1X0g5aWNRcEE&hl=en_GB
      >
      > If you find any problems in these entries, or have any comments please
      > write me. I apologise in advance to the authors of the mentioned
      > libraries if I have provided any incorrect information.
      >
      > Best,
      > Milo Sredkov
      >
    • Dave Gamble
      You ve inspired me to improve my Unicode support. UTF-16 surrogates now supported in cJSON. Not much I can do with embedded null characters since I /do/ use
      Message 2 of 3 , Oct 10, 2011
      • 0 Attachment
        You've inspired me to improve my Unicode support. UTF-16 surrogates now
        supported in cJSON.
        Not much I can do with embedded null characters since I /do/ use char*...
        but at least I skip them now. :)

        Dave.

        On Wed, Sep 28, 2011 at 5:18 PM, Milo Sredkov <miloslav@...> wrote:

        > **
        >
        >
        > Hello, JSON Groups Members!
        >
        > As I already mentioned, I recently finished analysing some large
        > number of JSON libraries linked from json.org about the data models
        > (or meta-models, information models, etc.) they use or assume. These
        > analyses are done for the needs of the evaluation part of a JSON data
        > model paper I am currently working on, but I think that they may be
        > useful for someone else to. Here is what I have done:
        > * All 72 links from http://json.org/ in the sections C++, C, Java,
        > Python, Haskell, JavaScript, Ruby, C#, PHP, and Lisp were included � I
        > picked these 10 languages because they are the most discussed ones
        > according to http://langpop.com/ .
        > * For each of these libraries, a quick analysis was performed based
        > on its source code, documentation, unit-tests or actual hands-on
        > experiments, in attempt to determine what information model is implied
        > for JSON (most often, what the of parsing JSON is).
        > * For each of these 72 libraries (minus 9, which were skipped) the
        > information was summarised and reduced to several columns in the
        > resulting table.
        >
        > Keep in mind that:
        > * The result may contain errors because the libraries were analysed in
        > about one hour on average only.
        > * The data considers only the (actual or intended) data-model, i.e.
        > how the JSON syntax is interpreted. It does not give any details about
        > the quality of the implementations (which actually varied very
        > dramatically), its usability, or even whether it works at all.
        >
        > So here is the link:
        >
        > https://docs.google.com/spreadsheet/ccc?key=0AsfskDziXAR6dEpVUk9iT2RrODJ1amt1X0g5aWNRcEE&hl=en_GB
        >
        > If you find any problems in these entries, or have any comments please
        > write me. I apologise in advance to the authors of the mentioned
        > libraries if I have provided any incorrect information.
        >
        > Best,
        > Milo Sredkov
        >
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.