W3C

XLink Markup Name Control

W3C Note 24 October 2000

This version:
http://www.w3.org/TR/2000/NOTE-xlink-naming-20001024/ (available in: HTML, XML)
Latest version:
http://www.w3.org/TR/xlink-naming
Editors:
Eve Maler, Sun Microsystems <eve.maler@east.sun.com>
Daniel Veillard, W3C <veillard@w3.org>

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 two editors, who are co-chairs of the XML Linking Working Group. 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

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:

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: