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

Re: Universal Binary JSON Specification

Expand Messages
  • rkalla123
    Paul, Thank you for the feedback, my comments are inlined below. ... Yes exactly. Elements can have a byte length of 0 or more, negative numbers would cause
    Message 1 of 76 , Sep 26, 2011
    • 0 Attachment
      Paul,

      Thank you for the feedback, my comments are inlined below.

      --- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
      > > [1-byte ASCII marker indicating type][4-byte int32 size][binary data]
      >
      >
      > 1. I presume the only reason for making this a signed number is to just
      > be consistent with the processing binary representations of numbers?

      Yes exactly. Elements can have a byte length of 0 or more, negative numbers would cause headaches for parsers (e.g. "What does a length of -13 mean?")

      > 2. I presume the size is strictly the number of bytes/octets; not the
      > number of UTF-8 characters in a string, for example.

      Correct, it is the byte length of the UTF-8 string. I clarified in the updated spec on the website that this *is not* the character count, http://ubjson.org

      > > The only difference from JSON being that "Number" is broken out into:
      > > int32, int64 and double types for the purposes of making parsing of
      > > the values as efficient as possible in Java, C, C#, Python, Erlang,
      > > PHP and any other language that has multiple concepts of the different
      > > types of numbers it can represent.
      >
      >
      > There are numbers that JSON can represent that cannot be represented
      > (only roughly approximated) by your selected numerical representations.
      > Instead of twos-complement and IEEE 754 (which I think you are
      > implying), perhaps consider BCD with an explicit decimal position. This
      > would support any possible number representation that JSON can with its
      > Number type, and we can also avoid endian bike shedding while we're at
      > it.

      If you are referring to > 64-bit, arbitrarily long numbers that was solved with the addition of a string-encoded numeric type to make then portable and manageable on all platforms that needed them (also no better or worse than what JSON would offer as far as performance).

      As for numbers <= 64-bits in length though, if that is what you were referring to would you mind clarifying?

      Best,
      Riyad
    • 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.