Chapter 10. XLinks

CONTENTS

  •  10.1 Simple Links
  •  10.2 Link Behavior
  •  10.3 Link Semantics
  •  10.4 Extended Links
  •  10.5 Linkbases
  •  10.6 DTDs for XLinks

XLinks are an attribute-based syntax for attaching links to XML documents. XLinks can be simple Point A-to-Point B links, like the links you're accustomed to from HTML's A element. XLinks can also be bidirectional, linking two documents in both directions so you can go from A to B or B to A. XLinks can even be multidirectional, presenting many different paths between any number of XML documents. The documents don't have to be XML documents XLinks can be placed in an XML document that lists connections between other documents that may or may not be XML documents themselves. Web graffiti artists take note: these third-party links let you attach links to pages you don't even control, like the home page of the New York Times or the C.I.A. At its core XLink is nothing more and nothing less than an XML syntax for describing directed graphs, in which the vertices are documents at particular URIs and the edges are the links between the documents. What you put in that graph is up to you.

Current web browsers at most support simple XLinks that do little more than duplicate the functionality of HTML's A element. Many browsers don't support XLinks at all. However, custom applications may do a lot more. Since XLinks are so powerful, it shouldn't come as a surprise that they can do more than blue underlined links on web pages. XLinks can describe tables of contents or indexes. They can connect textual emendations to the text they describe. They can indicate possible paths through online courses or virtual worlds. Different applications will interpret different sets of XLinks differently. Just as no one browser really understands the semantics of all the various XML applications, so too no one program can process all collections of XLinks.

10.1 Simple Links

A simple link defines a one-way connection between two resources. The source or starting resource of the connection is the link element itself. The target or ending resource of the connection is identified by a Uniform Resource Identifier (URI). The link goes from the starting resource to the ending resource. The starting resource is always an XML element. The ending resource may be an XML document, a particular element in an XML document, a group of elements in an XML document, a span of text in an XML document, or something that isn't a part of an XML document, such as an MPEG movie or a PDF file. The URI may be something other than a URL, for instance a book ISBN number like urn:isbn:1565922247.

A simple XLink is encoded in an XML document as an element of arbitrary type that has an xlink:type attribute with the value simple and an xlink:href attribute whose value is the URI of the link target. The xlink prefix must be mapped to the http://www.w3.org/1999/xlink namespace URI. As usual, the prefix can change as long as the URI stays the same. For example, suppose this novel element appears in a list of children's literature and we want to link it to the actual text of the novel available from the URL ftp://archive.org/pub/etext/etext93/wizoz10.txt.

<novel>   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year> </novel>

We give the novel element an xlink:type attribute with the value simple, an xlink:href attribute that contains the URL to which we're linking, and an xmlns:xlink attribute that associates the prefix xlink with the namespace URI http://www.w3.org/1999/xlink. The result is this:

<novel xmlns:xlink= "http://www.w3.org/1999/xlink"        xlink:type = "simple"        xlink:href = "ftp://archive.org/pub/etext/etext93/wizoz10.txt">   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year> </novel>

This establishes a simple link from this novel element to the plain text file found at ftp://archive.org/pub/etext/etext93/wizoz10.txt. Browsers are free to interpret this link as they like. However, the most natural interpretation, and the one implemented by the few browsers that do support simple XLinks, is to make this a blue underlined phrase the user can click on to replace the current page with the file being linked to. Other schemes are possible however.

XLinks are fully namespace aware. The xlink prefix is customary, though it can be changed. However, it must be mapped to the URI http://www.w3.org/1999/xlink. This can be done on the XLink element itself, as in this novel example, or it can be done on any ancestor of that element up to and including the root element of the document. Future examples in this and the next chapter use the xlink prefix exclusively and assume that this prefix has been properly declared on some ancestor element.

Every XLink element must have an xlink:type attribute telling you what kind of link (or part of a link) it is. This attribute has six possible values:

  • Simple

  • Extended

  • Locator

  • Arc

  • Title

  • Resource

