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] Better design: "flatter is better" or "nesting is bette

[ Lists Home | Date Index | Thread Index ]

One may not know the source.  One may not know the target.   Or one may be in a
contractual situation (aka, the meta-environment constraints) that dictate that the
system only sends or receives in the context of the 'schema current on delivery
of system'.  That proves to be just a negotiation ploy though, since in principle
and in fact, it is very easy to add fields to relational system (the dominant ones
today) **as long as there are no semantic implications** (aka, running code).
 
The contract language serves to retard attempts to push the schema to
extremes that result in massive redesign and redeployment.  The closer one
gets to 'COTS' and the further one gets from "demos, prototypes and one
offs", the more one wants to be conservative.   It isn't to be a Luddite, but
to ensure that the system will actually get deployed with running, certified
and well-understood components.
 
It is generally true that flatter is better, IMO, and that when designing for large or
general markets, stay close to existing widely deployed technologies if you want
to get the standard deployed in real world systems within the buy cycle for that
market.  This is simple state transition common sense: if the next state is
dependent on the last state with absolute known probabilities (first order
markov), you can predict the future and know the past with certainty. 
Unfortunately, one seldom finds systems of that type in a dynamic environment.
Past one or two transitions, and it all becomes prophecy or intention.
 
Beggaring implementation technologies through schema design is a bad idea. 
That is too often the result of future-proofing.
 
len

From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
</Quote>
Part 2: Design your XML to be flat, with direct mappings from XML to (relational) database tables.
</Quote>
 
Sometimes one is also using XML without any notion of a specific database type or database design - for example, for a data exchange in which XML is used as an intermediary exchange format to bridge between XML vocabularies. In such cases, all one knows is the "source" vocabulary and the "target" vocabulary, not any storage mechanism on either end. So in that case, it's a choice involving other factors (such as design preference).
 




 

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

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