Cart
[Home] [By Thread] [By Date] [Recent Entries]
That is a bit different. Is this a report in which the FinalEstimatedAmount is calculated? Three is tighter and a bit less "conceptual" and that can make it a better choice depending on how well it fits into the categories I mentioned in the last post. len -----Original Message----- From: Chiusano Joseph [mailto:chiusano_joseph@b...] 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> 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> Thanks! Joe Joseph Chiusano 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
|
