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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Designing XML to Support Information Evolution

[ Lists Home | Date Index | Thread Index ]
  • To: "Michael Champion" <mc@xegesis.org>,"xml-dev DEV'" <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Designing XML to Support Information Evolution
  • From: "Dare Obasanjo" <dareo@microsoft.com>
  • Date: Wed, 19 May 2004 07:37:58 -0700
  • Thread-index: AcQ8I6lIjLSNIo/EQPKm8aZWCxTaPwBizf2A
  • Thread-topic: [xml-dev] Designing XML to Support Information Evolution

Hierarchical databases failed for a reason. Treating XML as a hierarchical data modelling mechanism especially in teh context of databases is inviting failure that anyone who's taken a database class in the past twenty years can warn you against. 
There are always two solutions to the problem: yours and the boss's. 


From: Michael Champion [mailto:mc@xegesis.org]
Sent: Mon 5/17/2004 8:28 AM
To: xml-dev DEV'
Subject: Re: [xml-dev] Designing XML to Support Information Evolution

On May 17, 2004, at 10:20 AM, Roger L. Costello wrote:

> 1. How you structure your information in XML has a tremendous impact 
> on the processing of the information.
> 2. Hierarchy makes processing information hard!  There exists a 
> relationship between hierarchy of information and the complexity of 
> code to process the information.  The relationship is roughly: the 
> greater the hierarchy, the greater the complexity of code to process 
> the information  (Some hierarchy is good, of course.  But the amount 
> of hierarchy that is good is probably much less than one might 
> imagine, certainly less than I thought, as described above.)
> 3. Flat data is good data!  Flatten out the hierarchy of your data.  
> It makes the information flexible and easier to process.
> 4. Order hurts!  Requiring a strict order of the information makes for 
> a brittle design.  It is only when I allowed the lots and pickers to 
> occur in any order that the flexibility and simplicity kicked in.
> Comments?  /Roger

I'm wondering if you haven't rediscovered the relational model?  (Or at 
least you've discovered the importance of "normalization" in the 
relational sense even in the XML context).  But why bother with XML at 
all (except maybe as a data interchange format) here?  Wouldn't a 
relational reporting tool be much easier than XSLT with this data 

  C.J. Date gave a speech recently 
0,289142,sid13_gci962948,00.html complaining that XML is trying to take 
over the world.  Maybe he has a point :-)  I certainly don't agree with 
all he's saying, but if you are modeling data rather than exchanging 
documents, I would think that the relational model would be the 
starting point until you run into its walls.

Clearly if flexibility is paramount, order and hierarchy are a pain, 
and there's not much gain *if* you have unique identies for everything 
and the identity is all you need to know to figure out what to do with 
the information.

  On the other hand, if *context* is important, i.e. the intepretation / 
semantics / meaning / processing paradigm of some bit of information 
depends more on where it stands in relation to other information, then 
order and hierarchy are critical.   That's where the XML "data model" 
(by which I mean "fairly deeply hierarchical labelled trees in which 
order is preserved", not the InfoSet per se) comes into its own.

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://www.oasis-open.org/mlmanage/index.php>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS