search

raml-org / raml-spec

RAML Specification
http://raml.org
3.87k stars 858 forks source link

add decimal numeric format #508

Open amammes opened 8 years ago

amammes commented 8 years ago

None of the current numeric formats can represent currency values properly. Integers can't represent cents and IEEE754 float/double have rounding errors, so they are not suitable for financial applications.

XML has xsd:decimal which is suitable. http://www.w3.org/TR/xmlschema11-2/#decimal

These are the xsd:decimal constraints. totalDigits fractionDigits pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions

I am currently using a string with a regexp but I think a native type would be much more elegant, especially if it is native in XML and most SQL implementations.

sichvoge commented 8 years ago

@amammes coming back to your request; how about using:

type: number
multipleOf: 0.01

I have seen that in JSON schema quite often. I am not sure we should follow adding all the facets that are in XML since it will be difficult to present them in JSON schema. How would tooling generate an equivalent in both?

amammes commented 8 years ago

Whoever is using a float to store a financial value is really asking for trouble. That is absolutely forbidden due to the way IEEE754 represents numbers internally. It simply cannot represent all numbers without losing precision.

freddrake commented 8 years ago

Right. Financial values have to be represented as strings in JSON, and converted to appropriate types by the application.

gaganis commented 5 years ago

We have faced this issue of attempting to transfer monetary data. We are using https://github.com/mulesoft-labs/raml-generator to create our clients.

In our case we have handled this by updating the generator to create BigDecimal which are then serialized as the string representation, of the java BigDecimal.

You can see our rational here https://github.com/mulesoft-labs/raml-java-client-generator/pull/42

We believe this is a reasonable way to handle this usecase. Currently raml-spec only specifies fixed precision numbers and a format MUST be selected.

Would it be possible to amend the spec so format is optional and arbitrary precision numbers would be expected if format is ommited?