Simple XLinks are the only ones that are really similar to HTML links. The remaining five kinds of XLink elements will be discussed in later sections.

The xlink:href attribute identifies the resource being linked to. It always contains a URI. Both relative and absolute URLs can be used, as they are in HTML links. However, the URI need not be a URL. For example, this link identifies but does not locate the print edition of The Wonderful Wizard of Oz with the ISBN number 0688069444:

<novel xmlns:xlink= "http://www.w3.org/1999/xlink"        xlink:type = "simple"        xlink:href = "urn:isbn:0688069444">   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year> </novel>

10.2 Link Behavior

So far, we've been careful to talk in the abstract. We've said that an XLink describes a connection between two resources, but we haven't said much about how that connection is presented to the end user or what it makes software reading the document do. That's because there isn't one answer to these questions. For instance, when the browser encounters a novel element that uses an http URL, clicking the link should probably load the text of the novel from the URL into the current window, thereby replacing the document that contained the link. Then again, maybe it should open a new window and show the user the new document in that window. The proper behavior for a browser encountering the novel element that uses an isbn URN is even less clear. Perhaps it should reserve the book with the specified ISBN at the local library for the user to walk in and pick up. Or perhaps it should order the book from an online bookstore. In other cases something else entirely may be called for. For instance, the content of some links are embedded directly in the linking document, as in this image element:

<image width="152" height="345" xlink:type="simple"        xlink:href="http://www.turing.org.uk/turing/pi1/bus.jpg" />

Here, the author most likely intends the browser to download and display the image as soon as it finds the link. And rather than opening a new window for the image or replacing the current document with the image, the image should be embedded into the current document.

Just as XML is more flexible than HTML in the documents it describes, so too is XLink more flexible in the links it describes. An XLink indicates that there's a connection between two documents, but it's up to the application reading the XLink to decide what that connection means. It's not necessarily a blue, underlined phrase on which the user clicks in a browser to jump from the first source document to the target. It may indeed be that, just as an XML document may be a web page, but it may be something else too.

Page authors can offer suggestions to browsers about how links should be handled by using the xlink:show and xlink:actuate attributes. The xlink:show attribute tells a browser or other application what to do when the link is activated, for example, whether to show the linked content in the same window or to open a new window to display it. The xlink:actuate attribute tells the browser when to show the content, for example, whether it should follow the link as soon as it sees it or whether it should wait for an explicit user request.

10.2.1 xlink:show

The optional xlink:show attribute has five possible values that suggest in what context the application loading an XLinked resource should display that resource:

new

Open a new window and show the content of the link's URI (the ending resource) in that window.

replace

Show the ending resource in the current window, replacing the current document.

embed

Embed the ending resource in the current document at the location of the link element.

other

Exhibit some behavior other than opening a new window, replacing the document in the existing window or embedding the resource in the existing document. Exactly what that behavior is may be specified by other, nonstandard markup that a particular application understands.

none

Specify no behavior.

All five of these are only suggestions that browsers or other applications following XLinks are free to ignore. For example, a web spider would not open a window for any link and might ignore embedded links and treat the other four types identically. Mozilla might open a new tab in an existing window for xlink:show="new" rather than creating a completely new window. This is all allowed as long as it makes sense in the context of the application.

10.2.2 xlink:actuate

The optional xlink:actuate attribute has four possible values, which suggest when an application that encounters an XLink should follow it:

onLoad

The link should be followed as soon as the application sees it.

onRequest

The link should be followed when the user asks to follow it.

other

When to follow the link is determined by other markup in the document not specified by XLink.

none

No details are available about when or whether to follow this link. Indeed, following the link may not have any plausible meaning as in the previous example where the link pointed to a book's ISBN number rather than a URL where the book could be found.

All four of these are only suggestions that browsers or other applications following XLinks are free to ignore. For example, a web spider would use its own algorithms to decide when to follow and not follow a link. Differing behavior when faced with the same attributes is allowed as long as it makes sense for the application reading the document.

