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

Re: Universal Binary JSON Specification

Expand Messages
  • rkalla123
    Hey Dennis, Here is where we are: I have been working on a Universal Binary JSON specification and asked the group for feedback on it. You can check the spec
    Message 1 of 76 , Sep 24 10:52 AM
    • 0 Attachment
      Hey Dennis,

      Here is where we are:

      I have been working on a Universal Binary JSON specification and asked the group for feedback on it. You can check the spec here, it isn't too long:
      https://docs.google.com/document/d/12SimAfBVcl8Fd-lr_SSBkM5B_PyEhDRfhgu1Lzvfpfw/edit?hl=en_US

      I am in the midst of formalizing it to the main site here:
      http://ubjson.org/

      The reason for (another, hopefully final) binary JSON format is:
      1. To strictly adhere to the original JSON spec, introducing no incompatibilities or binary-only data structures that could lead to incompatibilities (BSON, BJSON).
      2. To strictly follow the core "Ease of use" tenant of JSON. This means more verbosity than something like Smile, but dead-simple, singular data structure to parse and understand.

      The struct looks like this:
      [type, 1-byte char]([length/count, 4-byte int])([binary data])

      My goal is that you can understand the spec in under 10mins. I see this as a fundamental requirement of the spec.

      In the specification, I took the JavaScript "Number" data type, and broke it down into 4 sub-types that I found mapped the most immediately to discrete data types in most of the popular programming languages I checked specs on.

      Namely:
      * byte, 1-byte
      * int32, 4-byte
      * int64, 8-byte
      * double, 8-byte

      In most of the languages I checked, these had native representations and optimized performance characteristics because of the support in the platform (e.g. C#, Java, etc.)

      I think for the most part everyone has been OK up to this point, the discussion that spawned more discussion was the support for arbitrarily long Integers and Decimals numbers.

      Specifying the format is easy enough (marker followed by length of bytes followed by the bytes, big-endian), but a few folks (myself included) feel that the requirement of arbitrarily long numbers for most developers is likely in the minority at the cost of adding 2 new data constructs to the specification that *don't* have a functional representation in every language (although it does in most).

      My feeling is that adding this complexity, however small, might make the spec just that much harder to understand in under 10mins or that much harder to write a parser/generator for that it could stymie adoption and usability.

      Keeping in mind that JSON's support for arbitrarily long numbers is undefined and depends on the parser and language you are using already, so I saw no reason to try and diverge by addressing this specifically in the binary spec if it had no ancillary in the JSON spec. People using the binary spec can work around this by string-encoding their long numbers, but I appreciate that is a sub-optimal approach for a lot of folks.

      And that is the recap of where we are. Look forward to your feedback!

      Best,
      Riyad

      --- In json@yahoogroups.com, Dennis Gearon <gearond@...> wrote:
      >
      > this subject in this mail list generated more email in one week that the list
      > had in 6 months.
      >
      > I therefore stepped back, too much to follow.
      >
      > Anyone willing to send me a summary of what has gone on?
      >
      > Dennis Gearon
    • Tatu Saloranta
      ... For what it is worth, I also consider support for only signed values a good thing. -+ Tatu +-
      Message 76 of 76 , Feb 20, 2012
      • 0 Attachment
        On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
        > Stephan,
        >
        > No problem; your feedback are still very applicable and much appreciated.
        >
        > The additional view-point on the signed/unsigned issue was exactly what I was hoping for. My primary goal has always been simplicity and I know at least from the Java world, going with unsigned values would have made the impl distinctly *not* simple (and an annoying API).
        >
        > So I am glad to get some validation there that I am not alienating every other language at the cost of Java.

        For what it is worth, I also consider support for only signed values a
        good thing.

        -+ Tatu +-
      Your message has been successfully submitted and would be delivered to recipients shortly.