[
Lists Home |
Date Index |
Thread Index
]
Chiusano Joseph wrote:
> Clarification: There was some stray text at the end, here are the 3
> approaches:
>
> APPROACH #1: Element-based approach
>
> - One long-named element that represents the entire "concept":
>
> <CurrentYearBudgetFinalEstimatedAmount>999.99</CurrentYearBudgetFinalEstimatedAmount>
<BudgetFinalEstimatedAmountCurrentYear />
<EstimatedAmountCurrentYearBudgetFinal />
<CurrentYearBudgetAmountFinalEstimated />
...
computerDeutsch!
But I did that for a reason. There's no obvious way to organize this
data (its almost like a bunch of metadata with no data to attach
to). In code, you can hang computerDeutsch of a verb or a process,
but not here.
> 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"
> finalIndicator="Final" estimateIndicator="Estimated">999.99</Amount>
I would prefer this but lean toward using elements, and would make
the primary thing we're talking about a budget rather than an
amount, since that's closer to the domain and seems to be what we're
caring about (I think!):
<Budget>
<Amount>999.99</Amount>
<year>CurrentYear</year>
<indicators>
<indicator>Final</indicator>
<indicator>Estimated</indicator>
</indicators>
</Budget>
In an alternate universe, I might be thinking about RDF or OWL for
this data. In this one I'd be going back to the users to find out
the thing they care about; I guessed budget, and could be wrong.
my 2 cents.
Bill de hÓra
|
