Book HomeJava and XML, 2nd Edition

Chapter 16. Looking Forward

Contents:

XLink
XPointer
XML Schema Bindings
And the Rest. . .
What's Next?

It's almost time to wrap up the journey through Java and XML. I hope you've had fun. Before I leave you to mull over all the possibilities, I want to finish up with a little crystal-ball gazing. Like any good programmer, I always try and outguess the technology space and be ahead of the curve. This usually involves knowing more than just cursory information about a whole lot of technologies, so I can easily get up to speed when something breaks. In this chapter, I'm going to point out some of the interesting things coming up over the horizon, and let you in on some extra knowledge on each. I'll be the first to admit that some of these guesses may be completely off; others may be the next big thing. Take a look at each, and then be ready to react when you see where they might fit into your applications.[28]

[28]Many of the sections within this chapter are based in whole or in part on articles and tips I have written for the IBM DeveloperWorks online publication, located at http://www.ibm.com/developer. Thanks to Nancy Dunn and the kind folks at IBM for letting me update and reprint parts of those articles.

16.1. XLink

First on my list of up-and-coming stars in the XML world is XLink. XLink defines an XML linking mechanism for referring to other documents. For those of you who are HTML authors, this may sound like the "a" element you are used to:

<a href="http://www.nickelcreek.com">Check out Nickel Creek!</a>.

However, XLink offers much more than simply unidirectional (one-way) linking. Using XLink, you can create bidirectional links, define how links are processed, and most importantly, allow linking from any XML element (instead of just the "a" element). For all these reasons, it's worth getting into here.

Example 16-1 is a small XML document, representing a few of my guitars.

Example 16-1. XML document using XLink

<?xml version="1.0"?>

<guitars xmlns="http://www.newInstance.com/about/guitars"
         xmlns:xlink="http://www.w3.org/1999/xlink">
 <guitar luthier="Bourgeois"
          xlink:type="simple"
          xlink:href="http://www.newInstance.com/about/guitars/bourgeoisOM">
  <descripton xlink:type="simple"  
              xlink:href="http://www.newinstance.com/pics/bougOM_front_full.jpg"
              xlink:actuate="onLoad" xlink:show="embed">
  This is a real beauty in a small body. Although this is an OM, I use it for
  flatpicking bluegrass as well as for producing some beautiful fingerstyle sounds.
  </description>
 </guitar>
 <guitar luthier="Bourgeois"
          xlink:type="simple"
          xlink:href="http://www.newInstance.com/about/guitars/bourgeoisD150">
  <descripton xlink:type="simple"
              xlink:href="http://www.newinstance.com/pics/bougd150_con_rim2.jpg"
              xlink:actuate="onLoad" xlink:show="embed">
   Here's the holy grail in process. Dana Bourgeois is building this Brazilian 
  rosewood and adirondack bluegrass monster right now... you'll know it's 
  finished when you hear a run and your windows shatter!
  </description>
 </guitar>
</guitars>

First, you'll notice that I reference the XLink namespace, so that the document has access to the XLink attributes and features. Second, I'm going to cover only XLinks of the "simple" type, specified by the xlink:type attribute. That's because browser support for XLinks is minimal, found only in Mozilla and Netscape 6 (I haven't been able to test IE 6.0, but 5.5 has no support for them), so keeping to the basic aspects will serve you well.

Once the formalities are out of the way, XLinking just requires using some attributes on the elements that have links. Take my document's guitar element. It specifies a luthier for each guitar (that's a guitar maker for those of you who are missing out on guitar playing!). I already mentioned the use of the xlink:type attribute, which is set to the value "simple". It then specifies a URL to link to using XLink. To specify this URL, it uses the xlink:href attribute. So far, this looks a lot like HTML. No big deal, right? By default (assuming browser support, of course), this will set the link up to replace the current window when clicked upon. 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.

Of course, this only covers basic linking. Things get more interesting when you want to access remote locations as resources, such as linking in images. Look at the description element; this sets the value of the xlink:show attribute to "embed". The resource, in this case an image file showing the guitar being described, should be processed inline within the page. This instructs an XLink-aware browser to insert the specified document inline within the XML. It becomes really interesting when you consider this could be another XML document, and not just an image.

Taking things even further, you can specify when the resource should be shown. This is handled by the xlink:actuate attribute. It defines when the resource is read and shown. When the value is "onLoad", as it is in Example 16-1, the resource should be loaded when the initial document is loaded. You could also specify the value "onRequest", which means that until the link is clicked, the resource is not shown. This is handy for keeping bandwidth low, allowing the user to view only the resources that they want to see.

XLink could definitely have major impact on the next generation of XML documents. For the complete specification, check out http://www.w3.org/TR/xlink. I'd also keep an eye on the latest browsers and versions to see when complete XLink support shows up.



Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.