[
Lists Home |
Date Index |
Thread Index
]
Roger,
Hope about an alternate view?
One that is Business-Centric!
Principle #1 - Making the XML match the business problem
you are trying to solve. XML is self-documenting - therefore
please use it to explain what is going on, rather than hide
what is happening.
Principle #2 - machine time is much cheaper than people time.
Unless you are processing millions of these things a
second - optimize for people time first.
Principle #3 - If people find your angle-brackets hard to grok,
they are less inclined to use it. Some may view this as
job security - but it continues to dog XML adoption.
Making the XML match the business problem you are trying to solve.
I guess this is the difference between asking a business analyst
for the answer or an <angle_bracket> engineer ; -)
So given your task I would prefer something like:
<grape_harvesting>
<pickers>
<picker name="Fred" skill="3" years_experience="3"/>
<picker name="John" skill="4" years_experience="0"/>
</pickers>
<farm name="Hill Top">
<lots>
<lot ID="1" location="X,Y"/>
</lots>
<harvest season="2004">
<assignments>
<today>
<picker name="Fred" lot="1"/>
<picker name="John" lot="1"/>
</today>
</assignments>
<history>
<week Jdate="254">
<activity picker="Fred" lot="1" grapes="25lbs"
start="8:00am" time="4hrs"/>
<activity picker="John" lot="1" grapes="25lbs"
start="8:00am" time="5hrs"/>
</week>
</history>
</harvest>
</farm>
</grape_harvesting>
Where the business goals aare tracking the grape harvesting, assigning
staff on a daily basis,
and then tracking each picker to assess pay (based on results) and
overall performance
(eg pickers may be operating on more difficult lots to pick on), etc.
Once we grok what
the business needs are - much easier to design optimal XML. Too often
people start the
other way around and that's when the XML / business syste,, interface
gets really ugly!
DW
|
