OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Designing XML to Support Information Evolution

[ Lists Home | Date Index | Thread Index ]

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@mitre.org]

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




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS