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

Re: Universal Binary JSON Specification

Expand Messages
  • rkalla123
    ... Glad to hear that. I ve been working hard on clarifying a lot of the holes that were in the original doc as I port them to the site and questions like
    Message 1 of 76 , Sep 26, 2011
    • 0 Attachment
      --- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
      > Ah, sorry, wasn't aware there was an updated spec yet. Just read it.
      > Most of my questions were resolved in the latest spec.

      Glad to hear that. I've been working hard on clarifying a lot of the holes that were in the original doc as I port them to the site and questions like yours help me realize where those are.

      > A couple more points, now based on this spec:
      >
      > 1. Will huge "H" numbers in UBJSON follow the JSON specification on
      > Numbers precisely?

      The "H" numbers are a UTF-8 string-encoded value, so anything you could have written into a numeric field in JSON can be written in there.

      So to your question specifically, yes the intent is that any string you encode as a huge number (> 64-bits) is written in adherence with the original JSON spec so it can be processed in exactly the same manner.

      > 2. It's worth noting in your specification what representation of double
      > you're supporting. I presume it's IEEE 754?

      Ah! Good catch, I need to add this to the spec. It would specifically follow the IEEE 754 double precision binary floating point format:
      http://en.wikipedia.org/wiki/Double_precision_floating-point_format#Double_precision_binary_floating-point_format

      >
      > Paul
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • 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.