W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 1999

comments on datatypes draft

From: <phillvl@uk.ibm.com>
Date: Mon, 28 Jun 1999 09:31:53 +0100
To: www-xml-schema-comments@w3.org
Message-ID: <8025679E.002ECBFE.00@d06mta05.portsmouth.uk.ibm.com>



 (reading version: http://www.w3.org/TR/xmlschema-2/  on 16th June)
  - I have dealt with defining proerties of numbers within a programming
 anguage.  It involves some suprising (to me, at least) complexities.  Two
 points occur to me when reading this- constrints on reals and problems
 with
 mixing DateTimestamp/Duration.  I can give you reference to people who
 dealt with these issues in (excruciating) detail, if you so wish.



 <CONSTRAINTS ON REALS>

 >Real has the following constraining facets:
 >              maxInclusive
 >              maxExclusive
 >              minInclusive
 >              minExclusive

 Real numbers mapped into the computer domain (implemented on real
 hardware)
 have four boundaries, as there is a set of values that are
 indistinguishable from zero.  This means that there is the concept of the
 smallest non-zero magnitude for positive and negative numbers.  I
 visualise
 this as three posible domains

 biggest negative <-------> smallest negative

 zero

 biggest positive <-------> smallest positive

 Theses considerations become important when doing comparisons - equality
 becomes a slippery concept. It may be useful to specifically declare he
 smallest positive and negative magnitudes.   We had fun with these when
 the
 customers used reals for finacial amounts (which is against the law in
 Switzerland).

 </CONSTRAINTS ON REALS>



 <MIXING DATETIMESTAMPS AND DURATIONS>

 Durations, and the elements forming durations (years, months, days, hours
 minutes, seconds) are all ZERO-based (ie the lowest value of each field is
 zero).  DateTimestamps, and their elements are not ZERO based (sort of
 ONE-based).  The prject I was on used the same textual representation for
 durations and datetimestamp and assumed some degree of equivalence.   This
 led to confusion and kludges.   Add to this that the size of a year varies
 with the year (what is the duration representation for 'a leap year'?),
 and
 the size of one month varies with the month AND the year, and you have an
 implementation nightmare.  I reckon folks ought to do temporal mathematics
 on units no greater than the day.  Conversion to days from years and vice
 versa should be provided.  Arithmetic on dateTimestamps should be avoided

 </MIXING DATETIMESTAMPS AND DURATIONS>


 This is probably old-hat to anyone with a computer science education
 (which
 I lack, so I dont know the proper terms - sorry).   As I said, they are
 minor points.  I like what you are doing.  I could wind up using it
 soon......


 Dr. Phill van Leersum                         ________________________
 ___________________                      MQSeries Development
 phillvl@ibm.uk.com                       mp206 Hursley Park,
 Tel +44-1962-815167                      Winchester,
                                    Hampshire SO21 2JN.

 In your heart you know its flat.......
Received on Monday, 28 June 1999 04:31:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:12:46 GMT