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

Re: Universal Binary JSON Specification

Expand Messages
  • rkalla123
    Milo, Agreed on how the format must be presented on the website, I am keeping your post bookmarked as a TODO list as I work on formalizing the spec on the
    Message 1 of 76 , Sep 23, 2011

      Agreed on how the format must be presented on the website, I am keeping your post bookmarked as a TODO list as I work on formalizing the spec on the website.

      The details on the number formats gave me a little miniature stroke, I need some more time to digest that ;)


      --- In json@yahoogroups.com, Milo Sredkov <miloslav@...> wrote:
      > Hello Riyad, Stephan, Don, Tatu, and all group members,
      > I recently analysed about 70 of the libraries linked from json.org (almost
      > all listed in the C++, C, Java, Python, Haskell, JavaScript, Ruby, C#, PHP,
      > and Lisp sections) and would like to share some opinions about the presented
      > specification, and also about some of the topics that rose in the discussion
      > so far.
      > First, I'm really happy to see people trying to do cool things in favour of
      > the JSON community â€" a simple and efficient binary JSON representation is
      > for sure a cool thing from which we can all benefit. Although you will
      > probably need to do more work in order to show everyone that this format is
      > *the one*, initiating a discussion is probably the right thing to do.
      > IMHO there are two things, already pointed out by the others, which I find
      > disturbing. First, as other binary JSON representations are already present,
      > you need to position the Universal Binary JSON format very clearly compared
      > to the alternatives, especially to the aforementioned Smile, which seems to
      > solve very similar goals. It's obvious that the proposed format is simple,
      > and that this may be its unique strength, but unless you clearly
      > (quantitatively) show exactly how simpler it is, people will not hurry to
      > adopt it. What's more, as there already exist several binary JSON formats,
      > failure to persuade the community that the new one is superior not only will
      > make your effort unsuccessful, it will also worsen things by introducing
      > additional discrepancy.
      > The second issue is about the numbers. This one is actually an issue of JSON
      > itself, and more specifically, the fact that JSON is specified only at the
      > syntax level and there lacks a commonly accepted data-model (or meta-model,
      > information model, etc.) specifying the set of information that can be
      > encoded in JSON. The JSON specification just states how numbers are encoded.
      > It does not state whether 10, 10.0, or 1E1 are different numbers, neither
      > does it say how large the numbers can be, or whether the concrete way in
      > which they are written is important. From this, in the libraries for the 10
      > programming languages I mentioned, there are huge variations in the
      > supported range formats. Some distinguish integers from floats, others
      > don't, some expose the concrete string in which the number was encoded,
      > others don't, and so on. Most importantly, the supported ranges vary for
      > each library, starting from 30bit (not 32) signed integers to unlimited
      > decimal numbers.
      > Having said that, although you are not the one who is responsible for the
      > situation, you should really treat the numbers very carefully. In my
      > opinion, thinking language neutrally, there are only 2 strategies (or data
      > models) that make sense. The first, which many people imply because of
      > JSON's origin, is to assume JavaScript semantics, that is, in this case that
      > numbers are 64bit IEEE 754 floating point numbers. This makes things really
      > simple, but is not suitable for applications where rounding errors are not
      > tolerable, e.g. storing monetary values. The second approach is to assume
      > (unlimited) decimal numbers â€" tools are free to have their limitations, but
      > any real number that can be encoded as a finite decimal fraction is
      > supported by the specification, and tools try their best to deliver it
      > without any loss of precision. This approach makes most sense to me â€" it
      > allows JSON to be used for a large number of applications. However, it
      > contrasts to the JSON's idea of being the intersection of the modern
      > programming languages, not the union. Adopting it means the following:
      > * There is no reason for having big integers at the format level, only
      > decimal numbers should be enough (1.0 == 1 == 1.00e0)
      > * The semantics and precision guarantees of the "double" encoding should be
      > very carefully and strictly defined. Keep in mind, that even simple decimal
      > values like 1.7 cannot be expressed exactly in binary IEEE 754 floats
      > * +0, -0, 0.0e0, are the same value, and according to the rule of picking
      > the smallest suitable type, they should be encoded as "byte"
      > * "BigDecimal should probably be renamed to something like BigFloat" may
      > not be a good idea â€" first, parsing binary floats with arbitrary precision
      > is not something easy and commonly supported, and secondly, decimal
      > precision guaranties suits better most large precision applications.
      > * The encoding of decimal numbers should be very carefully specified.
      > Btw, I hope that in few days I will publish the exact results of the
      > analysis I mentioned, which is actually a by-product of an effort to define
      > a strict data model for JSON.
      > Best,
      > Milo Sredkov
    • 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
        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.