- XML as a Wire Representation
- Querying XML Elements Using XPath
- Essential XML
- XML Schemas
- Identifying XML Elements Using XLink
- XML Transformations
- .NET's XML Architecture
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Identifying XML Elements Using XLink
As you gain experience with XML, you'll find that hierarchical relationships between data elements lend themselves to XML serialization rather naturally. XML is quite happy with a parent/child or sibling/sibling relationship between data elements. But what do you do if the data isn't hierarchical by nature?
A classic example of this is the linked list. The nodes in a linked list, by definition, have no hierarchical relationship. You could argue in favor of a sibling/sibling relationship, but recall that XML doesn't specify ordering of elements. To XML, this document arrangement
<element1/> <element2/>
is semantically the same as this arrangement:
<element2/> <element1 />
XML doesn't distinguish between the two unless you consider their document order—and this ordering is considered tenuous, at best. Because we're talking about a linked list, which has a definite ordering in memory, we need to be a bit more concrete. In this case, XPLink is employed.
XLink uses two attributes, href and id, to identify the semantic links between elements. Actually, XLink is a great deal more than what is discussed here. We'll discuss XLink only with respect to its use in the SOAP protocol, as you'll see in Chapter 4, ".NET Web Services and SOAP." You could use XLink to link elements in completely different XML documents, for example, but you needn't go that far for Web Service purposes.
Let's look at XLink by example. Imagine that you have the linked list that you see in Figure 3.3.
){kind=link}
You'll actually revisit the linked list in the next chapter when we tie XLink to SOAP, as well as in Chapter 6, "Web Services in ASP.NET," where you'll send a linked list to a Web Service for processing. Here, though, it's important to note that you have four nodes, with the usual components—a head node, a tail node, and intermediate nodes. The tail node has its "next" link set to null, or nothing, to indicate that there is no more data.
Figure 3.3 Conceptual image of a linked list.
In code, this linked list is made up of nodes:
class Node
{
int iValue;
Node pNext;
}
In XML, we create XML elements representing the list nodes and link them so that the current node "points" to the next node using the href attribute:
<node head="true"> <iValue>24</iValue> <pNext href="#node2" /> </node> <node root="true" id="node2"> <iValue>609</iValue> <pNext href="#node3" /> </node> <node root="true" id="node3"> <iValue>32</iValue> <pNext href="#node4" /> </node> <node id="node4"> <iValue>87</iValue> <pNext xsi:null="true" /> </node>
Each corresponding "next" node has an id attribute that is identical to the href of the previous node. Note that the href attribute precedes the actual id value with a pound sign, #. This indicates that the link is contained within this document instead of some external reference.
A head attribute also was created for this example. This identifies the node as the starting point—without it, you wouldn't necessarily know which node was the starting point. It's true that you could look at all the <pNext/> elements and figure it out, but adding the attribute makes for faster processing. SOAP has a similar concept that you'll read about in the next chapter.
To tie off the list, we added the xsi:null attribute. This comes directly from XML schema, where you can identify a value as null or nothing using this construct. Of course, you must tie off the list—that is required as part of the basic linked list abstract datatype. To do otherwise would invite your code to randomly walk through memory until you hurt yourself. The same requirement applies to the XML list serialization—hence, the attribute.
As the XML list representation indicates, XLink is a necessary technology for serializing Web Services. After all, if you think about it, the methods that you send into the remote Web Service method are roughly equivalent to a linked list. They're not linked in the traditional sense, but they do have some association, if only because they belong to the same remote method. SOAP looks at your method parameters and, in some cases, will serialize them using XLink.