BizTalk Utilities CV ,   Jobs ,   Code library
 
Home Page


Add/Edit your code items
Search the code library
Browse for the code library


Schemas, xsd, xdr
Tips for Designing a DTD- Part 4 of 4 : Object Oriented Data
Getting the value of an element with optional subelements
XML Code Generator: Generating Wrapper Classes from an XML Schema
What is WDDX?
XSLT Stylesheet for summarizing the structure of an XML document
Validating XML with Schemas
Punctuated Changes In XML Documents
XMLStarlet Command Line XML Toolkit
W2XML v2.0 SR1
Free DTD for Academic Publishers
Arquemie for XML Schemas
XMLStarlet Command Line XML/XSLT Toolkit
XSD Merger


 
 

<< reBloggerSEO >>


By Mark Wilson
I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
First Posted 03/14/2002
Times viewed 230

Tips for Designing a DTD- Part 3 of 4 : Database Oriented Data


Summary 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).

Elements vs. Attributes with Database Oriented Data

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</first>
</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/>

Excepts from XML Unlocks Information: How XML Accommodates Human-Authored Content

Additional information

Further additional information


Rate this article on a scale of 1 to 10 (0 votes, average 0)

Your vote :  

<< reBloggerSEO >>





Leave a comment for this article
Your name
Your email (optional)
Your comment
Optional: Upload an attachment
Enter the code shown:

 
 

    Email TopXML