W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > October 2022

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

From: David Booth via GitHub <sysbot+gh@w3.org>
Date: Mon, 31 Oct 2022 13:53:33 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-1297128272-1667224411-sysbot+gh@w3.org>
Even aside from any disruption a re-definition of [xsd:decimal](https://www.w3.org/TR/xmlschema-2/#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](https://www.w3.org/TR/xmlschema-2/#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 https://github.com/w3c/dxwg/issues/1536#issuecomment-1297128272 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 31 October 2022 13:53:35 UTC

This archive was generated by hypermail 2.4.0 : Monday, 31 October 2022 13:53:36 UTC