From: Jim Trezzo <jrtrezzo@hotmail.com>

Date: Fri, 02 Jun 2000 03:31:17 PDT

Message-ID: <20000602103117.48515.qmail@hotmail.com>

To: www-xml-schema-comments@w3.org

Date: Fri, 02 Jun 2000 03:31:17 PDT

Message-ID: <20000602103117.48515.qmail@hotmail.com>

To: www-xml-schema-comments@w3.org

>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.comReceived on Friday, 2 June 2000 06:31:49 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 23:08:47 UTC
*