Re: specific element vs. generic element with a type attribute

Hi Steve,

I personally would go with the second approach because it separates 
structure from content.  However, there are always exceptions, and your case 
might be one of them.  (I also think the second case would be easier to 
implement and be easier to add new values if required.)

However, due to personal notions of aesthetics I would be inclined to go for 
something like:

<Fees>
 <Fee type="Orange" Amount="12.34"><More>...</More></Fee>
 <Fee type="Yellow" Amount="56.7"><More>...</More></Fee>
</Rate>

Or:

<Fees>
 <Fee><type>Orange</type><Amount>12.34</Amount><More>...</More></Fee>
 <Fee><type>Yellow</type><Amount>56.7</Amount><More>...</More></Fee>
</Rate>

The above should probably best be viewed as input to your considerations 
rather than being conclusive in any sense as much of this comes down to 
personal style etc.

HTH,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         http://www.tech-know-ware.com/lmx
                         (or http://www.xml2cpp.com)
=============================================

----- Original Message ----- 
From: "Tolkin, Steve" <Steve.Tolkin@FMR.COM>
To: <xmlschema-dev@w3.org>; <xml-dev@lists.xml.org>
Sent: Sunday, March 12, 2006 5:43 PM
Subject: specific element vs. generic element with a type attribute



Which is better: using a set of specific elements or a generic element
with a type attribute?

Here is a snippet of an XML document using the specific elements
approach.
<Fees>
 <OrangeFee><Amount>12.34</Amount><More>...</More></OrangeFee>
 <YellowFee><Amount>56.7</Amount><More>...</More></YellowFee>
</Rate>

Here is a similar document, using a generic element with a type
attribute.
<Fees>
 <Fee type="Orange"><Amount>12.34</Amount><More>...</More></Fee>
 <Fee type="Yellow"><Amount>56.7</Amount><More>...</More></Fee>
</Rate>

Background:  We are using XML schema to specify the structure of a set
of XML documents.
The XML is the payload in a web service; it is described by WSDL and
sent using SOAP.  Currently it is just a message; it is not stored in an
XML database.  Currently the XML is written and read using Java.  Schema
validation is only done in test environments, not in production.   Each
type of value is optional, and can occur at most once.  For any omitted
type the Amount is treated as being 0.  All names and examples are
fictional.   The type attribute uses an enumeration.  The XML Schema
fragment for that approach includes something like:
<xs:simpleType name="FeeType">
  <xs:restriction base="xs:string">
    <xs:enumeration value="Orange"/>
    <xs:enumeration value="Yellow"/>
  </xs:restriction>
</xs:simpleType>

Questions:
The names "set of explicit elements" and "generic element with a type
attribute" are clear but verbose.
Q1a. Is there a generally accepted way to refer to these approaches?
Q1b. What other names are (or have been) commonly used?

Q2. Is there an already existing writeup that discusses the pro's and
con's of each approach?
(This seems analogous to the elements vs. attributes discussion.)

Differences:
Here are some differences between the approaches.  However, it is not
clear how much these actually matter.

Benefits of the specific element approach:
* Allows schema to enforce at most one occurrence.
* Allows schema to enforce sequence.
* Allows schema to have different annotation, e.g. documentation, for
each different type.
* Allows different types to have different default values.

Benefits of the specific element approach:
* Is slightly easier to define the XML schema
* Is slightly easier to modify the XML scheme, e.g., to add a new type

However there may be other considerations, and some may be more
important than these.
Q3. Which requires less code to implement?  (Is this different for write
vs. read?)

Q4. Which has less impact to the code after adding a new type.
(However, adding new types will be rare.)

Q5. Which has been performance?

Q6. To ease the burden on the reading code we might want to always have
a value for each type, populating the Amount element with 0.  Is this a
good idea?  Does this affect the best way to represent this information?


Thanks,
Steve
---
Steven Tolkin
There is nothing so practical as a good theory.  Comments are by me, not
Fidelity Investments, its subsidiaries or affiliates.

Received on Sunday, 12 March 2006 20:13:51 UTC