[
Lists Home |
Date Index |
Thread Index
]
Hi Joe:
This is an age-old discussion. I would like to point you
to Robin Covers website:
http://www.oasis-open.org/cover/elementsAndAttrs.html
This has some good reading and some good opinions.
Betty
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Betty Harvey | Phone: 410-787-9200 FAX: 9830
Electronic Commerce Connection, Inc. |
harvey@eccnet.com | Washington,DC XML Users Grp
URL: http://www.eccnet.com | http://www.eccnet.com/xmlug
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
On Wed, 2 Apr 2003, Chiusano Joseph wrote:
> 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
--
|