For example, a traditional link such as is provided by HTML's A element and indicated by the first novel example would be encoded like this:

<novel xlink:type="simple"        xlink:href="ftp://archive.org/pub/etext/etext93/wizoz10.txt"        xlink:actuate="onRequest" xlink:show="replace">   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year> </novel>

This says to wait for an explicit user request to follow the link (e.g., clicking on the content of the link) and then to replace the existing document with the document found at ftp://archive.org/pub/etext/etext93/wizoz10.txt. On the other hand, if you were using XLinks to embed images in documents, you'd want them traversed immediately and then embedded in the originating document. The following syntax would be appropriate:

<image xlink:type="simple"        xlink:actuate="onLoad" xlink:show="embed"        xlink:href="http://www.turing.org.uk/turing/pi1/bus.jpg"        width="152" height="345" />

Both xlink:show and xlink:actuate are optional. An application should be prepared to do something reasonable if they're missing.

10.3 Link Semantics

A link describes a connection between two resources. These resources may or may not be XML documents, but even if they are XML documents, the relationships they have with each other can be quite varied. For example, links can indicate parent-child relationships, previous-next relationships, employer-employee relationships, customer-supplier relationships, and many more. XLink elements can have xlink:title and xlink:role attributes to specify the meaning of the connection between the resources. The xlink:title attribute contains a small amount of plain text describing the remote resource such as might be shown in a tooltip when the user moves the cursor over the link. The xlink:role attribute contains a URI. This points to something that somehow describes or annotates the remote resource. For instance, it might indicate the MIME media type of the remote resource by pointing to a registration page for the type at the Internet Assigned Numbers Authority (IANA), such as http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml.

For example, the xlink:title attribute of this novel element specifies that the text comes from Project Gutenberg, while the xlink:role attribute points to the Project Gutenberg home page.

<novel xlink:type="simple"  xlink:href="ftp://archive.org/pub/etext/etext93/wizoz10.txt"  xlink:title= "The complete text of the novel from Project Gutenberg"  xlink:role="http://promo.net/pg/" >   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year> </novel>

As with almost everything else related to XLink, exactly what browsers or other applications will do with this information or how they'll present it to readers remains to be determined.

10.4 Extended Links

Whereas a simple link describes a single unidirectional connection between one XML element and one remote resource, an extended link describes a collection of resources and a collection of paths between those resources. Each path connects exactly two resources. Any individual resource may be connected to one of the other resources, two of the other resources, zero of the other resources, all of the other resources, or any subset of the other resources in the collection. It may even be connected back to itself. In computer science terms, an extended link is a directed, labeled graph in which the paths are arcs, the documents are vertices, and the URIs are labels.

Simple links are very easy to understand by analogy with HTML links. However, there's no obvious analogy for extended links. What they look like, how applications treat them, what user interfaces present them to people, is all up in the air. No simple visual metaphors like "click on the blue underlined text to jump to a new page" have been invented for extended links, and no browsers support them. How they'll be used and what user interfaces will be designed for them remains to be seen.

In XML, an extended link is represented by an extended link element, that is, an element of arbitrary type that has an xlink:type attribute with the value extended. For example, this is an extended link element that refers to the novel The Wonderful Wizard of Oz:

<novel xlink:type="extended">   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year> </novel>

Although this extended link is quite Spartan, most extended links contain local resources, remote resources, and arcs between those resources. A remote resource is represented by a locator element, that is, an element of any type that has an xlink:type attribute with the value locator. A local resource is represented by a resource element, that is, an element of any type that has an xlink:type attribute with the value resource. And an arc between two resources, whether local or remote, is represented by an arc element, that is, an element of any type that has an xlink:type attribute with the value arc.

10.4.1 Locators

Each locator element has an xlink:type attribute with the value locator and an xlink:href attribute containing a URI for the resource it locates. For example, this novel element for The Wonderful Wizard of Oz contains three locator elements that identify particular editions of the book:

