[
Lists Home |
Date Index |
Thread Index
]
Naming is often a matter of readability, addressability,
and composability.
1. Readability: Does a human read this? Is there a legacy name they
are familiar with and expect to see. Don't Shock The Monkey.
2. Addressability: Will the suconcepts/topics vary and will they
be the variants be used to identify the superconcept to the machine?
Like URI/URL naming or any other multi-morph name, if it varies,
it has to vary under the topic (whatever you use in the element)
3. Composability: can the human or machine that has to create
this element/attribute combination logically sort out these
multi-morphs and combine them efficiently from perhaps, the
orignal source, say a database table?
IME, approach number 2 wins most of the time. Since that
conflicts with your experience, I'll be interested in the
counter-response.
len
-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Wednesday, April 02, 2003 4:12 PM
To: xml-dev@lists.xml.org
Subject: [xml-dev] 3 possible approaches for representing concepts
I would like to please solicit some quick feedback if possible regarding
an approach to using elements and/or attributes to represent concepts in
an XML document. I am having a "healthy debate" with a "colleague" on
how much "meaning" should be placed into an element name, and how much
(if any) should be "filled out" by attributes.
Below I've identified 3 approaches for representing a concept called
(pipes separate the "subconcepts"):
CurrentYear|Budget|Final|Estimated|Amount
A "related" element in the same XML document might be called (note only
the first subconcept has been changed):
PriorYear|Budget|Final|Estimated|Amount
I am interested in feedback regarding which of the 3 approaches below
folks have used (whether it was an XML schema or DTD), and also which
may be best for both constructing an XML document based on database
contents, and parsing an XML document and committing the contents to a
database. I am aware of all the "issues" surrounding use of attributes
(order not enforced, cannot have duplicate names, namespace handling,
etc.), so my inquiry is outside of those. My personal experience tells
me that approach #2 (attribute-based approach) is not best practice, and
there *may* be some issues with tools.
And here they are:
APPROACH #1: Element-based approach
- One long-named element that represents the entire "concept":
<CurrentYearBudgetFinalEstimatedAmount>999.99</CurrentYearBudgetFinalEstimatedAmount>
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>
APPROACH #3: Combined approach
- One more "fully-named" element with several attributes to "fill in the
meaning":
<FinalEstimatedAmount yearType="CurrentYear" amountType="Budget">
999.99</FinalEstimatedAmount>
<CurrentYearBudgetFinalEstimatedAmount
core:amountTypeID="Federal">999</core:EstimatedUnobligatedAmount>
Thanks in advance for your feedback.
Joe Chiusano
Booz | Allen | Hamilton
|
