W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2009

Re: [Bug 6601] New: SAP uses precisionDecimal with 16 and with 8 bytes.

From: Dave Peterson <davep@iit.edu>
Date: Fri, 20 Feb 2009 13:46:41 -0500
Message-Id: <a06240803c5c4a1a3dfe8@[192.168.1.101]>
To: matthias.mittelstein@sap.com, www-xml-schema-comments@w3.org
Cc: David Ezell <David_E3@VERIFONE.com>, Sandy Gao <sandygao@ca.ibm.com>, Michael Sperberg-McQueen <cmsmcq@acm.org>
At 5:41 PM +0000 2009-02-20, bugzilla@farnsworth.w3.org wrote:
>http://www.w3.org/Bugs/Public/show_bug.cgi?id=6601

>         ReportedBy: Matthias.Mittelstein@sap.com

>Dear XML Schema Working Group.
>
>With reference to the new W3C XSD 1.1 I want to write you, that we at SAP are
>using decimal floating numbers and we are interested in all standards which
>help to make xs:precisionDecimal usable and interchangeable.
>
>We are using two formats:
>*     *œDECFLOAT34*
>    This type can hold up to 34 decimal mantissa digits. The possible values
>range from 1E-6143 through 9.999999999999999999999999999999999E+6144 plus the
>corresponding negative values and zero. Such a number occupies 16 bytes.
>
>*     *œDECFLOAT16*
>    This is the smaller variant of the decimal floating-point types. It allows
>up to 16 decimal mantissa digits and values in the range from 1E-383 through
>9.999999999999999E+384 plus negative values and zero. This type needs 8 bytes.

I conclude that your "bug" report is not really reporting a bug, but rather
a user endorsement for including precisionDecimal in the 1.1 specification,
for which I sincerely thank you.

For your information, in the discussion of
    http://www.w3.org/Bugs/Public/show_bug.cgi?id=3251 ,
the desirability of introducing precisionDecimal was questioned, with the
following decision by the working group:

>The WG presented to QT on 27 June its decision/proposal to (1) mark
>precisionDecimal as a "topic at risk" when the CR is released, (2) not to
>include precisionDecimal if IEEE has not finalized its 754 revision, and (3)
>not to include precisionDecimal if in the WG's opinion there was inadequate
>implementation support for IEEE 754.  QT 
>[reluctantly?] accepted this decision.

At this point in time:

    o 	Our Candidate Recommendation is expected to be published soon but
      	has not yet been released.

    o 	We understand the 754 revision is finalized and has been published.

    o 	I'm not sure of the status of implementations.  I believe that
     	Intel has a software implementation which they claim is sufficiently
      	efficient that there is no need for a hardware implementation for
      	their chips.  I believe at least one other hardware manufacturer
      	is planning to make (or has already made?) a hardware implementation.

More or less duplicating that bug 3251 remark is, for your information, this
extraction from
    http://www.w3.org/Bugs/Public/show_bug.cgi?id=3120 :

>Proposed by the WG at the June 2007 f2f
>
>1 we retain pD in our spec
>
>2 when we enter CR, we mark pD as a feature at risk
>
>3 exit criteria for retaining pD after CR include (a) implementations in the
>context of XML Schema, (b) uptake outside of XML Schema, (c) state of the
>relevant IEEE specs


While not speaking for the WG, I suspect the WG will retain precisionDecimal
in the forthcoming Candidate Recommendation, with the promised "topic at
risk" mark unless the QT group agrees to its omission.  Assuming that the
"topic at risk" marking is present in the CR version of the spec, I hope
you will again make your feelings known with respect to the new datatype.
-- 
Dave Peterson
SGMLWorks!

davep@iit.edu
Received on Friday, 20 February 2009 18:49:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:09 UTC