![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Since the release of XML in early 1998, interest in XML has continued to grow. There are an enormous number of XML-related specifications in use today: XPointer, XLink, XSD (XML Schema), RDF, RSS, and XHTML, to name a few. In this tip, I'll explore XLink, a particularly useful specification that defines an XML linking mechanism for referring to other XML documents.
For those of you who are HTML authors, XLink may sound a lot like the a element
that you have used hundreds of times before, as in
<a href="http://www.nickelcreek.com">Check out Nickel Creek!</a>.
This sort of link is referred to as a unidirectional link. That simply means that it goes from your page to
the target page (Nickel Creek's Web site in this example), but not from that site back to yours.
XLink offers much more than unidirectional linking, though. Using XLink, you can create bidirectional links, which allow travel in two directions..
You can also define how links are processed, and, most importantly, you can allow linking from
any XML element. This is quite an improvement over only being able to use
the a element. For all of these reasons, XLink is worth taking some time to look at.
Let me start by showing you a small XML document that represents a few acoustic guitars: Listing 1.
In the listing, you'll notice that I reference the XLink namespace so that the document has access to the
XLink attributes and features. Second, I only used XLinks of the "simple" type, specified by the
xlink:type attribute. You can also specify "extended", "locator", "arc", "resource",
"title", and "none" for this value; however, I have avoided these more complex types.
That's because browser support for XLinks is currently minimal; you will find some support in Mozilla 0.98 and Netscape 6.02,
and even less in Internet Explorer 6.0. Earlier versions of all of these browsers had no XLink support at all. I would
recommend that you experiment with only the basics now, and then move to more advanced features when browsers catch up with the XLink specification.
With Listing 1, you've got some basic XML to work with. To take advantage of XLink, all you have to do is use
XLink-specific attributes on the elements that contain links. Look at Listing 1's guitar
element, which specifies a luthier (that's a guitar maker) for each guitar. I already discussed the use of the
xlink:type attribute, which is set to the value "simple". The element then specifies a
URL to link to using XLink. To specify this URL, the element uses the xlink:href attribute.
At this point, you're probably thinking "No big deal -- this looks a lot like HTML." Well, you're absolutely
right about that! By default, this XLink will set up the link to replace the current window when the link is
clicked. If you want the target of the link to open in a new window, you can add the
xlink:show attribute, and give it a value of "new"; the default is "replace",
which is normal HTML behavior. You'll recognize xlink:show as similar to specifying
a different target window in HTML. And, as easily as that, you are using XLink.
Up to this point, I've covered only basic linking. Things get more interesting when you want to access remote
locations as resources, instead of standalone pages. Look at the description element in Listing 1.
It sets the value of the xlink:show attribute to "embed". This means that the resource
(an image file in this case) should be processed inline within the page. This instructs an XLink-aware browser to
insert the specified document within the XML, rather than opening the resource in a new window. When you consider
that this could be another XML document and not just an image, the possibilities really begin to open up; for example, you could
have a hierarchy of XML documents, each building upon and referring to others.
Going even further, you can specify when the resource should appear. The timing is handled by the
xlink:actuate attribute, which defines when the resource is "read" and shown.
When the value is "onLoad", as it is in Listing 1, the resource should be loaded when the initial document loads,
and it should be shown then as well. This is similar to how normal HTML resource loading works.
You can also specify the value "onRequest" for the attribute, which means that until the link is clicked,
the resource is not shown. This is handy for low-bandwidth settings, allowing users to only access
resources when they choose (through a mouse click).
I know this has been a short and simple look at XLink, but it should give you a good start. For more on XLink, check out the specification in Resources. You should also keep an eye on feature lists for new browser support for XLink, and once XLink is supported, have at it!
- For more on XLink, check out the XLink specification.
- While you're at it, check out XPointer, which adds even more advanced linking to XLink.
- Bone up on your XML with Doug Tidwell's tutorial on XML, "Introduction to XML" (developerWorks, August 2002 ).
Brett McLaughlin (brett@newinstance.com) works as Enhydra strategist at Lutris Technologies and specializes in distributed systems architecture. He is author of Java and XML (O'Reilly). He is involved in technologies such as Java servlets, Enterprise JavaBeans technology, XML, and business-to-business applications. Along with Jason Hunter, he founded the JDOM project, which provides a simple API for manipulating XML from Java applications. He is also an active developer on the Apache Cocoon project and the EJBoss EJB server as well as a co-founder of the Apache Turbine project.
