[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: 3 possible approaches for representing concepts

• To: Chiusano Joseph <chiusano_joseph@b...>
• Subject: Re: Re: 3 possible approaches for representing concepts
• From: Betty Harvey <harvey@e...>
• Date: Wed, 2 Apr 2003 18:00:21 -0500 (EST)
• Cc: xml-dev@l...
• In-reply-to: <3E8B61E7.61B6D3B7@b...>

Joe:

Definately not number 1.  I have seen approach #1 when organizations
want to XMLize their EDI.  It is ugly and it is a programmers nightmare 
dealing with the long elements names.  It is much better to break it down 
into logical attributes.  I think you you want 2 or 3.  How about a #4 

<EstimatedAmount yearType="CurrentYear" amountType="Budget"
         finalIndicator="Final">  

I think you could make the case the <EstimatedAmount> and
<Amount> should be distinctive.  Also if there are default
attributes, the values wouldn't necessarily be required.

I still think the discussion of elements and attributes
from Robin Covers is good reading!

Betty


On Wed, 2 Apr 2003, Chiusano Joseph wrote:

> 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

-- 

• References:
  • Re: 3 possible approaches for representing concepts
    • From: "Chiusano Joseph" <chiusano_joseph@b...>

• Prev by Date: Re: Re: 3 possible approaches for representing concepts
• Next by Date: Re: 3 possible approaches for representing concepts
• Previous by thread: Re: Design as, one hopes, not premature optimization
• Next by thread: Re: Re: 3 possible approaches for representing concepts
• Index(es):
  • Date
  • Thread