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

[Pete Cordell <[e-mail]>]

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.
-- 
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------