The element `<mappedDatatype>` has a number of attributes, including `minInclusive` and `maxInclusive` to specify a lower and/or upper bound for numeric values. The ISO 20022 logical model has both of these attributes but also `totalDigits` and `fractionDigits` to define the total number of digits and the maximum number of digits after the decimal point (for ASCII encodings like XML). These two attributes are specific to XML and there is no XML attribute to define a minimal precision. The latter requires the use of a pattern, e.g. `<xs:pattern value="-?\d+\.\d{2}"/>` to require exactly two decimal places. Note that in XML, the `fractionDigits` facet constrains the value space of xs:decimal, not its lexical representation. For example, 1.23 and 1.23000 are both valid when `fractionDigits="2"`.
Whilst `totalDigits` can be mapped to `maxInclusive` (unless `maxInclusive` is explicitly provided), the maximum precision of a decimal number does not have an equivalent Orchestra attribute. The precision is quite common information and sometimes even part of a logical data element, e.g. `AvgPxPrecision(74)` and `PricePrecision(2349)` in FIX. It seems more efficient to have an attribute for fields and datatype mappings.
It is proposed to add two optional attributes `minPrecision` and `maxPrecision` to define the minimum/maximum number of "meaningful" decimal places.
Would this be better suited to be handled in an `encoding` section?
It is slightly awkward putting this on mappedDatatype, since presumably the precision restriction is actually not encoding-specific. The issue is that, unlike ISO 20022, Orchestra has _no_ "infrastructure" for actually defining and characterizing types—only giving names to totally abstract types that can be mapped to an encoding layer. ISO 20022, in contrast, defines a whole type system that builds up numbers, decimals, quantities, dates and so forth.
I would argue that the granularity of numeric data is agnostic to a specific encoding. Hence, I would agree that making it part of `<mappedDatatype>` is not the best place. The existing attributes `minInclusive` and `maxInclusive` are similar in nature, i.e. they are better applicable to the field level (which has the same attributes), avoiding the need to define the range of values for every encoding of a field.
For example, in the area of FX trading with exchange rates, it is important to know the precision from a business point of view. The encoding section can then have additional attributes to drive the actual wire formats, e.g. whether there is an actual decimal point in ASCII representations or some implied approach.
Ultimately this information belongs in the datatype hierarchy, not on specific fields, but per my previous comment, we're a long way from having what we need in Orchestra to be able to build up datatype definitions to cover requirements like this.