| home / programming / xml_24 / 2 |    [previous][next] |
|
|
|
Seeing a few examples of XPointer expressions can make all the difference in understanding how XPointer is used to define document fragment identifiers. Following is an example of a simple XPointer expression:
child::factoid
This example uses the child relative location path to locate all of the children
of the context node that are of element type factoid. Let me rephrase
it in a different way: The sample expression locates element nodes of type factoid
that are child nodes of the context node. Keep in mind that the context node
is the node from which you are issuing the expression, which is a lot like the
current path of a file system when you’re browsing for files. Also, it’s worth
clarifying that the XPointer expression child::factoid simply describes
the fragment identifier for a resource and is not a complete resource reference.
When used in a complete expression, you would pair this fragment identifier
with a URI that is assigned to an href attribute, like this:
href=”http://www.stalefishlabs.com/factoids.xml#child::factoid”
In this example, a URI is specified that references the XML document named
factoids.xml. The XPointer expression is then provided as a fragment identifier,
which is separated from the URI by a pound symbol (#). This is the typical way in
which XPointers are used, although expressions can certainly get more complex
than this. For example, the following code shows how to use location paths to
create a more elaborate expression that carries out a more intricate reference:
child::factoid/following-sibling::legend
This example first locates all child elements that are of type factoid
and then finds the second siblings following each of those element nodes that
are of type legend. To understand how this code works, let’s break it down.
You begin with the familiar child::factoid expression, which locates
element nodes of type factoid that are child nodes of the context node. Adding
on the following-sibling::legend location path causes the expression
to locate sibling elements of type legend. Granted, this may seem
like a strange use of XPointer, but keep in mind that it is designed as an all-purpose
language for addressing the internal structure of XML documents. It’s impossible
to say how different applications might want to address document parts, which
is why XPointer is so flexible.
In addition to location paths, XPointer defines several functions that perform different tasks within XPointer expressions. One class of functions is known as node test functions, which are used to determine the type of a node. Of course, you can use the name of an element to check if a node is of a certain element type, but the node test functions allow you to check and see if a node contains a comment, text, or processor instruction. The following is an example of how to use one of these functions:
/child::processing-instruction()
This expression results in the location of any processing instructions that are children of the root element. The reason the expression results in children of the root element is because the root element (/) is specified as the basis for the expression.
As you can see in these few examples, XPointer is a comprehensive yet flexible technology that is capable of doing some pretty interesting things. I’ll readily admit that there is more to XPointer than I’ve touched on here; I mainly wanted to provide a solid overview and demonstrate how basic expressions are created. I encourage you to explore XPointer more on your own and experiment with creating XPointer expressions. However, before you do that you need to learn how XPointer fits into XLink.
The whole point of XPointer (no pun intended) is to provide a means of referencing portions of XML documents for the purpose of creating powerful XML links. XLink ultimately makes links possible through linking elements, which are elements that describe the characteristics of links. The anchor element in HTML is a good example of a linking element. Although linking elements form the basis of XLink, there are no predefined linking elements in the XLink language. Although it may seem strange at first, you won’t find any standard element in the XLink language. The reason is because XML is all about the creation of custom tags (elements), which precludes the use of a fixed linking element in XLink. In other words, you are encouraged to define your own linking elements specific to a particular XML-based language, as opposed to being locked into a fixed element, such as HTML’s anchor element (a).
Even though HTML’s anchor element is somewhat limiting in the context of XML, there still must be some kind of mechanism in XLink that identifies links. This mechanism comes in the form of standard linking attributes that can be associated with any element. There are several of these attributes, which you learn about in the next section. For now, just understand that the presence of XLink attributes is sufficient to identify an element as a linking element.
A linking element uses a construct called a locator to connect resources involved in a link. In both HTML and XML, the href attribute serves as the locator for links. Although HTML and XML share this attribute, links in XML are described in much more detail than their HTML counterparts. Perhaps the most important difference is the fact that XML links completely describe the resources involved, even if a target resource is just a document fragment. In HTML, it is necessary to place an anchor element in a target fragment resource and identify it using the id attribute. This is not the case in XML because XLink provides the necessary ingredients to fully describe the resources involved in a link.
There are two types of linking elements supported in XLink:
Inline links
An inline link is a link whose content serves as one of the link’s participating resources. Typically, an inline link has a linking element that contains content that serves as the source for the link. HTML anchor links are good examples of inline links because an anchor link contains text or an image that acts as the source for the link. Due to HTML’s use of inline links, you may be curious as to how a link could work any other way. Out-of-line links extend the concept of linking in XML by allowing you to create links that are independent of the linked resources.
An out-of-line link is a link whose content doesn’t serve as one of the link’s participating resources. This means that out-of-line links are independent of their participating resources and therefore serve a very different purpose than inline links. Out-of-line links are useful for linking information in documents that you can’t modify for one reason or another. For example, if you wanted to create a link between two resources that reside on other web sites, you’d use an out-of-line link. Such a link is possible because out-ofline links are geared toward opening up interesting new opportunities for how links are used to connect documents. More specifically, it would be possible to create link databases that describe relationships between information spread across the Web.
Out-of-line links partially form the concept of extended links in XML. Extended links are basically any links that extend the linking functionality of HTML. Out-of-line links obviously are considered extended links because HTML doesn’t support any type of out-of-line linking mechanism. Extended links also support the association of more than one target resource with a given link. With extended links, you could build a table of contents for a web site that consists solely of extended links that point to the various pages in the site. If the links were gathered in a single document separate from the table of contents page itself, they would also be considered out-ofline links.
Hopefully I’ve sold you on the fact that XLink offers some interesting opportunities for creating XML links that are impossible in HTML. Now it’s time to look at exactly how such interesting linking is made possible by XLink. Earlier I mentioned that XLink defines standard attributes that are used to establish linked elements in XML documents. Following are the XLink attributes that can be used to create linked elements:
type—A string that specifies the type of link
href—A locator that addresses a target resource using a URI
from—A string that identifies the resource being linked from when describing
an arc
to—A string that identifies the resource being linked to when describing an arc
show—A string that determines how a target resource is to be revealed to the user
actuate—A string that determines how a link is initiated
role—An application-specific string used to describe the function of a link’s
content
title—A string that serves as a name for a linkThe type attribute determines the type of a link and can have one of the following
values: simple, extended, locator, resource, arc, or group. The href attribute is
one with which you are already familiar, based on its use in HTML. The from and to
attributes are used by arcs, which describe the traversal behavior of links. More
specifically, an arc defines where a two-way link comes from and where it goes. Arcs
could be used to establish web rings, where web pages are linked from one to the
next using the from and to attributes to traverse the ring.
The show attribute determines how a target resource for a link is revealed to the user.
There are three main values for the show attribute:
replace—The target resource replaces the current document (default value).
new—The target resource is shown in a new window.
embed—The target resource is inserted into the current document in place of
the link.The functionality of the show attribute follows that of HTML anchor links until you get
to the last possible value, parsed. If you set the show attribute to parsed, the link will
be replaced by the target resource. This type of link allows you to divide a document
into subdocuments and then link them together to form a compound document,
which can help improve the organization of data.
The actuate attribute determines how a link is initiated and is typically set to one of
the following values:
onRequest—The link must be manually traversed by the user (default value).
onLoad—The link is automatically traversed upon loading the source document.Setting the actuate attribute to onRequest makes a link act like an HTML link,
which means that you have to click the link in order to activate it. The onLoad value
offers functionality not directly available in HTML by allowing a link to be traversed
when a document is first loaded. The onLoad value is particularly useful when used
in conjunction with the embed value for the show attribute; this results in a resource
being automatically loaded and placed directly in a document.
The last two XLink attributes are role and title, which are used primarily for
descriptive purposes. The role attribute describes the role of the content in a link,
whereas title provides a human-readable title for the link that may be displayed
in a browser.
| home / programming / xml_24 / 2 | [previous][next] |
The Network for Technology Professionals
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers
|
Video: How System Center Helps Reduce IT Costs IBM Cloud Computing for Developers Virtual Event, April 6-8 |
Microsoft Video: OCS and Exchange: Platform Futures MORE WEBCASTS, PODCASTS, AND VIDEOS |
Created: March 27, 2003
Revised: December 19, 2005
URL: http://webreference.com/programming/xml_24/2
