Copyright © 2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document proposes a possible XML Schema-based solution to the need to use XLink in XML-based languages such as XHTML 1.0.
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.
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.
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:
The element type names could be sufficient, since there are only two elements and their desired traversal behaviors are distinct.
If the vocabulary had several elements, with some sharing the same set of traversal behaviors, their declarations could share a named complex type that would convey the desired behavior.
If the complex type solution is used, instead of merely using the type name to convey the desired behavior, each type could set up attributes with fixed values as shown above.
Or each complex type could set up an attribute of type xl:arcrole
and give it a value that corresponds to an RDF property.
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:
Put xlink:href alongside href with the same
value, so that each could be used by its respective processor. This would
be better as a transition strategy than as a long-term solution.
Build a transformation into XLink-compliant form into the expected processing of XHTML.
Harvest third-party XLink links from the XHTML and use an XLink processor to operate on them as an expected part of XHTML processing.