Creating XML Document Formats - How to be a Successful Technical Architect for J2EE Applications

Creating XML Document Formats

In addition to their use in database design, data-modeling techniques can easily be applied to designing XML documents. The same data models that database administrators use to create physical database designs also readily translate into XML document formats, such as DTDs or schemas. XML is most often used as a means of communication between applications.

The first step in creating any XML document is to identify the document root. XML documents usually contain lists of things identified in the data model. For instance, a <customer-update> document might contain a list of customer-related elements that contain information hat has changed. A <purchase-order> document might contain a list of order-related elements describing one or more purchase order contents.

Entities in a data model translate to elements in an XML document. Only implement the elements that are needed for the documents you're creating. Chances are that you don't need all entities translated into elements. Entities that represent small look-up value domains (e.g., CUSTOMER_TYPE, ACCOUNT_TYPE, etc.) are usually implemented as attributes rather than elements in an XML document.

Attributes of an entity become attributes of the corresponding element. For example, the <customer> element from figure 7.1 would have the attributes customer-id, last-name, first-name, and telephone.

A one-to-many relationship implies that one element is the child of another in an XML document. Unlike relational databases, a foreign key to the parent element isn't needed because it's indicated by segment ancestry. Ancestry is indicated naturally within the XML syntax. For example, the <customer> element from figure 7.1 would have an optional <account> child element.

As a more complete illustration, listing 7.2 is a sample XML document for the data model in figure 7.1.

Listing 7.2: XML Documnt Example

<?xml version="1.0" encoding=" UTF-8"?>
<customer-update>
       <customer       customer-id=" C123"
first-name=" Derek"
last-name=" Ashmore"
telephone="999-990-9999">
               <account account-id=" A1"
account-name=" Personal Checking"
account-type=" checking"/>
       </customer>
</customer-update>

A sample DTD definition for this XML document type follows:
<?xml version="1.0" encoding=" UTF-8"?>
<!ELEMENT account EMPTY>
<!ATTLIST account
       account-id CDATA #REQUIRED
       account-name CDATA #REQUIRED
       account-type CDATA #REQUIRED
>
<!ELEMENT customer (account)>
<!ATTLIST customer
       customer-id CDATA #REQUIRED
       first-name CDATA #REQUIRED
       last-name CDATA #REQUIRED
       telephone CDATA #REQUIRED
>
<!ELEMENT customer-update (customer)>
A sample Schema definition for this XML document type follows:
<?xml version="1.0" encoding=" UTF-8"?>
<!DOCTYPE xsd:schema PUBLIC "-//W3C//DTD XMLSCHEMA 19991216//EN" "" [
       <!ENTITY % p 'xsd:'>
       <!ENTITY % s ':xsd'>
]>
<xsd:schema xmlns:xsd=" http://www.w3.org/1999/XMLSchema">
       <xsd:complexType name=" accountType"
 content=" empty">
                <xsd:attribute name=" account-id"
type=" xsd:string" use=" required"/>
                <xsd:attribute name=" account-name"
type=" xsd:string" use=" required"/>
                <xsd:attribute name=" account-type"
type=" xsd:string" use=" required"/>
        </xsd:complexType>
        <xsd:complexType name=" customerType"
 content=" elementOnly">
                <xsd:sequence>
                       <xsd:element name=" account"
type=" accountType"/>
                </xsd:sequence>
                <xsd:attribute name=" customer-id"
 use=" required">
                       <xsd:simpleType base=" xsd:binary">
                              <xsd:encoding value=" hex"/>
                       </xsd:simpleType>
                </xsd:attribute>
                <xsd:attribute name=" first-name"
type=" xsd:string" use=" required"/>
                <xsd:attribute name=" last-name"
type=" xsd:string" use=" required"/>
                <xsd:attribute name=" telephone"
type=" xsd:string" use=" required"/>
        </xsd:complexType>
        <xsd:element name=" customer-update">
               <xsd:complexType content=" elementOnly">
                       <xsd:sequence>
                             <xsd:element name=" customer"
type=" customerType"/>
                       </xsd:sequence>
                       <xsd:attribute name=" xmlns:xsi"
type=" xsd:uriReference"
use=" default"
 value=" http://www.w3.org/1999/XMLSchema-instance"/>
                       <xsd:attribute
 name=" xsi:noNamespaceSchemaLocation"
type=" xsd:string"/>
                       <xsd:attribute
 name=" xsi:schemaLocation"
type=" xsd:string"/>
                </xsd:complexType>
        </xsd:element>
</xsd:schema>

Rewrite all many-to-many relationships by choosing one of the entities of each relationship to be a child element. For example, consider a many-to-many relationship between customer orders and products. This relationship would be rewritten as two one-to-many relationships using the entity ORDER_LINE_ITEM as a cross-reference. An <order-line-item> element could be a child of the <order> or <product> element, or both. Chances are that both do not need to be implemented and that <order-line-item> would be considered a child of <order>.

Common Mistakes

Declaring attributes as elements. One of the most common XML design mistakes I see is making data elements that should be attributes. For example, some developers would have made account-name, from listing 7.2, a separate element instead of an attribute of <account>. Misusing elements in this way is likely to cause lower parsing performance and slower XSLT transformations.