This document proposes a possible XML Schema-based solution to the need to use XLink in XML-based languages such as XHTML 1.0.

XLink is a vocabulary that allows you to add hyperlinking to any XML document. In order to use it, you add XLink-namespaced attributes to elements of your own design. For example, say the following cmd element normally just indicates the name of a command in text, so it can be highlighted:

If you wanted to turn it into an XLink hyperlink, you would add a series of attributes to make it be recognized as such and to provide the relevant linking information:

A problem arises if you already have some marked-up information that provides some of the same kinds of linking information that XLink is designed to provide. For example, if you have an XHTML document that links the word grep with the grep manpage, you already provide a URI reference pointing to your desired target in XHTML's own href attribute:

In order to incorporate XLink usage directly into this vocabulary as a first-class construct, you would have to force the vocabulary to undergo a backwards-incompatible change from href to xlink:href. XLink's attributes must have namespace prefixes on them because of the way XML namespaces work; global attributes that can be attached to any element must be prefixed because they cannot identify themselves in any other way.

XML Schema could be useful in handling XML documents that want to use XLink but already provide link information in a form that is incompatible with XLink.

Currently, XLink requires applications to recognize a particular set of attribute names in the XLink namespace in order to do their work, but an imagined future version of XLink (here called Schema-XLink to avoid any confusion) might allow them to take advantage of XML Schema datatypes instead, or in addition, as a way to recognize Schema-XLink data. The idea is that any attribute name could be used, as long as the attribute were marked with an appropriate datatype, made available through a post-schema-validation information set or by other means. This idea was originally suggested by Henry Thompson of the XML Schema Working Group.

If Schema-XLink were to define such datatypes, it could provide a normative XML Schema module that merely contains a series of type definitions. (Note, however, that as of this writing, XML Schema does not have facilities to specify additional normative constraints of the style that XLink needs; prose would still be needed to specify the combinations of attribute types that are expected to appear on particular XLink element types.) It is likely that most vocabularies choosing to use these simple datatypes would incorporate the Schema-XLink schema module into a higher-level schema that defines stricter rules as necessary.

Following is how the Schema-XLink module might look.

If a higher-level vocabulary were to layer itself on top of Schema-XLink, it could then use the schema module as follows. This example is for a fictional vocabulary that has a and img elements that are somewhat similar to XHTML's elements of the same name. It assigns fixed values to the elements' attributes, so that users of the vocabulary don't need to set them explicitly; in this way, it relies on XLink processing to get the desired show and actuate behavior. It also defines a complex type, myLink, that provides constraints for what might be called the basics of an XLink simple linking element. The myLink type meets the needs of this schema, but might be too constraining for some other schema that wishes to be Schema-XLink-conforming.

Instead of creating target and visit attributes to hold fixed values for the traversal behavior for each element type, this vocabulary could have conveyed the desired behavior semantics in ways that would require a myvocab processor to act itself (possibly through communicating with an XLink processor, if the desired behavior is simple enough to fit within XLink's behavior axes). For example:

The examples in the previous section were relatively simple to accommodate in that the elements involved had only a single href-type attribute. This may of course not always be the case. We explore here to alternative approaches to supporting a schema-based approach to signalling link semantics when multiple linking attributes are involved, as for example is the case for XHTML's IMG tag, which has longdesc and usemap href-type attributes in addition to src.

The primary difficulty in extending the solution proposed in the previous section to the case of multiple links lies not in identifying the href-type attributes (the xlink:href simple type can be used for all of them) but in establishing the semantics of these links, that is, in identifying their show, actuate, arcrole, etc. We propose two possible solutions to this problem below, one simpler, but limited, and the other completely general, but more complex.