<novel xlink:type = "extended">   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year>   <edition xlink:type="locator" xlink:href="urn:isbn:0688069444" />   <edition xlink:type="locator" xlink:href="urn:isbn:0192839306" />   <edition xlink:type="locator" xlink:href="urn:isbn:0700609857" /> </novel>

Most of the time each locator element also has an xlink:label attribute that serves as a name for the element. The value of this attribute can be any XML name that does not contain a colon (i.e., that does not have a namespace prefix). For instance, in the previous example, we could add labels based on the ISBN number like this:

<novel xlink:type = "extended">   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year>   <edition xlink:type="locator" xlink:href="urn:isbn:0688069444"                                 xlink:label="ISBN0688069444"/>   <edition xlink:type="locator" xlink:href="urn:isbn:0192839306"                                 xlink:label="ISBN0192839306"/>   <edition xlink:type="locator" xlink:href="urn:isbn:0700609857"                                 xlink:label="ISBN0700609857"/> </novel>

The number alone cannot be used because XML names cannot start with digits. In this and most cases, the labels are unique within the extended link, but they don't absolutely have to be.

Locators may also have the optional semantic attributes xlink:title and xlink:role to provide more information about the remote resource. These attributes have the same meanings they have for simple XLinks. The xlink:title attribute contains a small amount of text describing the remote resource, and the xlink:role attribute contains an absolute URI that somehow describes or annotates the remote resource. For instance, the edition elements could provide the publisher's name and URL using these attributes like this:

<novel xlink:type = "extended">   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year>   <edition xlink:type="locator" xlink:href="urn:isbn:0688069444"            xlink:title="William Morrow"            xlink:role="http://www.williammorrow.com/"            xlink:label="ISBN0688069444"/>   <edition xlink:type="locator" xlink:href="urn:isbn:0192839306"            xlink:title="Oxford University Press"            xlink:role="http://www.oup-usa.org/"            xlink:label="ISBN0192839306"/>   <edition xlink:type="locator" xlink:href="urn:isbn:0700609857"            xlink:title="University Press of Kansas"            xlink:role="http://www.kansaspress.ku.edu/"            xlink:label="ISBN0700609857"/> </novel>

10.4.2 Arcs

Paths between resources are called arcs, and they are represented by arc elements, that is, elements of arbitrary type that have an xlink:type attribute with the value arc. Each arc element should have an xlink:from attribute and an xlink:to attribute. The xlink:from attribute identifies the source of the link . The xlink:to attribute identifies the target of the link. These attributes do not contain URIs as you might expect. Rather they contain a name matching the value of the xlink:label attribute of one of the locator elements in the extended link.

Example 10-1 shows an extended link that contains the first three novels in the Wizard of Oz series: The Wonderful Wizard of Oz, The Marvelous Land of Oz, and Ozma of Oz. Arcs connect the first book in the series to the second and the second to the third, and then back again. In this example, the root series element is the extended link element; each novel element is a locator element; and the next and previous elements are arc elements.

Example 10-1. An extended link with three locators and four arcs
<series xlink:type="extended" xmlns:xlink="http://www.w3.org/1999/xlink">   <author>L. Frank Baum</author>   <!-- locator elements -->   <novel xlink:type="locator" xlink:label="oz1"          xlink:href="ftp://archive.org/pub/etext/etext93/wizoz10.txt">     <title>The Wonderful Wizard of Oz</title>     <year>1900</year>   </novel>   <novel xlink:type="locator" xlink:label="oz2"          xlink:href="ftp://archive.org/pub/etext/etext93/ozland10.txt">     <title>The Marvelous Land of Oz</title>     <year>1904</year>   </novel>   <novel xlink:type="locator" xlink:label="oz3"          xlink:href="ftp://archive.org/pub/etext/etext93/wizoz10.txt">     <title>Ozma of Oz</title>     <year>1907</year>   </novel>   <!-- arcs -->   <next     xlink:type="arc" xlink:from="oz1" xlink:to="oz2" />   <next     xlink:type="arc" xlink:from="oz2" xlink:to="oz3" />   <previous xlink:type="arc" xlink:from="oz2" xlink:to="oz1" />   <previous xlink:type="arc" xlink:from="oz3" xlink:to="oz2" /> </series>

