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.

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".