Minor The definition of the Scale facet as the maximum number of digits right of the decimal point implies that there may be less digits to the right and consequently more digits to the left of the decimal point (up to the value of the Precision facet), so the decimal point is allowed to float within the given Precision.
Make sure that servers do not require clients to add "padding" zeros up to Scale
Ralf and Mike will work offline and bring back with specific proposed wording.
Note in ODATA-256, Evan cautions against supporting floating point in a decimal type:
"I recommend caution with any proposal to introduce quad precision binary floating point, or even decimal floating point for that matter. I do not believe that the support is there for such types across a sufficient number of the client types that may need to interoperate with OData services."
I understood Evan's comment cautioning against introducing a DECFLOAT equivalent, which is not widely used.
OData's Edm.Decimal can be represented as BigDecimal in Java, NSDecimalNumber in Objective-C, and decimal in C#.
All of these are variable-scale, so introducing the VariableScale facet is no burden for these platforms.
And all monetary amounts in SAP Business Suite are fixed-precision and variable-scale, so if we limit Edm.Decimal to fixed-scale, we'd have to use Edm.Decimal with artificially large Precision and Scale values and tell clients via an annotation that "by the way, only half of the digits are actually used".
Unfortunately, not all implementations of Decimal will be floating precision. The best we can do is to say that the data type MAY be floating precision, but that clients SHOULD NOT assume that to be the case. We can add an annotation for specifying whether or not a particular usage of decimal is fixed or floating precision.