[COAS-List] Re: A suggested model

[Tim Brinson <tim@protocol.com>]

Richard,

I did not get around to responding to Cory's email yet and now I'm going
to be out for a while.  I agree with the comments you made however I can
not read all of your document.  Can you send it as pdf or rtf or post it
as a CORBAmed document (the OMG will make all conversions and post them
too)?

I thought the model you showed in Orlando fits closer to what we need in
COAS.

Cory,

The biggest problem I see with the mechanism you show is that all
interoperability is lost (since only methods are shown - no state).  We
are problably trying to solve differnt problems.  The COAS team is
trying to solve a client-server problem.  The solution MUST define a
contract between the client and server so they can pass the data. 
Hopefully we can talk about this in Helsinki.  I hope you bring you BOCA
demo too.


Regards,

Tim


Richard Dixon wrote:
> 
> 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
> 
>   ------------------------------------------------------------------------
> 
>                      Name: UQandM1.doc
>    UQandM1.doc       Type: Microsoft Word Document (application/msword)
>                  Encoding: base64
begin:          vcard
fn:             Tim Brinson
n:              Brinson;Tim
org:            Protocol Systems, Inc.
adr:            8500 SW Creekside Place;;;Beaverton;Oregon;97008-7107;USA
email;internet: tim@protocol.com
title:          Systems Software Lead
tel;work:       503 526 4392
tel;fax:        503 526 4200
note:           <img src=http://aco.protocol.com/pids/tbrinson.jpg>
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard