[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enlightenment via avoiding the T-word
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: David Hunter <email@example.com>, firstname.lastname@example.org
- Date: Tue, 28 Aug 2001 15:11:05 -0500
And as long as the name is just a label, there
is also no confusion because no semantic is
attached. I can of course, know from the
relational description that a column value
must be of a certain type but that is intrinsic
information, so still essentially, without a
semantic. What Rick says holds true as
long as I stick to the basics of element
type definitions: labels scoped in a tree.
The slipperyness starts with saying it
has a datatype, but that is still not
worse than relational tables.
I can't escape the feeling this all works
as long as one doesn't want the schema to
tell the system that the type assigned is
an oop-object. It is just a label in a
tree of labels and it's value has a type.
If the namespace is
associated with a semantic by declaration,
it starts to fall apart. If it is done in the
processing system, it is as safe as the
processing system is sure but the rules
as Perry says, are local.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: David Hunter [mailto:email@example.com]
For the sake of this discussion and analogy, yes, I'm treating tables like
elements, and columns like child elements. And yes, my main point is that
there is no problem telling which <name> is which, because each belongs to a