Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@e... | 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@b... title:Senior Consultant fn:Joseph M. Chiusano end:vcard
|
