[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Designing XML to Support Information Evolution

• To: "Hunsberger Peter" <Peter.Hunsberger@S...>
• Subject: Re: Designing XML to Support Information Evolution
• From: "Chiusano Joseph" <chiusano_joseph@b...>
• Date: Mon, 17 May 2004 14:32:44 -0400
• Cc: "Roger L. Costello" <costello@m...>, xml-dev@l...
• Organization: Booz Allen Hamilton
• References: <1E0CC447E59C974CA5C7160D2A2854EC097E0D@S...>

"Hunsberger, Peter" wrote:
> 
> Chiusano Joseph <chiusano_joseph@b...> writes:
> 
> >
> > "Hunsberger, Peter" wrote:
> > >
> > > Roger L. Costello <costello@m...> writes:
> > >
> > > <snip>example</snip>
> > >
> > > > Here are some lessons I learned.  I believe these lessons
> > apply to
> > > > all
> > > XML information structures where you have a requirement to
> > > > evolve the information structure by moving the information (e.g.,
> > > > move
> > > the Picker around to different lots), changing the
> > > > information values (e.g., a Pickers harvests ripe grapes, thereby
> > > decreasing the value of <ripe-grapes> on a lot), and where
> > > > parallel processing of the information is desired/needed.  I don't
> > > know if these lessons apply everywhere.
> > > >
> > > > 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.)
> > >
> > > Hierarchy makes processing non-hierarchical data hard.  As
> > others have
> > > suggested, it would seem that you created a hierarchy where
> > none was
> > > needed.  You can always normalize a hierarchy in a database (eg.
> > > set/subset relational models for example), but when trying
> > to reflect
> > > a hierarchy for presentation purposes a hierarchy is the
> > best way to
> > > represent hierarchical data...  Gluing back together parent child
> > > relationships can also be inefficient!
> >
> > Of course, in some cases this can violate second and/or third
> > normal form (I forget which - it might be both...it's been a
> > long time since I studied this in my undergrad, and it's now
> > become instinct;). Using Roger's original example, let's say
> > that we have a business rule that allows a picker to belong
> > to multiple lots - perhaps we're short on pickers and need to
> > share them among multiple lots in alternating shifts. Let's
> > also say that we need to represent properties of a picker
> > - I'm a city boy so I'll take my best guess...manufacturer,
> > size, etc. Repeating the properties of a picker over and over
> > for each lot to which it is assigned violates one or both of
> > those normal forms.
> >
> 
> Umm, yes, but I'm not sure what the issue is?  Store the data
> relationally, fully normalized, represent it hierarchically.

The biggest issue right out of the gate, of course, is file size - with
XML files already being larger in size than data-only files, this
approach would take up inordinate amounts of file size and bandwidth to
transmit. That's a complete show-stopper in many instances.

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World
 
> I'm currently experimenting with having one master data relationship
> table that holds all our hierarchical data relationships in fifth normal
> form (mostly, but the one possible violation so far hasn't been needed
> -- that's another story).  By the time any portion of it makes it to the
> front end it has up to 11 levels of hierarchy that can in turn have
> many-to-many relationships with other portions of the data. Query
> performance is amazing, insert speed might be an issue in one particular
> case, but it's rare.
> 
> The key thing here is; on the XML side, hierarchy can be good.  On the
> DB side; do what comes naturally to the DB you're using...
> 
> <snip/>
> 
> -----------------------------------------------------------------
> 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>

-- 
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton

• References:
  • RE: Designing XML to Support Information Evolution
    • From: "Hunsberger, Peter" <Peter.Hunsberger@S...>

• Prev by Date: RE: Designing XML to Support Information Evolution
• Next by Date: RE: RDF storage
• Previous by thread: RE: Designing XML to Support Information Evolution
• Next by thread: RE: Designing XML to Support Information Evolution
• Index(es):
  • Date
  • Thread