An XSD datatype for IEEE floating-point decimal

3.1 Value Space

3.2 Lexical Mapping

The lexical mapping for precisionDecimal is ·precisionDecimalLexicalMap·.  The canonical mapping is ·precisionDecimalCanonicalMap·.

3.3 Facets

The precisionDecimal datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

• whiteSpace = collapse (fixed)

Datatypes derived by restriction from precisionDecimal may also specify values for the following ·constraining facets·:

• totalDigits
• maxScale
• minScale
• pattern
• enumeration
• maxInclusive
• maxExclusive
• minInclusive
• minExclusive
• assertions

4.1 totalDigits

For precisionDecimal values with ·numericalValue· of nV and ·scale· of aP, if the value of is t, the effect of the facet is to require that (aP + 1 + log₁₀(| nV |) div 1) ≤ t, for values other than zero, NaN, and the infinities. This means in effect that values are expressible in scientific notation using at most t digits for the coefficient.

4.2 maxScale

[Definition:]   maxScale places an upper limit on the ·scale· of precisionDecimal values: if the {value} of maxScale = m, then only values with ·scale· ≤ m are retained in the value space. As a consequence, every value in the value space will have ·numericalValue· equal to i / 10ⁿ for some integers i and n, with n ≤ m. The {value} of maxScale must be an integer. If it is negative, the numeric values of the datatype are restricted to multiples of 10 (or 100, or …).

The term 'maxScale' is chosen to reflect the fact that it restricts the value space to those values that can be represented lexically in scientific notation using an integer coefficient and a scale (or negative exponent) no greater than maxScale. (It has nothing to do with the use of the term 'scale' to denote the radix or base of a notation.) Note that maxScale does not restrict the lexical space directly; a lexical representation that adds non-significant leading or trailing zero digits, or that uses a lower exponent with a non-integer coefficient is still permitted.

<simpleType name='decimal32'>
  <restriction base='precisionDecimal'>
    <totalDigits value='7'/>
    <maxScale value='95'/>
    <minScale value='-96'/>
  </restriction>
</simpleType>

4.3 minScale

[Definition:]   minScale places a lower limit on the ·scale· of precisionDecimal values. If the {value} of minScale is m, then the value space is restricted to values with ·scale· ≥ m. As a consequence, every value in the value space will have ·numericalValue· equal to i / 10ⁿ for some integers i and n, with n ≥ m.

The term minScale is chosen to reflect the fact that it restricts the value space to those values that can be represented lexically in exponential form using an integer coefficient and a scale (negative exponent) at least as large as minScale. Note that it does not restrict the lexical space directly; a lexical representation that adds additional leading zero digits, or that uses a larger exponent (and a correspondingly smaller coefficient) is still permitted.

<simpleType name='price'>
  <restriction base='precisionDecimal'>
    <totalDigits value='8'/>
    <minScale value='2'/>
    <maxScale value='2'/>
  </restriction>
</simpleType>

5.1 Implementation limits

All minimally conforming processors must support all precisionDecimal values in the value space of the otherwise unconstrained derived datatype for which is set to sixteen, maxScale to 369, and minScale to −398.

5.2 Interfacing with XPath

[XPath 2.0] does not currently require support for the precisionDecimal datatype, but conforming XPath processors are allowed to support additional primitive data types, including precisionDecimal.

For interoperability, it is recommended that XPath processors intending to support precisionDecimal as an additional primitive data type follow the recommendations in [Chamberlin 2006]. If the XPath processor used to evaluate XPath expressions supports precisionDecimal, then any precisionDecimal values in the post-schema-validation infoset should be labeled as xs:precisionDecimal in the data model instance and handled accordingly in XPath.

If the XPath processor does not support precisionDecimal, then any precisionDecimal values in the post-schema-validation infoset should be mapped into decimal, unless the ·numericalValue· is not a decimal number (for example, it is positiveInfinity, negativeInfinity, or notANumber), in which case they should be mapped to float. Whether this is done by altering the type information in the partial post-schema-validation infoset, or by altering the usual rules for mapping from a post-schema-validation infoset to an [XDM] data model instance, or by treating precisionDecimal as an unknown type which is coerced as appropriate into decimal or float by the XPath processor, is implementation-defined and out of scope for this specification.

As a consequence of the above variability, it is possible that XPath expressions that perform various kinds of type introspections will produce different results when different XPath processors are used. If the schema author wishes to ensure interoperable results, such introspections will need to be avoided.