Re: [Json] JSON Schema Language is nearly done: int53

[Ulysse Carion <[e-mail]>]

Within this discussion we've seen precisely why I don't think JSL should
take on directly supporting currency-related stuff. Anders describes the
W3C's payment-request spec, which uses a string, whereas Carsten describes
the multiply-by-denominator approach, which is the one that Stripe uses:
https://stripe.com/docs/api/charges/create

I think JSL is useful without currency-specific support, just as it is
useful without int64/uint64. Better to ship fewer things well, no?

On Thu, Aug 1, 2019 at 12:54 PM Anders Rundgren <
[e-mail]> wrote:

> On 2019-08-01 21:07, Carsten Bormann wrote:
> > On Aug 1, 2019, at 18:08, John Cowan <[e-mail]> wrote:
> >>
> >> Monetary amounts need to be represented as JSON strings, or your
> auditors will be down on you like a ton of bricks.
> >
> > That is only true if you naively equate the interchange data model with
> your application data model.
> >
> > There is nothing wrong with interchanging currency values as floating
> point values if you properly process them on ingestion.  Typically, you
> multiply with a common denominator (such as 100 or 1000 [egyptian pounds?,
> or US mills as in gasoline prices]) and round to the nearest integer.
>
> In this case there are standards that are interoperable with any JSON
> parser although you typically have to perform one or two additional
> operations in order to get the proper local representation:
> https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value
>
> We lucky guys(?) who build our own stuff have it natively:
>
> https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/JSONObjectReader.html#getMoney-java.lang.String-java.lang.Integer%2d
> mapped => "string"
>
> Anders
>
> >
> >> The sum of ten 0.1 values is 0.9999999999999999, not 1.0, assuming the
> float64 interpretation that essentially all JSON readers assign to JSON
> numbers.
> >
> > Right, you can’t *compute* with them as floating point values (well, you
> can, but you need to be even more careful with the rounding).
> >
> > You still can *interchange* them as floating point values if you have
> enough precision (binary32 notably doesn’t for most applications; you
> really need binary64, and you are still limited to applications that handle
> less than ~ 90 Microsofts or Apples a piece and don’t need more internal
> decimal places at the same time).
> >
> > A data definition language could contain specific support for binary
> floating point values used to encode decimal fractions; CDDL currently
> doesn’t (but support could be added using its main extension point: control
> operators).
> >
> > Grüße, Carsten
> >
>
>