>  No, I think:
>  
>  data - context = RDBMS
>  
>  where the meta data and the data are separated (and the meta 
>  data is static)

Separated how?   Both the meta and the data are in the same system.

>  Is there not obvious context between the <name> elements in 
>  the following
>  XML?

[doc snipped]

>  We have:
>  Invoice>BillingAddress>Contact>name = Bill Payor
>  Invoice>ShipToAddress>Receiver>name = Joe Receiver
>  Invoice>PurchasedBy>name = John Purchaser

The same sorts of navigations can be performed in a relational database that
support PK-FK explicit definitions. The only difference is that in XML such
navigation paths are fixed (by hierarchy of structure), whereas in a
relationa database there is no 'head' node.

>  If I gave you the data: Diana, you would not know what it means, and
>  therefore could not interpret how to process it, but if I gave you:
>  
>  Owen>Wife>name = Diana then you have the context you need to 
>  process the
>  data, because it is now *information*

If I only spoke Swahili, I wouldn't have a clue.  You're assuming that the
receiver (let's assume it's not me) possesses the contextual backround of an
English speaker. 

Even within the English language, there are ambiguities.  Take this example:

<Measurement> 
	<length type="in."> 36</length>
	<width type="in."> 36</width>
</Measure> 

Here you might assume that "in." is an abbreviation for "inches". But now
comes along:

<Measurement> 
	<length type="out."> 42</length>
	<width type="in."> 69</width>
</Measure> 

Whoops! It turned out that (maybe) "in." referred to the "inner" dimension
of the thing being measured! The units of measure are evidently implicit
(and what are they, hmmm?).

These sorts of ambiguities arise everywhere. You can make assumptions about
the meaning of metatags, but there will be many situations where such
assumptions are based on, at best, educated guesses.

>  
>  Do not confuse data model (logical) with data base 
>  (physical), which I think
>  may be the disconnect.  

I'm sorry, but reread the definition I gave previously: both sources I based
it on included the word "physical" in the description. Check technopedia.com
and foldoc.org.  

I'll grant you that there are various interpretations of the term "data
model".  There's the conceptual (or user's data model) that for the case of
XML would be described by the Infoset.  But the more proper definition
refers to a physical representation of data.

> So many people use XML for transfer, 
>  and then shred
>  or CLOB it into their existing *data* bases, without regard 
>  to the fact that
>  the XML *could* be formatted in such as way 
>  (logical=physical) as to require
>  minimal translation, if the format was more information rich, and less
>  transfer brief.

But often the physical model that's useful for XML documents is not useful
to the application.  Are you suggesting that databased applications should
conform their internal data structures to the underlying relational
databases?

>  I guess I will go on to say that Objects (and object 
>  technology in general)
>  has hit a wall, or has failed us.  

I would say it has its limits.  I'm on record as saying the data model
should be seperated from the processing model, and that objects convolute
the two, and therefore make internal data manipulation and translation more
complex than is necessary.  XML and XML schemas (small s) have some
potential to address such concerns, or at least be sympathetic to them. 


>  I say this because we are 
>  still trying to
>  define things (like processable code) a-priori, without regard to the
>  behaviour that someone later might wish. 

You'll find a lot of agreement here that such is a problem with
object-orientation.  

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>