XML Unlocks Information

XML Unlocks Information - Elements vs. Attributes with Database Oriented Data
(Page 4 of 5 )

To contrast attributes with elements, here are two examples of student record data that are traditionally stored in a database. The first example primarily uses elements (element-centric) to store data values. The second example primarily uses attributes (attribute-centric).

Element-centric

<students>
<student id="2456">
<name>Jim Smith</name>
<grade>10</grade>
<gpa>3.5</gpa>
</student>
<student id="2457">
<name>Mary Jones</name>
<grade>12</grade>
<gpa>3.4</gpa>
</student>
:
</students>

Attribute-centric

<students>
<student id="2456" name="Jim Smith" grade="10" gpa="3.5" />
<student id="2457" name="Mary Jones" grade="12" gpa="3.4" />
:
</students>

With relational database data, the choice between attributes and elements does not appear all that important. Only unique keys, which establish a link between elements (such as student id), must be attributes to facilitate the linking of records (that is, other elements). With the attribute-centric approach, each element is a record, and each attribute is a field.

Although either approach works, it is generally recommended to use elements instead of attributes. For instance, to distinguish between first and last name, the element-centric approach can be changed to:

<name>
<first>Jim</first>
<last>Smith</last>
</name>

The attribute-centric approach is less favorable because the attribute must be split into two attributes.

<student ... firstname="Jim" lastname="Smith" .../>

Only the element-centric approach is compatible with XSL.

Element-centric XSL transform:

<xsl:value-of select="name"/>

The transform above results in "Jim Smith" in both element-centric approaches, but the attribute-centric approach requires two different transforms.

Attribute-centric XSL transform for one attribute:

<xsl:value-of select="@name"/>

Attribute-centric XSL transform for two attributes:

<xsl:value-of select="@firstname"/> <xsl:value-of select="@lastname"/>

Elements vs. Attributes with Object Oriented Data
Besides relational database data, we should also consider object-oriented data, which describes a physical object, such as a car or a wooden barrel. Like the student record, the data is highly structured. Every part and subassembly relate to the others.

For object-oriented data, the relationship between parts and subassemblies is best described using the element approach. For example,

<automobile modelno="OCC96" class="midsize">
<name>Cutlass Ciera</name>
<engine size="3.0l">
<cylinders count="4" />
</engine>
<wheels count="4" />
<doors>
<door>driver
<mirror />
<lock type="4 button combination" />
<window />
</door>
<door>front passenger
<mirror>OBJECTS IN MIRROR ARE CLOSER THAN THEY APPEAR</mirror>
<lock type="key" />
<window />
<door />
<door>left rear
<lock type="child safety" />
<window openable="no" />
</door>
</doors>
</automobile>

Example of an object-oriented approach for a 10 gallon wooden barrel:

<barrel capacity="10g" material="wood">
<hoops width="2in" dia="2.5ft" material="iron" />
</barrel>

As you can see, both database-oriented and object-oriented data have little text. The data is highly structured and can be easily expressed in a tabular or hierarchical format. However, these highly structured examples would become semi-structured if the student record included teachers' comments or the automobile object included part descriptions and assembly instructions.
blog comments powered by Disqus