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.
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:
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.
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.