RE: [xml-dev] specific element vs. generic element with a type attribute

["Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@cisco.com>]

Hi.

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

There are really at least two questions I think you are asking.  One is
about best practices for modeling data in XML, the other is about how
much you should let the capabilities of a given validation technique
(XSD in this case) influence your XML design.

I think the data modeling question is easier.  

It's not a hard and fast rule but if you are tempted to ask weather you
should use the common element name and qualify it using an attribute
then your probably should.

If you generalize fees but capture fee color in an attribute, you can
ask questions about either all fees or only yellow fees.  What you want
to avoid is having to parse an element name using string functions in
order to answer questions about yellow fees.

I love Michael's Aristotelian distinctions, and at the same time:

> So I would use <Dog> and <Cat> rather than <animal
> species="Dog"/> etc; but I would use <Program author="mike"> 
> rather than
> <MikesProgram> and <JanesProgram>. 

suggests an even simpler rule, which is "model commonality using markup
in preference to element naming conventions".  If you are going to adopt
a convention along the lines of "the element names of elements that
represent fees should follow the pattern XxxFee where Xxx is a color
name" then you are bucking best practices in XML design.

Also don't underestimate the semantics surfaced by choosing an attribute
name.  If I look at a few fees of the form:
	<OrangeFee/>
	<YellowFee/>
	etc...

I might assume you are modeling fee colors and assume that other fees
might be BlueFee, BlackFee, etc.

If I see fees like this:

	<Fee urgency="orange"/>
	<Fee urgency="yellow"/>

I might infer that other fees would be green and red, and that I would
do well to pay attention to the red fees.

Since you state that validation is done only in a test environment, I
assert that validation in general (and validation using schemas in
particular) is not a hard business requirement for your system.  If
that's the case, you should model first for you primary requirements,
then build the best schema you can to fit that model.

In order to answer the other questions about implementation complexity
and performance, you'd need to define some tasks you were going to do
against the data.

---->Nathan

> 
> 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.
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>