Lists Home |
Date Index |
At 05:19 PM 4/2/2003 -0500, Chiusano Joseph wrote:
>APPROACH #1: Element-based approach
>- One long-named element that represents the entire "concept":
>APPROACH #2: Attribute-based approach
>- One short- and simply-named element that represents the most basic
>concept, with multiple attributes to "fill in the meaning":
><Amount yearType="CurrentYear" amountType="Budget"
>APPROACH #3: Combined approach
>- One more "fully-named" element with several attributes to "fill in the
><FinalEstimatedAmount yearType="CurrentYear" amountType="Budget">
The overall information model is more important than the decision whether
to use elements or attributes - a simple-valued element and an attribute
are not that different.
More important, I think, is understanding the relationship between years,
budgets, estimates, etc. For instance, the concept "current year" does not
apply to data for more than a year - do you really want it used everywhere?
Which means that it is dangerous for me to try to answer your questions.
Also, what kind of processing are you doing? Design is a kind of
optimization, as Tommie Usdin likes to point out, and until you know how
you are using the markup, it is hard to know what to optimize. I like to
mock up some data and try a bunch of queries on it.
And then there's a lot of taste. I often use an approach like your #2:
<final-estimate year="2003" type="budget">999.99</final-estimate>
But....is this a final estimate whose type is budget, or a budget whose
type is final estimate? In my models, I would think the latter:
<budget year="2003" type="finalEstimate">999.99</budget>
Whatever design you choose, create sample data and play with it - how hard
is it to create in your environment? How hard to query? How hard to write
stylesheets for? Have you captured the relationship between the different