OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Enlightenment via avoiding the T-word

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

-----Original Message-----
From: David Hunter [mailto:david.hunter@mobileq.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
parent element.