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 ]

Roger L. Costello wrote:

> When I first started working on the demo I thought that the best way to
> design the XML for the Vineyard/Picker system was a "classical"  highly
> structured, hierarchical design.  In fact, this turned out to be the worst
> approach.  It was rigid, it made processing the information (e.g., moving
> the Pickers around, harvesting ripe grapes, eating, death) horribly complex,
> and I wanted to be able to process the Vineyard lots in a parallel fashion,
> which this design totally prohibited.  Here was my first design:
>  ...
> Here are some lessons I learned... 

Kian-Tat and Mike already pointed out that you are rediscovering some of 
the strengths of the relational model.  But there is more to be said, I 

This is an exercise in data modeling.  It is possible to do a good part 
of your data model without comitting to relational, object, 
entity-relational, hierarchical, or what have you.   You need to let the 
data model and what you need to do with it guide its design.

For example, adding the hierarchical information that you did adds 
information - strict, ordered data - to the data model.  The only reason 
you would want to do that would be if you needed it for some reason, but 
apparently you didn't.  So right off the bat, you made you job much 
harder, and the root cause is that you did not work out the data model 

For another example, in the world of relational databases, there are 
dependent and independent tables.  The rows of a dependent table cannot 
exist without some other table (the primary keys(s) of the dependant 
table are foreign keys into the other one).  The data modeling question 
here is whether the pickers are dependent or independent entities. 
Since they can be moved from lot to lot, clearly they are not dependent 
on lots or tracts.  Thus they are independent entities, and they had no 
business being modeled into the tracts and lots.

This conclusion has nothing to do with using hierarchies or not, or even 
xml vs relational.  The pickers are simply independent entities.  You 
could have linked them to the lots or tracts by using an xlink linkbase, 
instead of reinventing link methods as you did (not that there is 
anything wrong with doing it the way you ended up with).

So far as the tracts and lots go, you have not told us enough to assess 
whether the lots should be considered as contained by the tracts.  Here, 
the issue is whether you want to do anything with that information or 
not.  It seems as if you just need to look up the tract data for a given 
lot.  In that case, the fact that the lots are contained in the tracts 
may be irrelevant, and thus should not have been modeled - since it adds 
complexity for no returned value, as you discovered.

So with a little more work on the data model, you could have gotten 
directly to your final result, or something much like it.  If the 
purpose of the exercise (or other parts of the data model that we have 
not seen) had been different, you might have done better to put the lots 
into the tracts, but apparently not in this case.

So the lesson I am obviously pushing here is that good data modeling is 
as important as it ever was, xml or no.


Tom P


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

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