This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6601 - SAP uses precisionDecimal with 16 and with 8 bytes.
Summary: SAP uses precisionDecimal with 16 and with 8 bytes.
Status: RESOLVED WORKSFORME
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: David Ezell
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-20 17:41 UTC by Matthias Mittelstein
Modified: 2009-02-23 16:54 UTC (History)
2 users (show)

See Also:


Attachments

Description Matthias Mittelstein 2009-02-20 17:41:31 UTC
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. 


Best regards,
Matthias Mittelstein
Development Architect
TD Core AS&DM SI Internationalization & Printing
TD Core AS&DM Server Infrastructure
TD Core ABAP Server & Data Management
BST Technology Develoment Core 
BST Technology Develoment 
Business Solutions & Technology
SAP AG
Großer Grasbrook 17
20457 Hamburg
T +49 40 22707 131
T +49 6227 7 61164
F +49 6227 78 00295
mailto:matthias.mittelstein@sap.com 
www.sap.com  
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/Co-CEO), Léo Apotheker (Sprecher/Co-CEO), Werner Brandt, Erwin Gunst, Claus Heinrich, Bill McDermott, Gerhard Oswald, John Schwarz, Jim Hagemann Snabe
Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board: Hasso Plattner,
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
Comment 1 David Ezell 2009-02-23 14:56:00 UTC
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
Comment 2 Dave Peterson 2009-02-23 16:54:59 UTC
Matthias:  On the assumption that this really isn't a request to fix a problem, but rather an early response to the "at risk" not planned for the "candidate recommendation" phase, I'd like to take action to close the bug by marking it "WORKSFORME".  The WG will, of course, take note of your adoption of and encouragement for retaining precisionDecimal when reviewing the question of dropping it.  If this is acceptable to SAP, please mark this bug "CLOSED", otherwise mark it "REOPENED" and add a comment explaining why.

It's always nice to get a comment that says "good" rather than "bad".  :-)