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

[Anders Rundgren <[e-mail]>]

Cool!

On 2019-08-02 13:00, Pete Cordell wrote:
> On 02/08/2019 05:39, Ulysse Carion wrote:
>> 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?
> 
> A recent solution to JCR for managing an ever growing type system is to
> allow the base type to have a format URI designator with it. So JSL
> would end up looking something like:
> 
> "amount": {
>      "type": "string",
>      "format":
> "https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value" }
> 
> The format can then be defined in separate documents.  Which layer of
> validation ensures the format is correct is an implementation detail.
> The lower layers could just ensure it's a string. Higher layers could
> ensure that the string has the correct format.
> 
> 
>> On Thu, Aug 1, 2019 at 12:54 PM Anders Rundgren
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>>
>>      On 2019-08-01 21:07, Carsten Bormann wrote:
>>       > On Aug 1, 2019, at 18:08, John Cowan <[e-mail]
>>      <mailto:[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
>>       >
> 
> 
> Pete.
>