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

Re: Universal Binary JSON Specification

Expand Messages
  • rkalla123
    John, I really like the idea and agree that H is bigger and avoids confusion with the smaller numeric types. I ll add it to the spec!
    Message 1 of 76 , Sep 24, 2011
    • 0 Attachment
      John, I really like the idea and agree that 'H' is bigger and avoids confusion with the smaller numeric types.

      I'll add it to the spec!

      --- In json@yahoogroups.com, John Cowan <cowan@...> wrote:
      >
      > rkalla123 scripsit:
      >
      > > marker: N
      >
      > H for Huge might be good. We want people to encode ordinary numbers
      > using the byte/int/double formats.
      >
      > > length: required example: [N][0][0][0][121][121-bytes representing a
      > > UTF-8 string of my number]
      >
      > Yes. Of course, in this context UTF-8 and ASCII are the same thing.
      > You could save some space by using a 4-bit encoding (as proposed by
      > another poster), but that wouldn't be simple, as most languages don't
      > support that format, and those that do (like Cobol) don't usually allow
      > more than 18 digits of precision.
      >
      > > In this case the number could be a decimal or int value, but it would
      > > be up to the language parsing it to decide and return the right value.
      >
      > Right, or even a high-precision float like
      > 1.234571234809712348097123409871234098712340987E100000000000.
      >
      > --
      > MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS
      > John Cowan cowan@... http://www.ccil.org/~cowan
      >
    • 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.