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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Tatu Saloranta
    ... I think it is patronizing to suggest that something as simple as supporting Big Integer and -Decimal would be beyond skills of competent parser writers --
    Message 1 of 76 , Sep 23, 2011
    • 0 Attachment
      On Thu, Sep 22, 2011 at 3:00 PM, Stephan Beal <sgbeal@...> wrote:
      > On Thu, Sep 22, 2011 at 11:47 PM, Milo Sredkov <miloslav@...> wrote:
      > 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
      >>
      > i would argue that a large number of _types_ of applications become
      > possible, but that a smaller _number_ of applications would be possible
      > because the complexities involved would probably not be
      > tolerable/implemented by the vast majority of the JSON libs. (Some would
      > argue that's a good thing - weeding out the market.)

      I think it is patronizing to suggest that something as simple as
      supporting Big Integer and -Decimal would be beyond skills of
      competent parser writers -- world is full of XML, YAML and BSON
      parsers, even though as formats they are vastly more complex than
      anything one could do to support basic 100% JSON information model.

      And optimizing for simplicity of format seems misguided here, as it is
      irrelevant for end users. Why? Since being binary format, no user will
      ever write or hand edit such content and all such encoded content
      comes from:

      (a) Generators that produce format, or
      (b) Converters that take JSON, produce binary alternative

      (and conversely for parsers)

      This means that simplicity for end users is mostly defined by
      simplicity of API to process content -- if it is 100% JSON compatible,
      it's same as any old JSON API, which in turn is in optimal case based
      on simplicity of logical content model which should be same for JSON
      and matching binary serialization.

      So: for end users, simplicity of underlying format is all but
      irrelevant; and as to implementors of supporting libraries (of which
      only small amount is needed anyway, couple per language), their
      interest is usually based more on value of supporting format (how
      widely format is or is expected to be used) and possible benefits of
      format (compactness, processing efficiency).

      -+ Tatu +-
    • 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.