Hi Dave,

See inline comments.


> 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.  


Thanks. I fixed that.

 
> 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.


I used the hierarchy chart from the 1.0 specification. The 1.1 specification doesn't have one (at least, I couldn't find one).

 
> 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.


Ah, great explanation. I added that explanation.

 
> 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.


Okay, precisionDecimal has all the facets of decimal except fractionDigits, plus minScale and maxScale.


> 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.)

I must confess that minScale and maxScale is fuzzy in my mind. Dave, would you mind checking out slide 272 and de-fuzzy it?


> 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.

I'm not seeing your point. I can't ever do this, right?

<simpleType>
    <restriction base="anyAtomicType">
       -- facets --
    </restriction>
</simpleType>


> 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.


These two are equivalent?

1980-01-01T24:00:00-6:00
1980-01-02T00:00:00-6:00
 

> 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.)


Okay, see slide 285.

Thanks Dave!

/Roger