Re: Universal Binary JSON Specification
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 email@example.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
> 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
> 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.
> Milo Sredkov
- On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
> Stephan,For what it is worth, I also consider support for only signed values a
> 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.
-+ Tatu +-