 | Level: Introductory Kevin Williams (kevin@blueoxide.com), CEO, Blue Oxide Technologies, LLC
01 Jul 2001 This column takes a look at how to use XLink pointers when representing data to make XML documents more compact and flexible. Sample code shows examples of an invoice with and without the XLink pointers, plus an example of using XLinks with a URL-addressable database.
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.
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.
Listing 1. A full invoice document (with customer and part info embedded)
<?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.
Listing 2. Modified invoice document using XLink simple links
<?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>
|
Listing 3. customers/18273.xml
<?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>
|
Listing 4. parts/W-127.xml
<?xml version="1.0"?>
<part>
<partID>W-127</partID>
<partName>Widget</partName>
<partSize>2-inch</partSize>
<partColor>Blue</partColor>
</part>
|
Listing 5. parts/S-387.xml
<?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.
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
About the author | | | Kevin Williams is the CEO of Blue Oxide Technologies, LLC, a company
that designs XML and Web service creation software. He can be reached for comment at kevin@blueoxide.com. Visit their Web site
at http://www.blueoxide.com. He has also co-authored several books on XML from Wrox Press. |
Rate this page
| |
