Re: [json] Re: Universal Binary JSON Specification
- 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:I think it is patronizing to suggest that something as simple as
> 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.)
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
(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 +-
- On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
> Stephan,For what it is worth, I also consider support for only signed values a
> 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.
-+ Tatu +-