Figure 10-1 diagrams this extended link. Resources are represented by books. Arcs are represented by arrows. However, although we can understand this link in this sort of abstract sense, this doesn't really tell us anything about how a browser might present it to a user and how users might choose which links to follow. For instance, this extended link might be interpreted as nothing more than a list of the order in which to print these documents. All details of interpretation are left up to the application.

Figure 10-1. An extended link with three resources and four arcs between them

figs/xian2_1001.gif

10.4.2.1 Multiple arcs from one arc element

On occasion a single arc element defines multiple arcs. If multiple elements share the same label, then an arc element that uses that label in either its xlink:to or xlink:from attribute defines arcs between all resources that share that label. Example 10-2 shows an extended link containing locator elements for three different online bookstores and one edition of The Wonderful Wizard of Oz. Each bookstore element has the label buy, and a single purchase arc element connects all of these. Figure 10-2 shows the graph structure of this extended link.

Example 10-2. An extended link with one arc element but three arcs
<book xlink:type="extended" xmlns:xlink="http://www.w3.org/1999/xlink">   <author>L. Frank Baum</author>   <title>The Wonderful Wizard of Oz</title>   <!-- locator elements -->   <edition xlink:type="locator" xlink:href="urn:isbn:0192839306"            xlink:title="Oxford University Press"            xlink:role="http://www.oup-usa.org/"            xlink:label="ISBN0192839306"/>   <store xlink:type="locator"          xlink:href="http://www.amazon.com/exec/obidos/ASIN/0192839306"          xlink:label="buy">Amazon</store>   <store xlink:type="locator" xlink:href=    "http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0192839306"     xlink:label="buy">Fatbrain</store>   <store xlink:type="locator" xlink:href= "http://shop.bn.com/booksearch/isbninquiry.asp?isbn=0192839306"     xlink:label="buy">Barnes &amp; Noble</store>   <!-- arcs -->   <purchase xlink:type="arc" xlink:from="ISBN0192839306" xlink:to="buy" /> </book>
Figure 10-2. One arc element can generate several arcs

figs/xian2_1002.gif

If an arc element does not have an xlink:to attribute, then it uses all the resources in the extended link as sources. If an arc element does not have an xlink:from attribute, then it uses all the resources in the extended link as targets.

However, it is an error for more than one arc element to define an arc between the same two resources, whether implicitly or explicitly. For example, if an extended link contains N resources and an arc element such as <edition xlink:type="arc"/> with neither an xlink:to or xlink:from attribute, then it cannot contain any other arc elements because this one arc element defines all N2 possible arcs between the resources in the extended link.

10.4.2.2 Arc titles

Each arc element may optionally have an xlink:title attribute, just like all other XLink elements. This contains a small amount of text describing the arc intended for humans to read. For instance, in Example 10-1, we might give these titles to the arcs:

<next     xlink:type="arc" xlink:from="oz1" xlink:to="oz2"           xlink:title="Next" /> <next     xlink:type="arc" xlink:from="oz2" xlink:to="oz3"           xlink:title="Next" /> <previous xlink:type="arc" xlink:from="oz2" xlink:to="oz1"           xlink:title="Previous" /> <previous xlink:type="arc" xlink:from="oz3" xlink:to="oz2"           xlink:title="Previous" />

When processing an extended link, a browser might show the title to the user as the contents of a link so they could choose which arc they wanted to follow from their current position, or they might appear in a pop-up menu when the user was on one of the referenced pages. XLink does not require or suggest any specific user interface for arcs or arc titles.

10.4.2.3 Arc roles

Arc elements cannot have xlink:role attributes. However, an arc element can have an xlink:arcrole attribute that contains an absolute URI pointing to a description of the arc. More specifically, this URI should point to a resource that indicates which relationship the arc describes (e.g., parent-child, employer-employee). However, there's really no way to validate this at all beyond checking to see that xlink:arcrole does contain a legal URI (and even that is not strictly required). For instance, in Example 10-2 we might add an xlink:arcrole attribute to the purchase arc that pointed to the URL http://www.example.com/purchase_details.txt.

