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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Stephan Beal
    ... Absolutely. That s a literal interpretation (but not a sane one, i admit!). ... Interpreted that way, all implementations must implement
    Message 1 of 76 , Sep 22, 2011
    • 0 Attachment
      On Fri, Sep 23, 2011 at 2:28 AM, Tatu Saloranta <tsaloranta@...>wrote:

      > **
      > You have a very interesting way of reading specifications -- when spec
      > does not limit magnitude or precision, you claim it's fine to use
      > whatever size: by that logic, it'd be fine to only support values 0
      > and 1. Or just 0.
      >

      Absolutely. That's a literal interpretation (but not a sane one, i admit!).


      > Put another way: if you only support a subset, then format can not
      > represent all valid JSON documents, and thus is just a subset, not a
      > 1-to-1 equivalent.
      >

      Interpreted that way, all implementations must implement arbitrary-precision
      numbers. (And that interpretation's also valid for a grammar which doesn't
      specify a max length.)

      So we're screwed either way ;).

      As to not all environments having BigDecimal/BigInteger, that's a red
      > herring -- as long as you define exact format of data, any environment
      > can support it, even if by just exposing array of bytes.
      >

      "Support it", sure, but not using a 1-to-1 type mapping as is generally
      possible with other types.

      --
      ----- stephan beal
      http://wanderinghorse.net/home/stephan/


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