Presents your 
XML E-NEWSLETTER for February 19, 2003

<------------------------------------------->

PROCESS EFFICIENTLY WITH THE KEY ELEMENT PATTERN

XML patterns establish a common approach to solving problems. Some patterns
relate to the processing of XML documents, while others relate to the
structure of the XML data directly. The key element pattern falls into
the latter category. Let's examine what the key element pattern is and
what types of problems it solves.

SIMPLE PROBLEM

We'll begin our discussion with a simple problem. We're going to process
a set of XML documents on a periodic basis--say 10 new documents every
hour. Within these documents is a set of data that consists of a handful
of items. A key identifies each item. In our application, we're only
interested in processing items with a specific key.

SOLUTION

This is a particularly common XML problem, and there are many solutions.
A very simple yet powerful solution is to apply the key element pattern
to the data set. Using this pattern, you affect the way the data is
stored in the XML document to better facilitate its processing. The key
element pattern is structured as a way of describing the data in the 
XML document.

The pattern has a few identifying traits. First, it affects a set of
elements within an XML document. You wouldn't apply the key element pattern
to differing elements. Second, the key element pattern is usually
implemented when you have subelements grouped together under one parent element.
And finally, the parent element is identified as the key element and is
augmented with a key attribute used to uniquely identify the parent and
its subelements within the document.

SAMPLE DOCUMENT

To illustrate this solution, we'll start with a set of data that needs
to be included in our documents. This data is a purchase order consisting
of several items. TABLE A shows the items to be included in a single
purchase:

Table A: Sample items in an order

* 15 Widgets @ $13.95 each
* 22 SuperGogs @ $25.00 each
* 10 WankaWoos @ $5.00 each

Putting these items into an XML document is simple enough. We'll create
a root element called PurchaseOrder and then create a series of Item
elements that each contain Description, Quantity, and Price elements, 
as shown in LISTING A:

Listing A: PurchaseOrder.xml
<? xml version="1.0" encoding="ISO-8859-1" ?>
<PurchaseOrder>
  <Item>
    <Quantity>15</Quantity>
    <Description>Widgets</Description>
    <Price>13.95</Price>
  </Item>
  <Item>
    <Quantity>22</Quantity>
    <Description>SuperGogs</Description>
    <Price>25.00</Price>
  </Item>
  <Item>
    <Quantity>10</Quantity>
    <Description>WankaWoos</Description>
    <Price>5.00</Price>
  </Item>
</PurchaseOrder>

So far, our document exhibits some of the traits for the pattern. It
contains a set of like elements, called Item elements. And we have 
groups of elements together under the Item element.

The next step is to augment our key element, the Item element, with a
key attribute that uniquely identifies it within the document. LISTING B
shows the same purchase order, but augmented with a key element that 
can be used to uniquely identify each item within the order document:

Listing B: PurchaseOrder.xml
<? xml version="1.0" encoding="ISO-8859-1" ?>
<PurchaseOrder>
  <Item key="1">
    <Quantity>15</Quantity>
    <Description>Widgets</Description>
    <Price>13.95</Price>
  </Item>
  <Item key="2">
    <Quantity>22</Quantity>
    <Description>SuperGogs</Description>
    <Price>25.00</Price>
  </Item>
  <Item key="3">
    <Quantity>10</Quantity>
    <Description>WankaWoos</Description>
    <Price>5.00</Price>
  </Item>
</PurchaseOrder>

CAVEATS

There are two obvious caveats with this pattern. First is the problem of
ensuring key uniqueness. In other words, it's up to both the application
that creates the document and the application that reads the document to
ensure that the keys are unique for each element; or, at least, to be
aware that there is no mechanism to ensure key uniqueness within XML
directly, as there is with relational database keys.

The second caveat is that keys should be managed as metadata within this
context. In other words, you wouldn't want to use a SKU as a key
attribute since the SKU represents actual content data rather than metadata.
Placing content within an attribute violates the notion of "marking up"
content data.

Brian Schaffner is a senior consultant for Fujitsu Consulting. He
provides architecture, design, and development support for Fujitsu's 
Telcom360 group.

----------------------------------------

MASTER YOUR SKILLS BY PARTICIPATING IN OUR XML FORUM

Attention XML developers! It's time to speak your mind. We have
designated the XML Forum as the place where members can talk technique, 
argue
methods, ask questions, and share experiences. Get a feel for the 
community
consensus on issues that are important to you, and join your peers in 
the
XML Forum.
http://cl.com.com/Click?q=3e-F5gnIizjf2XAxO39CK_PGByo-ibj 

Or send us an e-mail.
mailto:enews7@cnet.com?subject=XML%20-%20Using%20key%20patterns

----------------------------------------