Cart
[Home] [By Thread] [By Date] [Recent Entries]
Naming is often a matter of readability, addressability, and composability. 1. Readability: Does a human read this? Is there a legacy name they are familiar with and expect to see. Don't Shock The Monkey. 2. Addressability: Will the suconcepts/topics vary and will they be the variants be used to identify the superconcept to the machine? Like URI/URL naming or any other multi-morph name, if it varies, it has to vary under the topic (whatever you use in the element) 3. Composability: can the human or machine that has to create this element/attribute combination logically sort out these multi-morphs and combine them efficiently from perhaps, the orignal source, say a database table? IME, approach number 2 wins most of the time. Since that conflicts with your experience, I'll be interested in the counter-response. len -----Original Message----- From: Chiusano Joseph [mailto:chiusano_joseph@b...] Sent: Wednesday, April 02, 2003 4:12 PM To: xml-dev@l... Subject: 3 possible approaches for representing concepts 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
|
