[COAS-List] RE: A suggested model

[Cory Casanave <cory-c@dataaccess.com>]

Tim,
We are trying to solve the same problem - I know the "IDL" part of the
document is lacking.  Attributes in CDL are assumed to have state unless
specified otherwise, that should be reflected in the "value" types
defined, the syntax for this is not yet stable so it is not currently
produced.
Cory

	----------
	From:  Tim Brinson[SMTP:tim@protocol.com]
	Sent:  Monday, July 20, 1998 12:58 PM
	To:  Richard Dixon
	Cc:  Timothy Slidel; Pablo Madril; Jeanette Breton; Harold
Solbrig; Evan Wallace; Eric Neumann; Edward Barkmeyer; David Schramm;
David Benton; Cory Casanave; Chris Nelson; COAS
	Subject:  Re: A suggested model

	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<<File: vcard.vcf>>