At 4:21 PM -0400 2009-07-29, noah_mendelsohn@u... wrote:
>Dave:
>
>Not sure if you saw this.  Are Roger's sample precisions on slide 28
>actually correct?  His draft says:
>
><length>3.00</length>  <!-- value is 3, precision is 2 -->
><length>3.0</length>    <!-- value is 3, precision is 1 -->
><length>3</length>       <!-- value is 3, precision is 1 -->
>
>Shouldn't that be:
>
><length>3.00</length>  <!-- value is 3, precision is 2 -->
><length>3.0</length>    <!-- value is 3, precision is 1 -->
><length>3</length>       <!-- value is 3, precision is 0 -->

Noah is correct.  But Roger got it right on the deail slide nbr 267.

I noticed that precisionDecimal doesn't seem to have made it into
the hierarchy diagram on slide 263--nor have the new duration- and
dateTime-derived datatypes.

On slide 268:  For scientific numerals CeE, the arithmetic
precision is the arithmetic precision of C minus the value of E:

   30.0 has AP 1, so the AP of 30.0e1 is 1 - 1, which is 0, not -1.

Slide 269 asserts "The precisionDecimal datatype has all the facets
of the decimal datatype, plus minScale and maxScale".  But it doesn't:
decimal has the fractionDigits facet, which plays a role for decimal
similar to that played by maxScale for precisionDecimal.  There are
historical and psychological reasons why one facet wasn't used for
both datatypes.

On slide 269:  "minScale is used to specify the largest exponent when
the precisionDecimal value is expressed in scientific notation (I do
mean 'largest,' that's not a typo)".  This is true only if the
coefficient (the numeral precedint the 'E' or 'e') is a
noDecimalPointNumeral.  But that is putting the em·pha'sis on the
wrong syl·lab'ble.  The important thing is that minScale and maxScale
put limits on the arithmetic precision.  As has already been shown,
it's possible to have many different scientificNotationNumerals that
map to the same value, hence provide the same precision.  (Similarly,
of course, for maxScale on the same slide.)

Slide 277 asserts (about anyAtomicType) "It has no facets. Thus it
cannot be used as the base type in a simpleType."  True only for
non-primitive datatypes; it *is* the base type for the primitive
datatypes.

Slide 275 notes that "1980-01-01T24:00:00-6:00... is [an example of]
how to express end-of-day".  Will that lead people to believe that
1980-01-01T24:00:00-6:00 and 1980-01-00T00:00:00-6:00 are not
identical?  '1980-01-01T24:00:00-6:00' and '1980-01-00T00:00:00-6:00'
are two lexical representations for the same value; dateTime *values*
never have an hour property with value 24.

One final thought:  You might want to point out that the two datatypes
derived from duration were created to satisfy a demand for totally
ordered durations.  (E.g., a duration of 1 month is incomparable with
a duration of 30 days--neither greater than, equal to, nor less than.)
-- 
Dave Peterson
SGMLWorks!

davep@i...