<purchase xlink:type="arc" xlink:from="ISBN0192839306" xlink:to="buy"           xlink:arcrole="http://www.example.com/purchase_details.txt" />

The file purchase_details.html might then contain the text "will be bought from." This would indicate that the source of the link is bought from the target of the link; that is, "The Wonderful Wizard of Oz will be bought from Amazon," or "The Wonderful Wizard of Oz will be bought from Fatbrain," or "The Wonderful Wizard of Oz will be bought from Barnes & Noble." However, although this usage is suggested, XLink processors will not enforce it, and indeed there's really no way they could be asked to do this since that would require that they actually understand what they read. The xlink:arcrole attribute is optional. You don't have to include it on your arcs, and XLink processors don't have to do anything with it even if you do.

10.4.3 Local Resources

Locators represent remote resources, that is, resources that are not part of the document that contains the extended link. Extended links can also contain local resources in which the data is contained inside the extended link element. Each such resource is represented by a resource element. This is an element of arbitrary type that has an xlink:type attribute with the value resource. For instance, in Example 10-1 the series extended link element contains an author child element. This can easily be made a local resource simply by giving it an xlink:type="resource" attribute:

<author xlink:type="resource">L. Frank Baum</author>

A resource element can and generally does have the same attributes as a locator element, that is, xlink:label , xlink:role, and xlink:title. These all have the same semantics as they do for locator elements. For instance, the label is a name arcs use to connect resources. An arc can connect a resource to a resource, a resource to a locator, a locator to a resource, or a locator to a locator. Arcs really don't care whether resources are local or remote. To link to or from this resource, it needs an xlink:label attribute like this:

<author xlink:type="resource" xlink:label="baum">L. Frank Baum</author>

To establish links from this local resource to all the books, we'd simply add these three arc elements:

<book xlink:type="arc" xlink:from="baum" xlink:to="oz1" /> <book xlink:type="arc" xlink:from="baum" xlink:to="oz2" /> <book xlink:type="arc" xlink:from="baum" xlink:to="oz3" />

To move in the other direction, you'd simply reverse the values of the xlink:from and xlink:to attributes.

10.4.4 Title Elements

As you've seen, extended link elements, locator elements, arc elements, and resource elements can all have xlink:title attributes that provide a short blurb of text identifying the link. However, this isn't always enough. For instance, in a document that was a rather large extended link, you might want to mark up the titles using XHTML or some other vocabulary. To this end, a title can instead (or in addition) be provided as a title type child element, that is, an element whose xlink:type attribute has the value title.

For example, suppose you wanted to provide a more complete description of each edition of The Wonderful Wizard of Oz than simply who published it. Then you would give the edition element a title type element containing any convenient markup like this:

<edition xlink:type="locator" xlink:href="urn:isbn:0700609857"          xlink:title="University Press of Kansas"          xlink:role="http://www.kansaspress.ku.edu/"          xlink:label="ISBN0700609857">   <publisher_info xlink:type="title">     <ul>       <li>The Kansas Centennial Edition</li>       <li>Illustrated by Michael McCurdy</li>       <li>Foreword by Ray Bradbury</li>       <li>1999</li>       <li>216 pages</li>       <li>SRP: $24.95</li>     </ul>   </publisher_info> </edition>

What markup you use inside the title element is up to you as long as it's well-formed XML. XLink doesn't constrain it in any way. How the application interprets that markup is its own business. Here we've used basic HTML that a browser might perhaps be able to render. Once again, however, this is far enough past the bleeding edge that exact browser behavior, even when browsers do support extended XLinks, is hard to predict.

10.5 Linkbases

