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

RE: Designing XML to Support Information Evolution

• To: "'xml-dev@l...'" <xml-dev@l...>
• Subject: RE: Designing XML to Support Information Evolution
• From: "Bullard, Claude L (Len)" <len.bullard@i...>
• Date: Mon, 17 May 2004 12:26:42 -0500

You are encountering the problem of determining when a structure
relationship 
("has-a") is meaningful or not.    If pickers can move from lot to lot, they
are  
located on the lot, but the lot doesn't really 'have' a picker.    Order may
not  
matter and when it does, it can be  a temporal relationship as is the
'having 
a picker'.  

Is "order" the information?  Is "structure" the information?
 
Because there can be multiple users for a given chunk of information, 
this is hard to know in advance.  That is why it is better to enable 
the requestor to determine order and structure unless pushing those 
requirements to the requestor IS the message.

BTW, is the information really evolving or just changing?  IOW, is there 
some aspect of feedback to the processing that results in a new 
feature of the information, an additional element or attribute, a value 
outside a predicted range, etc.?

Is the complexity of the processing affected by using "only elements" 
versus using "only attributes" versus some combination?  Note, this 
doesn't include the surface area of things one must know to use 
either/or or in combination, but the actual code written.  How many 
times do you see an XML language with container elements that 
contain what are simply value-pairs?

<container id="someID">
  <somename>somevalue</somename>
  <somename>somevalue</somename>
  <anothername>anothervalue</anothername>
</container>

Not relational, of course.  Should it be?

len

From: Roger L. Costello [mailto:costello@m...]

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

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.

Comments?  /Roger

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