[
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
|