One of the most revolutionary features of XLinks is the ability to define links between documents you don't control. For instance, Example 10-1 is an extended link that describes and links three documents neither of the authors of this book has anything to do with. Links between purely remote resources are called third-party links . A third-party link is created when an arc's xlink:from and xlink:to attributes both contain labels for locator elements. Links from a remote resource to a local resource are called inbound links . An inbound link is created when an arc's xlink:from attribute contains the label of a locator element and its xlink:to attribute contains the label of a resource element. Links from a local resource to a remote resource are called outbound links. An outbound link is established when an arc's xlink:from attribute contains the label of a resource element and its xlink:to attribute contains the label of a locator element. Simple links are also outbound links.

An XML document that contains any inbound or third-party links is called a linkbase. A linkbase establishes links from documents other than the linkbase itself, perhaps documents that the author of the linkbase does not own and cannot control. Exactly how a browser or other application will load a linkbase and discover the links there is still an open question. It will probably involve visiting a web site that provides the linkbase. When the browser sees the extended link that attempts to establish links from a third web site, it should ask the user whether he wishes to accept the suggested links. It might even use the xlink:role and xlink:title attributes to help the user make this decision, though if past experience with cookies, Java applets, and ActiveX controls is any guide, the initial user interfaces are likely to be quite poor and the choices offered quite limited.

Once a browser has loaded a linkbase and arrived at a page that's referenced as the starting resource of one or more of the links in the linkbase, it should make this fact known to the user somehow and give them a means to traverse the link. Once again the user interface for this activity remains to be designed. Perhaps it will be a pop-up window showing the third-party links associated with a page. Or perhaps it will simply embed the links in the page, but use a different color underlining. The user could still activate them in exactly the same way they activate a normal HTML link.

If this is the scheme that's adopted, then it would be useful if the starting resource of the link didn't have to be an entire document, but could rather be just one part of it, such as a specific paragraph, personal name, or book title. Indeed, you can attach an XPointer to the URI identifying the starting resource of the link that chooses a particular part of or point in the starting document. This will be the subject of Chapter 11.

10.6 DTDs for XLinks

For a document that contains XLinks to be valid, all the XLink attributes that the document uses have to be declared in a DTD just like any other attributes. In most cases some of the attributes can be declared #FIXED, and then they do not need to be explicitly included in the document itself. For example, this DTD fragment describes the novel element seen earlier:

<!ELEMENT novel  (title, author, year)> <!ATTLIST novel  xmlns:xlink CDATA   #FIXED 'http://www.w3.org/1999/xlink'                  xlink:type (simple) #FIXED 'simple'                  xlink:href  CDATA   #REQUIRED> <!ELEMENT title  (#PCDATA)> <!ELEMENT author (#PCDATA)> <!ELEMENT year   (#PCDATA)>

Given this DTD to fill in the fixed attributes xmlns:xlink and xlink:type, a novel element only needs an xlink:href attribute to be a complete simple XLink:

<novel xlink:href = "urn:isbn:0688069444">   <title>The Wonderful Wizard of Oz</title>   <author>L. Frank Baum</author>   <year>1900</year> </novel>

Documents that contain many XLink elements often use parameter entity references to define the common attributes. For example, suppose novel, anthology, and nonfiction are all simple XLink elements. Their XLink attributes could be declared in a DTD like this:

<!ENTITY % simplelink   "xlink:type (simple) #FIXED 'simple'    xlink:href  CDATA   #REQUIRED    xmlns:xlink CDATA   #FIXED 'http://www.w3.org/1999/xlink'    xlink:role  CDATA   #IMPLIED    xlink:title CDATA   #IMPLIED    xlink:actuate (onRequest | onLoad | other | none) 'onRequest'    xlink:show (new | replace | embed | other | none) 'new'" > <!ATTLIST anthology   %simplelink;> <!ATTLIST novel       %simplelink;> <!ATTLIST nonfiction  %simplelink;>

Similar techniques can be applied to declarations of attributes for extended XLinks.

CONTENTS


XML in a Nutshell
XML in a Nutshell, 2nd Edition
ISBN: 0596002920
EAN: 2147483647
Year: 2001
Pages: 28

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net