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

RE: Designing XML to Support Information Evolution

• To: "Roger L. Costello" <costello@m...>, <xml-dev@l...>
• Subject: RE: Designing XML to Support Information Evolution
• From: "Hunsberger, Peter" <Peter.Hunsberger@S...>
• Date: Mon, 17 May 2004 13:01:12 -0500
• Thread-index: AcQ8L2V7U8ZIgcWWTwWd5kHRhhqiogAB/xYg
• Thread-topic: Designing XML to Support Information Evolution

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!

> 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

• Follow-Ups:
  • Re: Designing XML to Support Information Evolution
    • From: "Chiusano Joseph" <chiusano_joseph@b...>

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