W3C

XLink Markup Name Control

W3C Note 20 December 2000

This version:
http://www.w3.org/TR/2000/NOTE-xlink-naming-20001220
(Available as: HTML, XML).
Latest version:
http://www.w3.org/TR/xlink-naming
Previous versions:
http://www.w3.org/TR/2000/NOTE-xlink-naming-20001024/
Editors:
Eve Maler, Sun Microsystems <eve.maler@east.sun.com>
Daniel Veillard, W3C <veillard@w3.org>
Henry S. Thompson, University of Edinburgh <ht@cogsci.ed.ac.uk>

Abstract

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

Status of this Document

This Note is available for W3C-member review. It has been produced by the three editors, who are co-chairs of the XML Linking Working Group and editor of part of the XML Schema spec. respectively. This Note has not been approved by the group or taken up as a work item.

No commitment is made to update this Note. However, if you have comments, please send them to the editors.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Table of Contents

1 Problem Statement
2 Schema Datatypes as a Future Solution
3 Extending the Schema to Support Multiple Links
    3.1 Encoding Semantics in the Type Name
    3.2 Using Schema Annotation to Group XLink Attributes

Appendix

A Other Potential Solutions


1 Problem Statement

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:

<doc xmlns="http://example.com/myvocab">
...
<p>See <cmd>grep</cmd> for more information.</p>
...
</doc>

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:

<doc
  xmlns="http://example.com/myvocab"
  xmlns:xlink="http://www.w3.org/1999/xlink">
...
<p>See <cmd
  xlink:type="simple"
  xlink:href="manpages.xml#grep1">grep</cmd> for 
more information.</p>
...
</doc>

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:

<html>
...
<p>See <a href="manpages.xml#grep1">grep</a> for 
more information.</p>
...
</html>

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.

2 Schema Datatypes as a Future Solution

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.

Note:

This schema example is non-normative. This Note cannot dictate what problems future XML Linking Working Groups will be chartered to solve, nor what solutions they will use to solve them.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN"
                 "http://www.w3.org/2000/10/XMLSchema.dtd" >
<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
        xmlns:xl="http://www.w3.org/2000/10/xlink-ns"
        targetNamespace="http://www.w3.org/2000/10/xlink-ns">

 <simpleType name="type">
  <restriction base="NMTOKEN">
   <enumeration value="simple"/>
   <enumeration value="extended"/>
   <enumeration value="locator"/>
   <enumeration value="arc"/>
   <enumeration value="resource"/>
   <enumeration value="title"/>
   <enumeration value="none"/>
  </restriction>
 </simpleType>

 <simpleType name="href">
  <restriction base="uriReference"/>
 </simpleType>

 <simpleType name="role">
  <restriction base="uriReference"/>
 </simpleType>
 
 <simpleType name="arcrole">
  <restriction base="xl:role"/>
 </simpleType>

 <simpleType name="title">
  <restriction base="CDATA"/>
 </simpleType>

 <simpleType name="show">
  <restriction base="NMTOKEN">
   <enumeration value="new"/>
   <enumeration value="replace"/>
   <enumeration value="embed"/>
   <enumeration value="other"/>
   <enumeration value="none"/>
  </restriction>
 </simpleType>

 <simpleType name="actuate">
  <restriction base="NMTOKEN">
   <enumeration value="onLoad"/>
   <enumeration value="onRequest"/>
   <enumeration value="other"/>
   <enumeration value="none"/>
  </restriction>
 </simpleType>

 <simpleType name="label">
  <restriction base="NMTOKEN"/>
 </simpleType>
 
 <simpleType name="from">
  <restriction base="xl:label"/>
 </simpleType>
 
 <simpleType name="to">
  <restriction base="xl:label"/>
 </simpleType>
</schema>

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.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN"
                        "http://www.w3.org/2000/10/XMLSchema.dtd" >
<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
        xmlns:myvocab="http://www.example.com/myvocab"
        xmlns:xl="http://www.w3.org/2000/10/xlink-ns"
        targetNamespace="http://www.example.com/myvocab">
 
 <import namespace="http://www.w3.org/2000/10/xlink-ns"/>
 
 <element name="doc">
  <complexType mixed="true">
   <choice minOccurs="0" maxOccurs="unbounded">
    <element ref="myvocab:a"/>
    <element ref="myvocab:img"/>
   </choice>
  </complexType>
 </element>
 
 <complexType name="myLink">
  <simpleContent>
   <extension base="CDATA">
    <attribute name="xltype" type="xl:type" use="fixed" value="simple"/>
    <attribute name="href" type="xl:href"/>
    <attribute name="target" type="xl:show"/>
    <attribute name="visit" type="xl:actuate"/>
   </extension>
  </simpleContent>
 </complexType>
 
 <element name="a">
  <complexType>
   <complexContent>
    <restriction base="myvocab:myLink">
     <attribute name="target" type="xl:show" use="fixed" value="replace"/>
     <attribute name="visit" type="xl:actuate" use="fixed" value="onRequest"/>
    </restriction>
   </complexContent>
  </complexType>
 </element>
 
 <element name="img">
  <complexType>
   <complexContent>
    <restriction base="myvocab:myLink">
     <attribute name="target" type="xl:show" use="fixed" value="embed"/>
     <attribute name="visit" type="xl:actuate" use="fixed" value="onLoad"/>
    </restriction>
   </complexContent>
  </complexType>
 </element>

</schema>

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:

3 Extending the Schema to Support Multiple Links

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.

3.1 Encoding Semantics in the Type Name

In this approach, we provide for the most common cases by allowing the choice of simple type for the href-type attributes to not only identify them as such, but also to signal their show and actuate, by providing twenty synonyms for xlink:href:

<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
        xmlns:xl="http://www.w3.org/2000/10/xlink-ns"
        targetNamespace="http://www.w3.org/2000/10/xlink-ns">
 <simpleType name="href-new">
  <annotation>
   <documentation>Corresponds to show='new' actuate='none'</documentation>
  </annotation>
  <restriction base="xl:href"/>
 </simpleType>

 <simpleType name="href-new-onLoad">
  <annotation>
   <documentation>Corresponds to show='new' actuate='onLoad'</documentation>
  </annotation>
  <restriction base="xl:href"/>
 </simpleType>
 . . .
</schema>
   

Were such types to be provided in the XML Schema for XLink, then the myvocab example schema in section 2 Schema Datatypes as a Future Solution could be both simplified in expression and extended in coverage as follows:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN"
                        "http://www.w3.org/2000/10/XMLSchema.dtd" >
<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
        xmlns:myvocab="http://www.example.com/myvocab"
        xmlns:xl="http://www.w3.org/2000/10/xlink-ns"
        targetNamespace="http://www.example.com/myvocab">
 
 <import namespace="http://www.w3.org/2000/10/xlink-ns"/>
 
 <element name="doc">
  <complexType mixed="true">
   <choice minOccurs="0" maxOccurs="unbounded">
    <element ref="myvocab:a"/>
    <element ref="myvocab:img"/>
   </choice>
  </complexType>
 </element>
 
 <element name="a">
  <complexType>
   <attribute name="xltype" type="xl:type" use="fixed" value="simple"/>
   <attribute name="href" type="xl:href-replace-onRequest"/>
  </complexType>
 </element>
 
 <element name="img">
  <complexType>
   <attribute name="xltype" type="xl:type" use="fixed" value="extended"/>
   <attribute name="src" type="xl:href-embed-onLoad"/>
   <attribute name="longdesc" type="xl:href-new-onRequest"/>
  </complexType>
 </element>

</schema>

This solution is attractive in its simplicity, but it does require conformant processors to decode the twenty typenames and act as if the implied show and actuate attributes were present. It also cannot be extended to the other XLink attributes such as arcrole or title, as these do not have a closed set of possible values.

3.2 Using Schema Annotation to Group XLink Attributes

Using the provision in XML Schema for annotating declarations with attributes from user-specified namespaces, we can provide a general solution to the problem, at the cost of requiring additional schema-sophistication on the part of processors. We add a single attribute declaration to the XLink schema itself, as follows:

<attribute name="arcIndex" type="positiveInteger"/>

Then in application schemas with multiple arcs encoded on a single tag, we annotate the declarations of the XLink-related attributes with an arcIndex, as follows:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN"
                        "http://www.w3.org/2000/10/XMLSchema.dtd" >
<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
        xmlns:myvocab="http://www.example.com/myvocab"
        xmlns:xl="http://www.w3.org/2000/10/xlink-ns"
        targetNamespace="http://www.example.com/myvocab">
 
 <import namespace="http://www.w3.org/2000/10/xlink-ns"/>
 
 <element name="doc">
  <complexType mixed="true">
   <choice minOccurs="0" maxOccurs="unbounded">
    <element ref="myvocab:a"/>
    <element ref="myvocab:img"/>
   </choice>
  </complexType>
 </element>
 
 <element name="a">
  <complexType>
   <attribute name="xltype" type="xl:type" use="fixed" value="simple"/>   
   <attribute name="s1" type="xl:show" use="fixed" value="replace"/>
   <attribute name="a1" type="xl:actuate" use="fixed" value="onRequest"/>
   <attribute name="href" type="xl:href"/>
  </complexType>
 </element>
 
 <element name="img">
  <complexType>
   <attribute name="xltype" type="xl:type" use="fixed" value="extended"/>
   <attribute name="src" type="xl:href"
              xl:arcIndex="1"/>  
   <attribute name="s1" type="xl:show" use="fixed" value="embed"
              xl:arcIndex="1"/>
   <attribute name="a1" type="xl:actuate" use="fixed" value="onLoad"
              xl:arcIndex="1"/>
   <attribute name="t1" type="xl:title" use="fixed" value="The picture itself"
              xl:arcIndex="1"/>
   <attribute name="longdesc" type="xl:href"
              xl:arcIndex="2"/>  
   <attribute name="s2" type="xl:show" use="fixed" value="new"
              xl:arcIndex="2"/>
   <attribute name="a2" type="xl:actuate" use="fixed" value="onRequest"
              xl:arcIndex="2"/>
   <attribute name="t2" type="xl:title" use="fixed" value="A long caption"
              xl:arcIndex="2"/>
  </complexType>
 </element>

</schema>

The result of these declarations is that in the post schema-validation infoset not only will all the fixed semantic indicator attribute values be available, but each will be keyed to the appropriate href by the arcIndex annotation, which is present on each relevant attribute information item.

A Other Potential Solutions

Besides a potential schema solution, there are other potential solutions that do not require a backwards-incompatible change to the vocabulary in question; however, they are outside the scope of this document. Nevertheless, to convey a sense of the alternatives, here are some possibilities phrased in terms of XHTML: