The W3C recently promoted a specification called XLink to Recommendation status. In this column, I take a look at XLink and how you can use it to simplify the representation and transmission of data.

What is XLink, anyway?

To quote the W3C XLink specification: "[T]he XML Linking Language (XLink) ... allows elements to be inserted into XML documents in order to create and describe links between resources." The specification then goes on to assert that links defined using XLink are similar to HTML hyperlinks, leading many programmers to conclude that this is the only purpose for the specification. However, there is another way XLink can be used to great benefit: to show the relationships between data resources.

Back to top

XLink in action

Consider a typical order-tracking application, say for a large manufacturing company. An XML document describing an order would usually contain information about the customer who placed the order, the order status, and the individual line items on the order, with quantities and prices. Consumers of this document might want to use it in very different ways. In the accounting department, someone who requests the order data probably would be interested only in the total price that it needs to bill the customer -- details about the individual line items on the invoice (apart from the quantity and price) would be irrelevant. By contrast, when customers request their orders (for viewing online, perhaps), they might want to see more information, for example, the human-readable name for a part on a line item. Transmitting the entire document to each customer with full details doesn't necessarily make sense: It would be ideal to transmit just the bare bones of the order (for consumers who are interested only in the basics) with pointers to more detailed info. XLink provides a great way to accomplish that.

A full order document might look something like Listing 1.

<?xml version="1.0"?>
<order>
  <orderDate>7/23/2001</orderDate>
  <shipDate>7/26/2001</shipDate>
  <customer>
    <customerID>18273</customerID>
    <customerName>Fred Q. Customer</customerName>
    <billingAddress>
      <address1>100 Main St.</address1>
      <city>Anywhere</city>
      <state>AZ</state>
      <zip>12345</zip>
    </billingAddress>
    <shippingAddress>
      <address1>800 Corporate Dr.</address1>
      <address2>Suite 314</address2>
      <city>Anywhere</city>
      <state>AZ</state>
      <zip>12345</zip>
    </shippingAddress>
  </customer>
  <lineItem>
    <part>
      <partID>W-127</partID>
      <partName>Widget</partName>
      <partSize>2-inch</partSize>
      <partColor>Blue</partColor>
    </part>
    <quantity>17</quantity>
    <unitPrice>0.20</unitPrice>
  </lineItem>  
  <lineItem>
    <part>
      <partID>S-387</partID>
      <partName>Sprocket</partName>
      <partSize>1-inch</partSize>
      <partColor>Red</partColor>
    </part>
    <quantity>31</quantity>
    <unitPrice>0.40</unitPrice>
  </lineItem>  
</order>

Not only does the complete invoice in Listing 1 contain information that the consumer might not need (and would just discard), but this document would also create a problem if you use XML natively to store your data: If details about each part are embedded in each document, lots of disk space would be wasted on repeated part information. Assume for the moment, however, that the information is being pulled on demand from a relational database. A typical design for a database holding this type of information would have three main tables: a Customer table that defines all the customers for the manufacturer, a Part table that describes all the parts that are sold by the manufacturer, and an Order table that relates the two, showing which customer ordered which part, when, and in what quantity. This gives us a hint as to how we can break this document down into controllable pieces.

Accordingly, Listing 2 replaces the customer and part elements in the structure with XLink references to documents that contain just those elements. The resulting documents would look something like listings 2, 3, 4, and 5.

<?xml version="1.0"?>
<order xmlns:xlink="http://www.w3.org/1999/xlink">
  <orderDate>7/23/2001</orderDate>
  <shipDate>7/26/2001</shipDate>
  <customer xlink:href="customers/18273.xml">18273</part>
  <lineItem>
    <part xlink:href="parts/W-127.xml">W-127</part>
    <quantity>17</quantity>
    <unitPrice>0.20</unitPrice>
  </lineItem>  
  <lineItem>
    <part xlink:href="parts/S-387.xml">S-387</part>
    <quantity>31</quantity>
    <unitPrice>0.40</unitPrice>
  </lineItem>  
</order>

<?xml version="1.0"?>
<customer>
  <customerID<18273</customerID>
  <customerName>Fred Q. Customer</customerName>
  <billingAddress>
    <address1>100 Main St.</address1>
    <city>Anywhere</city>
    <state>AZ</state>
    <zip>12345</zip>
  </billingAddress>
  <shippingAddress>
    <address1>800 Corporate Dr.</address1>
    <address2>Suite 314</address2>
    <city>Anywhere</city>
    <state>AZ</state>
    <zip>12345</zip>
  </shippingAddress>
</customer>

<?xml version="1.0"?>
<part>
  <partID>W-127</partID>
  <partName>Widget</partName>
  <partSize>2-inch</partSize>
  <partColor>Blue</partColor>
</part>

<?xml version="1.0"?>
<part>
  <partID>S-387</partID>
  <partName>Sprocket</partName>
  <partSize>1-inch</partSize>
  <partColor>Red</partColor>
</part>

You can probably see the obvious advantages to structuring your information this way. If your accounting department just wants to send a bill to customer 18273 (and that ID is in your accounting software), it needs to retrieve only the order document to obtain the information it needs. This information is available in a significantly smaller document than the original (in Listing 1) with all extra information embedded. You could set up the application so that the customer retrieving the invoice online sees the information automatically presented (the style sheet rendering the page could obtain the detail information for the customer and parts at the initial rendering time), or so that the detail information appears as hyperlinks for the customer to traverse. Documents structured with hyperlinks are more flexible and atomic; the consumer retrieves only the relevant pieces.

You may be wondering how this strategy would benefit your system. After all, you probably store your data in a relational database, rather than in a native XML database, with the XML documents generated on the fly as needed. You can take advantage of this approach a couple of ways. If your customer and part information has a relatively low volatility, you can generate XML documents to represent the customers and parts as they are created or changed, thus ensuring that requests for this data do not require additional costly database calls. This also allows you to create customer and part catalogs without accessing the relational database at all. If you are using a relational database that is URL-addressable -- most relational databases either already provide this functionality or will very soon -- you can create an accessor (such as a stored procedure) that would allow the information to be retrieved on the fly, as in the fictitious example in Listing 6.

Back to top

Conclusion

This column demonstrates how you can use XLink's basic functionality to simplify your document structures and reduce your network transmission overhead. It looks only at the way to use simple links; XLink also provides extended link functionality, which you can use to relate many resources together (you might create an XLink linkbase that relates a customer to all of his or her orders, for example). As XML and the associated helper technologies continue to mature, programmers will have more flexibility when deciding how to implement information systems, allowing you to tune your solutions to best meet the needs of your clients.

Resources

• To learn more about XLink, take a look at the W3C Recommendation.
  
  
• For a quick look at how to use XLink for hyperlinking or for external references, see Brett McLaughlin's recent tip.
  
  
• Soapbox: Kevin tells why he advocates XML Schema for data-centric XML apps.
  
  
• Find out about DB2 XML Extender and the XML support built into DB2.
  
  
• Find other articles in Kevin William's XML for Data column.
  
  
• Learn how you can become an IBM Certified Developer in XML and related technologies.
  
  
• Find a wealth of XML-related content in the developerWorks XML zone.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• What is XLink, anyway?
• XLink in action
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

With the no-charge DB2 Express-C, pureXML, Zend Core PHP, and Java you can develope advanced Web 2.0 applications quickly that matter.

---

• Try: Download a free trial version of DB2 Express-C, which includes Zend Core PHP and pureXML technology that is ideally suited for managing both XML and relational data.
• Article: See how DB2 pureXML schema capabilities can evolve schemas without making any changes to your applications.
• Tutorial: This tutorial shows you how to use DB2's pureXML to expose the native XML capabilities of DB2.
• Buy: DB2 9 for Linux, UNIX and Windows

My developerWorks community

Dig deeper into XML on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers