Sams Teach Yourself XML in 24 Hours, Complete Starter Kit, 3rd Edition. Part 2

Sams Teach Yourself XML in 24 Hours, Part 2

Excerpted from Sams Teach Yourself XML in 24 Hours, Complete Starter Kit, 3rd Edition by Michael Morrison. ISBN 067232797X, Copyright © 2005. Used with the permission of Que & Sams Publishing.

One example of a link repository that could be built using XLink is an intricately cross-referenced legal database, where court cases are linked in such a way that a researcher in a law office could quickly find and verify precedents and track similar cases. Though it's certainly possible to create such a database and incorporate it into HTML web pages, it is cumbersome. XLink provides the exact feature set to make link repositories a practical reality.

You now understand that XML linking is considerably more powerful than its HTML counterpart. Perhaps more interesting is the fact that XML links involve a concert of technologies working together. XLink is the primary technology that makes XML links possible, but it requires the help of two other technologies—XPointer and XPath. If you traced the history of XLink in the W3C, you'd learn that it originally consisted of only two components, XPointer and XLink. However, the W3C realized that XPointer wasn't the only XML technology that needed a means of addressing parts of a document. XSLT also needed a means of addressing document parts, so it was decided to separate document addressing into XPath. XPointer builds on XPath to provide support for addressing the internal structure of XML documents. XLink in turn uses XPointer to describe flexible links to specific structures within XML documents.

XLink is designed to support simple one-way links similar to those in HTML, as well as a variety of different extended links that offer interesting new ways of linking documents. XLink is implemented as an XML language, which means that it can be easily integrated into XML applications. XPointer is a non-XML language based upon XPath that is used to address internal structures in XML documents. XPointer is an important part of XLink because it specifies the syntax used to create fragment identifiers, which are used to reference internal document constructs.

Addressing with XPointer

XPointer allows you to walk the tree of nodes that an XML document is comprised of to address a specific node or nodes. XPointer expands the syntax set forth by XPath to provide a means of creating fragment identifiers, which are used to specify parts of documents. XPointer provides considerably more control over the referencing of XML document data than the hyperlink approach employed by HTML. For example, XPointer allows you to do things such as address an element with a given value within a list of elements of a given type. You use XPointer expressions in XML links by appending them onto the end of URIs with a pound symbol (#), as in the separation between a URI and an XPointer expression. The next few sections break down XPointer into further detail and demonstrate exactly how to create XPointer expressions.

The most important component of XPointer expressions is the location path, which is a construct used to describe the path that must be followed to arrive at a node within an XML document tree. Location paths are the building blocks of XPointer expressions, which are evaluated to arrive at a specific location within a tree. More specifically, location paths allow you to traverse siblings, ancestors, children, and descendants of nodes, not to mention attributes. Location paths are broken down into two basic types—absolute paths and general paths.

Absolute location paths point to a specific location within an XML tree, and therefore aren't dependent on context. Following are the different absolute location paths defined in XPointer:

/—Locates the root node, which is the parent node for the entire document tree id(Name)—Locates the element with an attribute ID value of Name here()—Locates the node containing the current XPointer expression origin()—Locates the sub-resource from which the user initiated a link (used with out-of-line links)

The most important absolute location paths are the root and id() paths. The root path is represented by a forward slash (/), and is often used at the start of an XPointer expression as the basis for absolute location paths. The id() location path is used to locate an element with a specific attribute value.

In addition to absolute location paths, XPointer also defines a rich set of relative location paths. Relative location paths are always relative to some node, which is known as the context node for the path. Following are the relative location paths available for use in XPointer expressions:

child—Locates child nodes of the context node descendant—Locates nodes within the context node descendant-or-self—Same as descendant except the context node is also included parent—Locates nodes one level above the context node that contains the context node ancestor—Locates all nodes above the context node that contain the context node ancestor-or-self—Same as ancestor except the context node is also included preceding-sibling—Locates sibling nodes that precede the context node following-sibling—Locates sibling nodes that follow the context node preceding—Locates nodes that precede the context node following—Locates nodes that follow the context node self—Locates individual context nodes within a list of context nodes attribute—Locates attributes of the context node

If you're totally confused by all this context node talk, don't worry because it will all make sense in a moment. As confusing as it may seem, the relative location paths in the previous list really are quite useful and are much easier to use than you might think. The next section shows you how to use these location paths to create expressions in XPointer.

Created: March 27, 2003
Revised: December 19, 2005

URL: https://webreference.com/programming/xml_24/2