[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:09:50 -0400
• Cc: "Roger L. Costello" <costello@m...>, xml-dev@l...
• Organization: Booz Allen Hamilton
• References: <1E0CC447E59C974CA5C7160D2A2854EC097E0C@S...>

"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.
 
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World

> > 3. Flat data is good data!  Flatten out the hierarchy of your data.
> It makes the information flexible and easier to process.
> 
> For raw data: definitely.  You touched on this indirectly, but I think
> it's worth noting that for things like SAX pipelines, deep data
> structures allow less concurrency; in a pipeline, you can only start on
> a element when you know the previous step has finished with it, deep
> hierarchies obviously slow that event down.  When we need a hierarchy we
> have a metadata model that maps the hierarchy, the data that gets mapped
> to this structure is flat.
> 
> > 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
> 
> -----------------------------------------------------------------
> 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