[
Lists Home |
Date Index |
Thread Index
]
Thanks Betty. The fact that it is age-old is precisely the reason I
posted this - I am looking for feedback based on the tools of today,
April 2003. I have an urgent need to make a decision based on the
current landscape. If things haven't changed, then that is good
information too.
Joe
Betty Harvey wrote:
>
> 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
>
> --
begin:vcard
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard
|
