Re: [dxwg] Definition of dcat:spatialResolutionInMeters incompatible/problematic with JSON-LD (#1536)

Even aside from any disruption a re-definition of [xsd:decimal]( may cause, allowing xsd:decimal to contain an exponent may create a different problem.  I think it is important to be able to syntactically distinguish an [xsd:double]( from an xsd:decimal.  Currently, the presence of an exponent is what signals an xsd:double: 1.23E1 *must* be an xsd:double.  If an exponent were allowed in an xsd:decimal, then it isn't clear how an xsd:double could be syntactically distinguished: 1.23E1 would (presumably) conform to both datatypes.   

Possibly one could use the number of digits in the mantissa to distinguish them, because xsd:decimal is required to support 18 digits, whereas xsd:double supports a mantissa up to 2^53 = 9,007,199,254,740,992, which is 16 digits.  But if E notation is added to xsd:decimal then the digits in the exponent would probably come out of that same 18-digit budget, so you'd again be faced with not being able to syntactically distinguish them.   Furthermore, it would probably be confusing to have subtly different limits on the number of digits permitted in the mantissa and/or exponent between xsd:decimal and xsd:double.

GitHub Notification of comment by dbooth-boston
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 31 October 2022 13:53:35 UTC