[COAS-List] A suggested model

["Richard Dixon" <R.M.Dixon@comhealth.hull.ac.uk>]

Okay, here's what I currently have on Units, Quantities and Measurements
(UQ+M).

Thought I'd better share it with those of you to whom I haven't already
shown it, so you can attack me on it at Helsinki.

While I'm on the subject of UQ+M, I'll address a few points that came out of
Cory's response:

-  Okay, Cory, you've convinced me that UQ+M stuff could be BOCA types once
everyone is happy with them.

- I can't see the justification for having MonthDay as a separate class.
Firstly, not having reference to the year (where known) means that day of
the year (as defined) could be wrong (in a leap year or year in which there
were 'adjustments').  Secondly, It is just as likely that Month + Year might
crop up without day as it is for Month + Day to crop up without year, so why
single this out?.  Surely, all that is needed is the Date class with an
invariant to the effect that any combination of the presence or absence of
these is possible except:  Day, Month, Year all null, and Day + Year present
+ Month null.

- Your description of Decimal includes the line: "attribute boolean
is_signed = TRUE".  This is not on the diagram.
I have a general point about the issue of 'seconds from a fixed point' as
being equivalent to the 'calendar' time.  This, as far as I can see, is not
necessarily strictly true.  On occasion, adjustments are made (be this in
minutes or seconds or fractions of seconds - or even days) to cope with the
inaccuracies of the length of the year.  Algorithms that claim to count the
exact number of milliseconds (or whatever) from a fixed date will have to be
modified every time such an adjustment is announced.  (I believe there is
one due shortly).  The 'calendar' time approach is IMHO, much safer.

Thats all for now,

Richard

UQandM1.doc