Re: Fraud Number 3: U-Gene

Cimode wrote:
> First, I am aware of Date's definition and I do not quite feel
> confortable with it because it focuses too much on structural
> definition and not enough on the characteristics values extraction from
> domains. Neverthless, Date's is logically correct: it's a matter of
> perspective.
>

Well that's reassuring; although you're right on the potential for overemphasising structure.

> I also believe some of Date's definition can also lead to
> confusion..For instance, Date's definition relvar could lead to
> confusion with the definition of an attribute. (both have a name, a
> data type and may hold a value in time). If we define, attribute and
> relvar alike, one take the risk of confusing them...
>

But I'm not sure how you could confuse an attribute with a relvar. A relvar is a variable and can indicate different values at different times. A relation value is value; like an integer value, it never changes. You can change which relation value a relvar indicates, but you can't change the relation value itself. So, you can't "change" an attribute.

[ snippage ]

> For instance, Pascal defines a data type as the combination of:
>
> --> a name
> --> set of constraints regulating *extraction* of values from a
> specific domain
> --> set of operators applyable in specifc context

Which marks a difference between domains and types that I don't currently hold; the definition of a type as a set of acceptable values (or equations defining a set of acceptable values) plus a set of operators over those values seems simpler and no less expressive. Received on Tue Jun 20 2006 - 12:23:06 CEST