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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Don Owens
    I like this. It meets Riyad s goal of keeping the spec simple, while compact in most cases, and, at the same time, meeting the need for lossless round trip
    Message 1 of 76 , Sep 28, 2011
    • 0 Attachment
      I like this. It meets Riyad's goal of keeping the spec simple, while
      compact in most cases, and, at the same time, meeting the need for lossless
      round trip encoding. I see it's been added to the spec. Thanks Riyad!

      ./don

      On Sat, Sep 24, 2011 at 11:59 AM, rkalla123 <rkalla@...> wrote:

      > **
      >
      >
      > 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
      > >
      >
      >
      >



      --
      Don Owens
      don@...


      [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.