| home / programming / xml_24 / 1 |   [previous] |
|
|
|
The XPath number functions should be somewhat familiar to you since you saw them in action back in Hour 13 when you created XSLT stylesheets that relied on the number functions. Following are the most commonly used number functions in XPath:
|
Following is an example of how to use the sum() function to add up a bunch of
attribute values:
sum(cart/item/@price)
Of course, you can make nested calls to the XPath number functions. For example,
you can round the result of the sum() function by using the round() function, like
this:
round(sum(cart/item/@price))
You may have noticed that I’ve used the word “select” a lot in this hour when explaining how an XPath expression effectively selects part of a document. However, this selection process doesn’t take place within XPath alone. XPath is always used in the context of another technology such as XSLT, XPointer, or XLink. The examples of XPath that you’ve seen in this lesson must therefore be used in conjunction with additional code. For example, the following code shows how one of the training log expressions from earlier in the hour might be used in an XSLT stylesheet:
<xsl:value-of select=”*/session[@type=’running’]”
/>
In this code, the XPath expression appears within the select attribute
of the xsl:value-of element, which is responsible for inserting
content from a source XML document into an output document during the transformation
of the source document. Refer back to Hours 12 and 13 for more information on
XSLT stylesheets and how they are used. The point I want to make here is that
the XSLT xsl:valueof element is what makes the XPath expression
useful. XPath plays a critical role in XSLT, as you probably remember from Hour
13.
Similar to its role in XSLT, XPath serves as the addressing mechanism in XPointer. XPointer is used to address parts of XML documents, and is used heavily in XLink, which you learn about in a moment. XPointer uses XPath to provide a means of navigating the tree of nodes that comprise an XML document. Sounds familiar, right? XPointer takes XPath a step further by defining a syntax for fragment identifiers, which are in turn used to specify parts of documents. In doing so, XPointer provides a high degree of control over the addressing of XML documents. When coupled with XLink, the control afforded by XPointer makes it possible to create interesting links between documents that simply aren’t possible in HMTL, at least in theory.
Similar to HTML web pages, XML documents can also benefit greatly from links that connect them together. Knowing this, the architects of XML created a linking mechanism for XML that provides support for traditional one-way links, such as those you may be familiar with in HTML, along with more advanced links, such as two-way links. Links in XML are in fact considerably more powerful than HTML links, as you will learn in a moment when you begin exploring XLink and XPointer. Before getting into that, however, it’s worth taking a moment to assess the role of links in HTML.
HTML links (hyperlinks) are based upon the concept of connecting one resource to another resource—a source is linked to a target. The source of an HTML link is typically displayed on a web page (via text or an image) so as to call out the fact that it links to another resource. Text links are typically displayed with an underline, and the mouse pointer usually changes when the user drags it over a link source. Traversing a link in HTML typically involves clicking the source resource, which results in the web browser navigating to the target resource. This navigation can occur in the same browser window, in which case the target resource replaces the current page, or in a new browser window.
The important thing to understand about HTML links is that although they involve two resources, they always link in one direction. In other words, one side of the link is always the source and the other side is always the target, which means you can follow a link only one way. You might think that the Back button in a web browser allows HTML links to serve as two-way links, but the Back button has nothing to do with HTML. The Back button in a web browser is a browser feature that involves keeping a running list of web pages so that the user can back through them. There is nothing inherent in HTML links that supports backing up from the target of a link to the source; the target of a link knows nothing about its source. So, HTML links are somewhat limited in that they can link only in one direction. You might be wondering how it could possibly be useful to link in two directions—we’ll get to that in a moment.
If you’ve spent any time coding web pages with HTML, you’re no doubt familiar
with the a element, also known as the anchor element, which is used to create HTML
links. The anchor element identifies the target resource for an HTML link using the
href attribute, which contains a URI. The href attribute can either reference a full
URI or a relative URI. HTML links can link to entire documents or to a document
fragment. Following is an example of an HTML link that uses a relative URI to link
to a document named fruit.html:
Click <a href=”fruit.html”>here</a> for
fruit!
This code assumes the document fruit.html is located in the same
path as the document in which the code appears. If you want to link to a document
located somewhere else, you’ll probably take advantage of a full URI, like this:
Click <a href=”http://www.michaelsgroceries.com/veggies.html”>here</a>
for veggies!
Document fragments are a little more interesting in terms of how they are linked
in HTML. When linking to a document fragment, the href attribute
uses a pound symbol (#) in between the URI and the fragment identifier. The
following is an example of how you create an HTML link to a specific location
within a document:
Click <a href=”fruit.html#bananas”>here</a>
for bananas!
In this code, the fragment identifier bananas is used to identify a portion of the
fruit.html document. You associate a fragment identifier with a portion of a document
using the anchor element (a) and the id attribute in the link target. This attribute
value is the name used to the right of the pound symbol (#) in the anchor element that
serves as the link source. Following is an example of an HTML link that establishes a
banana document fragment for a link target:
<a id=”bananas”>We have the freshest bananas for $0.99
per pound.</a>
This code shows how a sentence of text can be marked as a link target by setting the id attribute of the a tag with a unique fragment identifier.
HTML links are both very useful and very easy to create. Simply based on the power and usefulness of the Web, it’s hard to make an argument against the strength of HTML’s simplistic approach to linking documents. However, there are many ways that it can be improved, some of which you might have never thought about. For one, it would be nice if links could be bidirectional, which means that you wouldn’t be dependent on a browser’s implementation of a Back button in order to navigate backwards to a previous resource. Although this may seem trivial, it could be extremely useful to be able to traverse a link in either direction, thereby eliminating the need for fixed source and target resources. A bidirectional link would treat the two resources as both sources and targets depending on the context.
In addition to bidirectional links, it could be extremely beneficial to have links that reference multiple target resources. This would keep web developers from having to duplicate content for the sole purpose of providing link sources. More specifically, a link with multiple targets could present a pop-up menu with the target selections from which the user selects. An example of this type of link might be a book listing on Amazon.com. A multiple-target link for the cover image of a book could present a pop-up menu containing links to documents such as a book summary, reviews, and a sample chapter. This tightens up the user interface for the web site by reducing the content used purely for navigational purposes. It also provides a logical grouping of related links that would otherwise be coded as unrelated links using HTML anchors.
If your only exposure to document linking is HTML, you probably regard link resources as existing completely separate of one another, at least in terms of how they are displayed in a web browser. XML links shatter this notion by allowing you to use links to embed resources within other resources. In other words, the contents of a target resource can be inserted in place of the link in a source document. Granted, images are handled much like this in HTML already, but XML links offer the possibility of embedding virtually any kind of data in a document, not just an external image. Traversing embedded links in this manner ultimately results in compound documents that are built out of other resources, which has some interesting implications for the Web. For example, you could build a news web page out of paragraphs of text that are dynamically pulled from other documents around the web via links.
Speaking of link traversal, HTML links are limited in that the user must trigger their traversal. For example, the only way to invoke a link on a web page is to click the linked text or image, as shown in Figure 22.2.
You may be wondering why it would be desirable to have it any other way. Well, consider the situation where a linked resource is to be embedded directly in a document to form a compound document. You might want the embedding to take place immediately upon opening the document, in which case the user would have nothing to do with the link being invoked. In this sense, the link is serving as a kind of connective tissue for components of a compound web document (see Figure 22.3), which is far beyond the role of links in HTML. Again, images already work like this in HTML via the img tag, but XML links open the door for many other possibilities with flexible linking.
As you’re starting to see, XML links, which are made possible by the XLink technology, are much more abstract than HTML links, and therefore can be used to serve more purposes than just providing users a way of moving from one web page to the next. Admittedly, you almost have to take a few steps back and think of links in a more abstract sense to fully understand what XML links are all about. The up side to this shift in thinking is that when the significance of XLink fully sinks in, you will probably view the web quite differently.
Yet another facet of XLink worth pointing out is its support for creating links that reside outside of the documents they link. In other words, you can create a link in one document that connects two resources contained in other documents (see Figure 22.4). This can be particularly useful when you don’t have the capability of editing the source and target documents. These kinds of links are known as out-of-line links and will probably foster the creation of link repositories. A link repository is a database of links that describe useful connections between resources on the Web.
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.
| home / programming / xml_24 / 1 | [previous] |
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers
Created: March 27, 2003
Revised: December 12, 2005
URL: http://webreference.com/programming/xml_24/1
