[COAS-List] Re: A suggested model

["David A. Schramm" <dschramm@ipworld.com>]

Wow. This is a great model. We have implemented a very similar one although
not quite as good as this. Have you taken a look at the Boca Application
Components RFP document? UQM are one part of a larger set of business
"ValueTypes".

http://www.ipworld.com/bodtf

Our approach has been to associate "BocaAttributes" with "ValueTypes" so
that they can be replaced as needed locally.

I would certainly like to see this included in submissions to this RFP if we
ever get to issue it.

-----Original Message-----
From: Richard Dixon <R.M.Dixon@comhealth.hull.ac.uk>
To: Timothy Slidel <slidel@ebi.ac.uk>; Tim Brinson <tim@protocol.com>; Pablo
Madril <pablo.cis@epm.br>; Jeanette Breton <breton@shellus.com>; Harold
Solbrig <HRSOLBRIG@wpmail.code3.com>; Evan Wallace <ewallace@cme.nist.gov>;
Eric Neumann <eneumann@netgenics.com>; Edward Barkmeyer <edbark@nist.gov>;
David Schramm <dschramm@ipworld.com>; David Benton
<W_David_Benton@sbphrd.com>; Cory Casanave <cory-c@dataaccess.com>; Chris
Nelson <chris@dimension-edi.com>; Dr Richard Dixon
<r.m.dixon@comhealth.hull.ac.uk>
Cc: COAS <coas@cs.fiu.edu>
Date: Monday, July 20, 1998 9:21 AM
Subject: A suggested model


>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
>
>
BEGIN:VCARD
VERSION:2.1
N:Schramm;David;A.
FN:David A. Schramm
TEL;HOME;VOICE:407-359-6553
ADR;HOME:;;1956 Wrenfield Lane;Oviedo;Florida;32765;USA
LABEL;HOME;ENCODING=QUOTED-PRINTABLE:1956 Wrenfield Lane=0D=0AOviedo, Florida 32765=0D=0AUSA
URL:http://www.ipworld.com
EMAIL;PREF;INTERNET:dschramm@ipworld.com
REV:19980728T150244Z
END:VCARD