1.1 Requirements (was: Fwd: [technical niceties] Re: status report from XML Schema )WG

These comments on our requirements for XML Schema 1.1 should go
into the record.  -CMSMcQ

>X-Sender: 10003479@pop.iamdigex.net
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>Date: Tue, 04 Feb 2003 11:12:32 -0500
>To: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
>From: Al Gilman <asgilman@iamdigex.net>
>Subject: [technical niceties] Re: status report from XML Schema WG
>
>
>[please pass to the appropritate personnel working on these requirements]
>
>At 06:11 PM 2003-02-03, you wrote:
>
>>2 Requirements for XML Schema 1.1.
>>
>>
>>   - definition of a 'precision-decimal' numeric type which allows
>>     users to keep track of the precision of their numeric values; the
>>     current decimal type, by contrast, has a value space consisting
>>     only of exact numeric values.  Some users have found this
>>     confusing and frustrating.
>
>Yes, the existing theory is at variance with the usage in most quantitative
>computation.
>
>>[snip 2]
>>   - define fully-ordered duration types; the current duration type
>>     is only prtially ordered, because 60 days (for example) may be
>>     less than or greater than two months in the Gregorian calendar,
>>     and the type accurately reflects this fact.  The fully-ordered
>>     types proposed would involve either units of months or greater, or
>>     units of days and smaller, but not both.  The current expectation
>>     is to ignore the occurrence of leap seconds and say that for
>>     purposes of this type, a minute always contains exactly sixty
>>     seconds.
>
>The solution to the first of these should be taken as the solution to the
>second.  If one treats durations denoted in months and/or years as of known
>precision rather than of absolute precision, the precision of differences
>and hence the domain of ambiguous order is well handled.
>
>True durations should all be in units that are known exact ratios w.r.t. the
>atomic second.  Point, paragraph.  An apartment lease for one year is *not*
>of a set duration but for a set _epoch_ marked by two identified events:
>from now until next year, same date.  For genuine durations where 
>comparison in
>duration terms matters, stick to physical time, measured in atomic seconds,
>denoted in convenient multiples and sub-multiples of the atomic second..
>Forget UTC and astronomical time for this purpose.  Bury the difference in
>the finite-precision tolerance calculus as used for
>"known-precision-fraction" types above.
>
>It's not just leap seconds.  There are whole leap days in years.  The
>average year is 365.25 days but no individual year is even close.
>
>Unless a demonstrated use can be found for a time scale where the first
>differences need to be totally ordered but all the Field properties of
>class:atomicTime do not pertain, stick to the above.
>
>atomicTime is a class of durations rooted in the atomic second, and
>calendarTime is an evolving[1] system of quasi-regular epoch denotations
>which mediates between atomicTime and astronomical events.
>
>The calendar does not guarantee the cardinal equivalence of different epochs
>of like category (different years, different months, different days).
>
>Al
>
>[1]  The mapping between physical time and calendar time is no more certain
>into the future than is the mapping between local time and UTC.  Compare with
>
>  http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2002Dec/thread.html#22

Received on Tuesday, 4 February 2003 21:10:10 UTC