RE: more MOPs
> 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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format