From owner-xml-l@LISTSERV.HEA.IE Thu Apr 2 15:09:35 1998 Date: Thu, 2 Apr 1998 15:59:36 -0500 From: "Eve L. Maler" <elm@ARBORTEXT.COM> Subject: Re: XML - Total Package
At 10:14 AM 4/2/98 -0500, Kaiman, Charlie wrote:
>Finally, I have heard much about XLL ("tech-talk"), but can't really >conceptualize it. Would someone be willing to offer a helping hand in that >area, as well?
We've been remiss in not getting the word out on XLink and what it's all about... I hope this short message will help for the moment. Beware that I'm using the time-honored principle that "A little inaccuracy saves tons of explanation."
XLink (the new name) is a package of hyperlinking functionality that comes in two parts: the "XLink" component (http://www.w3.org/TR/WD-xlink) allows links in your XML documents to be recognized as such, and the "XPointer" component (http://www.w3.org/TR/WD-xptr) allows your links to address into precise sub-parts of an XML document. In other words:
XLink is needed, first of all, because in an XML document you can use whatever element names you want. In HTML, it's predetermined that A and IMG (and a couple of others) do link-ish things, but software can't predict ahead of time what the linking elements will be called in an XML document: FOOTNOTE? ANNOTATION? RELATIONSHIP? CROSS-REFERENCE? So you have to put a "marker" (in the form of a special attribute) on your element in order for XLink-aware applications to recognize it.
In addition to this innovation, however, XLink does another important job, which is invent a whole new form of link. In HTML, A is a two-ended, unidirectional link: you click from here to go there. In XML, this would be a "simple link," but you can also have a 318-ended "extended link" where you can start from any one of the ends and go to any of the others. And on top of this, the link doesn't have to be stuck into *any one* of those 318 pieces of content! This means that you can store the linking information outside all the information that you're hooking together, so you can update your link if one of the 318 chunks changes in any way.
Here's an example of a plain vanilla ("simple") XLink linking element that functions just like an HTML A element (using syntactic details from the 19980303 working draft; this is highly likely to change a bit in the next draft). In fact, this example is actually an XMLified HTML fragment:
See <a xml:link="simple" href="http://www.arbortext.com">our home page</a> for more cool information.
Now, on to XPointer. If you use HTML's A to point into an HTML document, your choices are:
Often, it's useful to point to some actual content, instead of a "spot." For example, you might want to direct your readers' attention to the third item in a particular list, or a certain stretch of text in the equivalent of a PRE element. When the content of interest is in an XML document, then you can rely on XML's natural tree structure to provide signposts that you can use in navigating to the right stuff.
XPointer is a little mini-language that you can stick on the end of a URL after the #, in the case where the URL points to an XML document. It uses a keyword-and-arguments syntax like this:
For example, if you want to link to the third item in the list with a unique ID of "interesting-list", you can do it this way:
There's a whole boatload of keywords, and some of their arguments can get a bit complicated, but that's the basic idea. The best part about XPointer is that, if you do addressing this way, your link will probably be more robust against some change in the target document. For example, even if the target list is cut and pasted somewhere else, the fact that it has a unique ID will keep your link operational. (Now, if someone rearranges the items, that's another story.)
If folks have additional questions, I would be happy to try to field them (time permitting), and there's also been some talk of starting an XLink FAQ, so we could use your questions as fodder.