Fwd: Re: comments on XML Schema part 2: Precision/Scale

>From: "Martin J. Duerst" <duerst@w3.org>
>To: "Jim Trezzo" <jrtrezzo@hotmail.com>
>CC: w3c-xml-schema-ig@w3.org
>Subject: Re: comments on XML Schema part 2: Precision/Scale
>Date: Fri, 02 Jun 2000 18:40:10 +0900
>
>Hello Jim,
>
>Please forward this mail to the comments list for bookkeeping
>if desirable.
>
>At 00/06/01 06:44 -0700, Jim Trezzo wrote:
>>Martin,
>>
>>today we began reviewing your comments to the XML Schema, Part 2, wrt
>>precision/scale.  The work group requested some additional clarification
>>on your input.
>
>Thanks for contacting me. The main motivation for my proposal
>was to make the scale and precision properties regular and
>well structured. But I didn't fully work out my proposal.
>The proposal in the spec is somewhat slanted, and that makes
>me quite a bit uneasy. As an example:
>
>Precision    Scale     Examples
>5            0         12345
>5            1         12345 1234.5
>5            2         12345 1234.5 123.45
>5            3         12345 1234.5 123.45 12.345
>5            4         12345 1234.5 123.45 12.345 1.2345
>5            5         12345 1234.5 123.45 12.345 1.2345 .12345
>5            absent    12345 1234.5 123.45 12.345 1.2345 .12345
>
>I hope the above examples are correct; if not, please correct me.
>
>This looks quite out of balance to me, and I have real difficulties
>imagining the application domain or use case, or the underlying
>representation one would chose for this.
>
>To fix this, I wanted to make sure that precision and scale
>are orthogonal, and that the whole thing corresponds more
>to use cases and representations I know of. Unfortunately,
>my first proposal was incomplete.
>
>What was missing was that precision has to be changed from its
>current definition as 'number of digits' to 'number of significant
>digits'.
>
>>Your suggestions ask for a change in 'scale' to allow for Integer values
>>as opposed to the current restriction of nonNegativeInteger.  If someone
>>specifies 'scale' to be -3 for a datatype, would you expect the occurrence
>>of '5' in an XML instance to represent 5000?
>>
>>The other interpretation of your suggestion is that use of a datatype with
>>'scale' of -3 is as follows:
>>
>>The XML instance of 5000 is the value 5000 and that occurrences of 5321,
>>5973, etc. would not be valid.  Essentially by specifying scale to be -3,
>>you have restricted the value of this datatype to be multiples of one 
>>thousand.
>
>As for the representation, there are indeed two choices:
>
>One that represents just the significant digits and one that
>writes out a full decimal number. I would leave the choice to
>the WG, but I guess that most probably to use the usual decimal
>number representation would be best; this avoids differences
>between the case where scale is undefined and the case where
>scale is defined.
>
>The above example would now look like
>Precision    Scale     Examples
>...          ...       ...
>5            -6        12345000000
>5            -5        1234500000
>5            -4        123450000
>5            -3        12345000
>5            -2        1234500
>5            -1        123450
>5            0         12345
>5            1         1234.5
>5            2         123.45
>5            3         12.345
>5            4         1.2345
>5            5         .12345
>5            6        .012345
>...          ...       ...
>5            absent    all of the above
>
>On the passing, I found a small problem that should be fixed
>anyway: precision is currently defined as:
>
> >>>>
>    A member of a value space is schema-valid with respect to precision if:
>
>    1.the number of decimal digits in the value is less than or equal to
>{value};
><<<<
>
>Now the lexical representation has decimal digits, but for me it is unclear
>whether the value of decimal has decimal digits, and what exactly they
>are. The definition of decimal:
>
> >>>>
>    [Definition:]  decimal represents arbitrary precision decimal numbers.
>    The value space of decimal consists of the values i * 10^n, where i and
>    n are integers, with n being known as the scale of the value space.
><<<<
>
>doesn't give any indication of what the number of decimal digits of
>the value is. It may be the number of significant digits, it may be
>the number of digits needed to represent i (I think that's the same),
>or it may be the number of lexical representation (which is currently
>not well defined, because irrelevant zeroes are allowed), or the minimum
>number of digits in all possible lexical representations (which is more
>or less what I have assumed above).
>
>Also, in the formula above, if n=scale=3, then this means values
>of the form 5000, 6000,..., so I think this should be corrected to
>i * 10^(-n) to match the definition of scale elsewhere.
>
>Another problem is that saying 'n is the scale' doesn't really work
>in the case of types that don't have the scale facet fixed; there
>seems to be a confusion between the scale of the number itself
>and the scale constraining facet in this case.
>
>
>>Please let us know what you meant here.  I also should let you know that
>>the current sense of the WG was not supportive of this change. If you have
>>a more compelling use case for this feature, please let us know so we may
>>consider that as well.
>
>I have given the example of financial data. Many balance sheets are
>written in thousands of dollars, an overview of the US budget is
>probably in millions or even billions of dollars. I don't think
>anybody has difficulties imagining this, but if you want to have
>a look at an example, please check e.g.
>http://www.ibm.com/annualreport/1999/report/csoe.html.
>
>What is more, you should be aware of the fact that some countries have
>currencies with only one unit (not dollars and cents as in the US).
>In some cases, the currency has been considerably devaluated over time,
>and lower digits are not used anymore. A typical example is the
>Lira in Italy. I can give you some examples on web sites if you
>think it's needed.
>
>Various measurements in Physics also can go far in scale to
>either side, while being quite reasonable in precision.
>
>
>Hope this helps,    Martin.
>

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Received on Friday, 2 June 2000 06:31:49 UTC