[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: "Chris Angus" <chris.angus@b...>
• Date: Mon, 17 May 2004 17:45:40 +0100
• Importance: Normal
• In-reply-to: <000201c43c1a$212cfff0$10395381@M...>

Roger 

Looking at the four points thay you make:

<snip>
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.)

3. Flat data is good data!  Flatten out the hierarchy of your data.  It
makes the information flexible and easier to process.

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.
</snip>

I think that (1) is undoubtedly true!

I think that (2) contains some truth, but also hides some.  Using a
hierarchy as a general mechanism for representing relationships adds to
complexity, but using a relational model to model certain forms of
hierarchical structure also brings its problems.  In your example the
objects that ended up as elements under the root element were all
independent objects, their identities were separate.  Nesting elements
comes into its own where there is a strong aggregation relationship
between an element and its constituent elements - the identity of the
constituent elements being dependent on the identity of their parent
element in an invariant fashion.

(3) ties into my point about (2).

(4) Order hurts if it is there for processing convenience rather than
being an implicit property of the data.  It doesn't hurt in the case of
elements in a textual document, for example, but in your model it
carries no information.

Regards
Chris Angus

• References:
  • Designing XML to Support Information Evolution
    • From: "Roger L. Costello" <costello@m...>

• Prev by Date: Re: Designing XML to Support Information Evolution
• Next by Date: 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