This document is for public review. Open issues are identified at various points within the document or in the General Link Issues Appendix, and a complete list of links to them is collected in the Open Issues List Appendix. Comments on this document should be sent to the public mailing list firstname.lastname@example.org, archived at http://lists.w3.org/Archives/Public/www-xml-linking-comments/
This is a W3C Working Draft for review by members of the W3C and other interested parties in the general public.
It has been reviewed by the XML Linking Working Group and the Working Group has agreed to its publication. Note that not that all sections of the draft represent the current consensus of the WG. Different sections of the specification may well command different levels of consensus in the WG. Public comments on this draft will be instrumental in the WG's deliberations.
Open issues are identified at various points within the document or in the General Link Issues Appendix, and a complete list of links to them is collected in the Open Issues List Appendix, Open Issues List.
Comments on this document should be sent to the public mailing list email@example.com, archived at http://lists.w3.org/Archives/Public/www-xml-linking-comments/.
It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at http://www.w3.org/TR.
Note: Since working drafts are subject to frequent change, you are advised to reference the above URI, rather than the URIs for working drafts themselves. Some of the work remaining is described in Unfinished Work and Remaining Issues.
This work is part of the W3C XML Activity (for current status, see http://www.w3.org/XML/Activity). For information about the XPointer language which is expected to be used with XLink, see http://www.w3.org/TR/WD-xptr.
See http://www.w3.org/TR/NOTE-xlink-principles for additional background on the design principles informing XLink.
See http://www.w3.org/TR/NOTE-xlink-req/ for the normative XLink requirements that this document attempts to satisfy.
This specification defines constructs that may be inserted into XML DTDs and document instances to describe links between objects. It uses XML syntax to create structures that can describe the simple unidirectional hyperlinks of today's HTML as well as more sophisticated links.
This specification defines constructs that may be inserted into XML DTDs and document instances to describe links between resources. A link, as the term is used here, is an explicit relationship between two or more resources or portions of resources. This specification is concerned with the syntax used to assert link existence and describe link characteristics.
Data relationships arise when XML is being used to transfer data and metadata containing links, corresponding e.g. to foreign keys from a relational database or reference values from a programming language. Integrated treatment of such links has yet to be fully explored, but is currently considered out of scope for XLink.
XLink is a mechanism for asserting link relationships using elements contained in XML document instances. A simple case of establishing a link relationship within an XML document is the ID/IDREF mechanism. This mechanism is described in the XML 1.0 Recommendation, and is thus out of scope for XLink, but this specification provides a mechanism that extends this basic capability in a number of ways:
An important application of XLinks is in hypertext systems. For the purpose of this specification, "hyperlinks" are considered to be those links that are meaningful, frequently for direct use by end users. This specification defines hypertext meta-data that can be associated with a link.
A simple hyperlink case is an HTML A element, which has these characteristics:
While this set of characteristics is already very powerful and obviously has proven itself highly useful and effective, each of these assumptions also limits the range of hypertext functionality. The hyperlinking model defined here provides ways to create hyperlinks that go beyond each of these specific characteristics, thus providing features previously available mostly in dedicated hypermedia systems.
XLink has adopted the following conventions for non-normative commentary:
Issue (Issue Name):
A recorded issue and something on which the working group is seeking comment
General comments the editors wish to call to the attention of the reader
Following is a summary of the design principles governing XLink, derived from but not overriding the XLink Requirements Document:
Issue (HTML Support):The XLink WG has not determined to what extent the current draft supports HTML linking constructs, nor to what extent we will in the final document. We welcome feedback on this issue.
Three standards have been especially influential:
Many other linking systems have also informed this design, especially Dexter, FRESS, MicroCosm, and InterMedia.
Issue (infoset):Shouldn't XLink also be described in terms of the XML Information set? See http://www.w3.org/TR/xml-infoset
A symbolic representation of traversal behavior in links, especially the direction, context and timing of traversal.
A representation of the relevant structure specified by the tags and attributes in an XML document.
An explicit relationship between two or more data objects or portions of data objects with an eye to presentation and traversal in user interfaces.
Abstractly, a link which serves as one of its own resources. Concretely, a link where the content of the linking element serves as a participating resource.
clink, and TEI
are all inline links.
An explicit relationship between two or more data objects or portions of data objects.
The content of an inline linking element. Note that the content of the linking element could be explicitly pointed to by means of a regular locator in the same linking element, in which case the resource is considered remote, not local.
Data, provided as part of a link, which identifies a remote resource.
A link whose traversal can be initiated from more than one of its participating resources. Note that being able to "go back" after following a one-directional link does not make the link multidirectional.
A link whose content does not serve as one of the link's participating resources . Such links presuppose a notion like extended link groups, which instruct application software where to look for links. Out-of-line links are generally required for supporting multidirectional traversal and for allowing read-only resources to have outgoing links.
In the context of link behavior, a parsed link is any link whose content is included into the document where the link originated. The use of the term "parsed" directly refers to the concept in XML of a parsed entity.
A resource that belongs to a link. All resources are potential contributors to a link; participating resources are the actual contributors to a particular link.
Any participating resource of a link that is pointed to with a locator.
In the abstract sense, an addressable unit of information or service that is participating in a link. Examples include files, images, documents, programs, and query results. Concretely, anything reachable by the use of a locator in some linking element. Note that this term and its definition are taken from the basic specifications governing the World Wide Web, such as IETF RFCs [IETF RFC 2396], [IETF RFC 1738] and [IETF RFC 1808].
A portion of a resource, pointed to as the precise destination of a link. As one example, a link might specify that an entire document be retrieved and displayed, but that some specific part(s) of it is the specific linked data, to be treated in an application-appropriate manner such as indication by highlighting, scrolling, etc.
The action of using a link; that is, of accessing a resource. Traversal may be initiated by a user action (for example, clicking on the displayed content of a linking element) or occur under program control.
Issue (hypertext link versus hyperlink):Is there a difference between hypertext links and hyperlinks?
The locator for a resource is provided by means of a Uniform Resource Identifier reference, or URI-reference [IETF RFC 2396]. A URI-reference is a URI [IETF RFC 2396], [IETF RFC 1738] and [IETF RFC 1808] with an optional fragment identifier separated from the URI by a crosshatch ("#") character. For locators into XML resources, the fragment identifier format is specified by the XPointer specification [XPTR]. It is outside the scope of this specification to define locators to non-XML resources.
The existence of a link is asserted by a linking element. Linking elements must be recognized reliably by application software in order to provide appropriate display and behavior. There are several ways link recognition could be accomplished: for example, reserving element type names, reserving attributes names, leaving the matter of recognition entirely up to stylesheets and application software, or using the XLink Namespace to specify element names and attribute names that would be recognized by namespace and XLink-aware processors. Using element and attribute names within the XLink namespace provides a balance between giving users control of their own markup language design and keeping the identification of linking elements simple and unambiguous.
The XLink namespace shall be associated with the following URI: http://www.w3.org/XML/XLink/0.9. The declaration of XLink elements and attributes will require the usual declaration of the XLink namespace, for example:
<A xmlns:xlink="http://www.w3.org/XML/XLink/0.9" xlink:type="simple" xlink:href="students.xml" xlink:role="student list" xlink:title="Student List" xlink:show="new" xlink:actuate="user"> Current List of Students </A>
The two approaches to identifying linking elements are relatively simple to implement. For example, here's how the HTML
A element would be declared using attributes within the XLink namespace, and then how an element within the XLink namespace might do the same:
<A xmlns:xlink="http://www.w3.org/XML/XLink/0.9" xlink:type="simple" xlink:href="students.xml" xlink:role="student list" xlink:title="Student List" xlink:show="new" xlink:actuate="user"> Current List of Students </A>
<xlink:simple href="students.xml" role="student list" title="Student List" show="replace" actuate="user"> Current List of Students </xlink:simple>
xlink:typeattribute. And the explicit XLink elements may be used as well. This document describes the linking attributes that are associated with linking elements. The reader may assume that these attributes require the
xlinknamespace prefix if they existed within an arbitrary element, or that they may be used directly if they exist within an explicit XLink element.
XLink has several attributes associated with the variety of links it may represent. These attributes define four main concepts: locators, arc ends, behaviors, and semantics. Locators define where the actual resource is located. Arcs define the traversal of links. Where does the link come from? Where does it go to? All this information can be stored in the arc attributes. Behaviors define how the link is activated, and what the application should do with the resource being linked to. Semantics define useful information that the application may use, and enables the link for such specialized targets as constricted devices and accessibility software.
The only locator attribute at this time is
href. This attribute value must be a URI-reference as defined in [IETF RFC 2396].
Arcs contain two end attributes,
from attribute may contain a string containing the content of an
ID attribute from the resource being linked from. The purpose of the
from attribute is to define where this link is being actuated from.
to attribute may contain a string containing the content of an
ID attribute from the resource being linked to. The purpose of the
to attribute is to define where this link traverses to.
The application may use this information in a number of ways, especially in a complex hypertext system, but it is mainly useful in providing context for application behavior. The arc construct is intended to provide an explicit model for the relationship between two locators. The arc construct is the correct construct to associate XLink and non-XLink related traversal information.
Issue (Arcs to IDs or roles):We changed the suggested method of identifying the from and to values from roles to IDs, making the from and to IDREFs. This disallows the specification of a model of traversal from and to classes of ends, which seems like the too high a level of abstraction (though admittedly this is just a hunch). We wanted to allow arcs to specify locator IDs as their from and to values because this would be giving specific instructions for any two instances of locators.
Issue (Arc containment):Can an arc exist outside the scope of a link? When arcs
fromwere connected with roles, it was required that arcs be contained within the link because the roles of the locators were only valid within the link. But using IDs for arcs means that arcs could be outside the context of a link and it's containing locators.
There are two attributes associated with behavior:
show attribute defines how the remote resource is to be revealed to the user. It has three options:
new option indicates that the remote resource should be shown in a new window (or other device context) without replacing the previous content. The
parsed option, relating directly to the XML concept of a parsed entity, indicates that the content should be integrated into the document from which the link was actuated. The
replace option is the one most commonly seen on the World Wide Web, where the document being linked from is entirely replaced by the object being linked to.
actuate attribute defines how the link is initiated. It has two options:
user option indicates that the link must be initiated by some sort of human-initiated selection, such as clicking on an HTML anchor. The
auto option indicates that the link is automatically initiated when the application deems that the user has reached the link. It then follows the behavior set out in the
There are two attributes associated with semantics,
role attribute is a generic string used to describe the function of the link's content. For example, a poem might have a link with a
title attribute is designed to provide human-readable text describing the link. It is very useful for those who have text-based applications, whether that be due to a constricted device that cannot display the link's content, or if it's being read by an application to a visually-impaired user, or if it's being used to create a table of links. The
title attribute should contain a simple, descriptive string.
Issue (Inline attribute):Simple links are inline and extended links are out-of-line. This appears to disallow the representation of an arc to inline content as there appear to be too many options for representation. The difficulty arises from the addition of arcs, which require an explicit
fromalready has to be an ID of a locator, so what datatype could the
fromhave to cover inline content and out-of-line content? One approach would be to have the
fromattribute of an arc be required to be the ID of an extended link. Another approach would be for the
fromattribute to be an XPath expression, such as #here().
There are several kinds of linking elements in XLink:
extended link groups, and
extended link group documents. These elements may be instantiated via element declarations from the XLink namespace, or they may be instantiated via attribute declarations from the XLink namespace. Both kinds of instantiation are described in the definition of each linking element.
simple link is used to declare a link that approximates the functionality of the HTML
A element. It has, however, a few added features to increase its value, including the potential declaration of semantics and behavior. The
locator elements are used to define the resource being linked to. Some links may contain multiple locators, representing a choice of potential links to be traversed. The
arcs are used to define the traversal semantics of the link. Finally, an
extended linking element differs from a simple link in that it can connect any number of resources, not just one local resource (optionally) and one remote resource, and in that extended links are more often out-of-line than simple links.
[Definition: ] Simple links can be used for purposes that approximate the functionality of a basic HTML
A link, but they can also support a limited amount of additional functionality. Simple links have only one locator and thus, for convenience, combine the functions of a linking element and a locator into a single element. As a result of this combination, the simple linking element offers both a locator attribute and all of the behavior and semantic attributes.
The following are two examples of linking elements, each showing all the possible attributes that can be associated with a simple link. Here is the explicit XLink simple linking element.
<!ELEMENT xlink:simple ANY> <!ATTLIST xlink:simple href CDATA #REQUIRED role CDATA #IMPLIED title CDATA #IMPLIED show (new|parsed|replace) "replace" actuate (user|auto) "user" >
<!ELEMENT student ANY> <!ATTLIST student xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (simple|extended|locator|arc) #FIXED "simple" xlink:href CDATA #REQUIRED xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:show (new|parsed|replace) "replace" xlink:actuate (user|auto) "user" >
<xlink:simple href="students.xml" role="student list" title="Student List" show="replace" actuate="user"> Current List of Students </xlink:simple>
<students xmlns:xlink="http://www.w3.org/XML/XLink/0.9" xlink:href="students.xml" xlink:role="student list" xlink:title="Student List" xlink:show="new" xlink:actuate="user"> Current List of Students </students>
<students xmlns:xlink="http://www.w3.org/XML/XLink/0.9" xlink:href="students.xml"> The list of students. </students>
<A href="students.html">The list of students.</A>
There are no constraints on the contents of a simple linking element. In
the sample declaration above, it is given a content model of
to illustrate that any content model or declared content is acceptable. In
a valid document, every element that is significant to XLink must still conform
to the constraints expressed in its governing DTD.
Note that it is meaningful to have an out-of-line simple link, although such links are uncommon. They are called "one-ended" and are typically used to associate discrete semantic properties with locations. The properties might be expressed by attributes on the link, the link's element type name, or in some other way, and are not considered full-fledged resources of the link. Most out-of-line links are extended links, as these have a far wider range of uses.
[Definition: ] An extended link differs from a simple link in that it can connect any number of resources, not just one local resource (optionally) and one remote resource, and in that extended links can be out-of-line
These additional capabilities of extended links are required for:
Application software might be expected to provide traversal among all of a link's participating resources (subject to semantic constraints outside the scope of this specification) and to signal the fact that a given resource or sub-resource participates in one or more links when it is displayed (even though there is no markup at exactly that point to signal it).
A linking element for an extended link contains a series of child elements that serve as locators and arcs. Because an extended link can have more than one remote resource, it separates out linking itself from the mechanisms used to locate each resource (whereas a simple link combines the two).
xlink:type attribute value for an extended link must be
extended, if the link is being instantiated on an arbitrary element. Note that extended links introduce variants of the
actuate behavior attributes. These attributes, the
actuatedefault define the same behavior as their counterparts. However, in this case, they are considered to define the default behavior for all the linking elements that they contain.
However, when a linking element within an extended link has a
actuate attribute of its own, that attribute overrides the defaults set on the extended linking element.
The extended linking element itself retains those attributes relevant to the link as a whole and to any local resource. Following are two sample declarations for an extended link. The first is an example of the explicit XLink extended link:
<!ELEMENT xlink:extended ((xlink:arc | xlink:locator)*)> <!ATTLIST xlink:extended role CDATA #IMPLIED title CDATA #IMPLIED showdefault (new|parsed|replace) #IMPLIED actuatedefault (user|auto) #IMPLIED >
<!ELEMENT students ((xlink:arc | xlink:locator)*)> <!ATTLIST students xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (simple|extended|locator|arc) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED >
<xlink:extended role="student list" title="Student List" showdefault="replace" actuatedefault="user"> ... </xlink:extended>
<students xmlns:xlink="http://www.w3.org/XML/XLink/0.9" xlink:type="extended" xlink:role="student list" xlink:title="Student List" xlink:showdefault="replace" xlink:actuatedefault="user"> ... </students>
Issue (Order of Arcs and Locators):Should the order of arcs and locators (arcs before locators versus arcs after locators) be specified?
[Definition: ] A locator is contained within an extended link for the purpose of defining resources that are participating in a link. The remote resource is specified by the href attribute. More than one locator may be associated with a link. Each remote resource can have its own semantics in relation to the link as a whole and these are specified in the locator element. These are the title and role attributes.Here is the explicit XLink locator element.
<!ELEMENT xlink:locator ANY> <!ATTLIST xlink:locator id ID #REQUIRED href CDATA #REQUIRED role CDATA #IMPLIED title CDATA #IMPLIED >
<!ELEMENT student ANY> <!ATTLIST student xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (locator) #FIXED "locator" id ID #REQUIRED xlink:href CDATA #REQUIRED xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED >
<xlink:locator href="/essays/student1/FirstEssay" role="essay" title="homework assignment 1"/>
<student xmlns:xlink="http://www.w3.org/XML/XLink/0.9" xlink:href="FirstEssay">The First Essay.</foo>
Note:Locators have a subset of the attributes of simple links. It is not feasible to combine the locator and simple link elements together because the semantics of linking versus locating are substantially different.
Note:Locators are conceptually similar to programming handles. They provide a needed layer of abstraction for associating metadata with the resource.
Issue (locator container or content):How does a locator specify the container versus specifying the content of the container?
Issue (HTML access key):Lack of an equivalent in XLink to the HTML 4.0 ACCESSKEY attribute (on anchor, area). Further consideration should also be given to the use of TITLE and/or link content to provide text which can be identified by speech recognition software as a label for the link, thereby allowing it to be activated via a spoken command.
[Definition: ] An arc is contained within an extended link for the purpose of defining traversal behavior. More than one arc may be associated with a link. Otherwise, arc elements function exactly as the arc attributes might lead one to expect.
Here is the explicit XLink arc element.
<!ELEMENT xlink:arc ANY> <!ATTLIST xlink:arc from IDREF #REQUIRED to IDREF #REQUIRED >
<!ELEMENT genericarc ANY> <!ATTLIST genericarc xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (arc) ` #FIXED "arc" xlink:from IDREF #REQUIRED xlink:to IDREF #REQUIRED show (new|parsed|replace) "replace" actuate (user|auto) "user" >
<xlink:arc from="student" to="essay" show="parsed" actuate="auto"/>
<genericarc xmlns:xlink="http://www.w3.org/XML/XLink/0.9" xlink:type="arc" xlink:from="student" xlink:to="teacher" show="new" actuate="user"/>
Default arc instructions are on the linking element - the show/actuate values inherit from the values in the parent. The alternative is to have a special "default arc" element but that prevents us from setting partial defaults, like "from any id" or "to any id". The "to any id" default could be done on locator elements instead, but this would conflate arcs and ends. The
actuate attributes on the arc are optional. We proposed that there be cascading defaults, starting with defaults set by the specification, overridden by defaults (if any) set on the
xlink element, overridden by values (if any) set on individual arc elements.
Issue (Empty Arc Content):Arcs are empty for simplicity. What purpose could content serve? Or should we allow content and decide that an XLink processor simply ignores it?
Note:We proposed not putting
titleattributes on arc elements because we felt that the role of any arc is the concatenation of the two end roles, and if you're going to display title text for an end, there's no sensible place to display the title text for an arc in addition. In cases where the relationship between two elements has a role, then this mechanism does not hold. For example, a family may have many members, and the arc between a one person and another person could have a daughter role, whereas the arc in the opposite direction could have a mother role.
Note:Every pair of locators has 4 implicit arcs: From each locator to itself, and the two arcs going opposite directions between the locators. An XLink processor is required to make the arcs explicit after processing the link. This enables an application to perform behavior based upon either implicit or explicit arcs. There is no need to specify an arc if the default arcs between the locators is sufficient for traversal.
[Definition: ] An extended link group specifies an XML document that may contain extended links and additional extended link groups. Hyperlinked documents may be processed in groups rather than one at a time. If it is desired to highlight resources to advertise that traversal can be initiated, and if at the same time out-of-line links are being used, it may be an absolute requirement to read other documents to find these links and discover where the resources are.
In these cases, an extended link group element, a special kind of extended link, may be used to store a list of links to other documents that together constitute an interlinked group.[Definition: ] Each such document is identified by means of an extended link document element, a special kind of locator element.
Following are sample declarations for extended link group and extended link document elements, showing all the possible XLink-related attributes they may have. The
xlink:type attribute value for an extended link group element must be
group, and the value for an extended link document element must be
<!ELEMENT xlink:group (xlink:document*)> <!ATTLIST xlink:group steps CDATA #IMPLIED > <!ELEMENT xlink:document EMPTY> <!ATTLIST xlink:document href CDATA #REQUIRED >
<xlink:group steps="2"> <xlink:document href="http://www.w3.org/W3CHubDoc.xml"/> </xlink:group>
steps attribute may be used by an author to help deal with the situation where an extended link group directs application software to locate another document, which proves to contain an extended link group of its own. There is a potential for infinite regress, and yet there are situations where processing several levels of extended link groups is useful. The
steps attribute should have a numeric value that serves as a hint from the author to any link processor as to how many steps of extended link group processing should be undertaken. It does not have any normative effect.
For example, should a group of documents be organized with a single "hub" document containing all the out-of-line links, it might make sense for each non-hub document to contain an extended link group containing only one reference to the hub document. In this case, the best value for
steps would be
Issue (ELG Steps):dorchard. Steps = 2 seems wrong to me. I would have though = 1. Steps is the depth of the graph of documents to retrieve from the current position, so 1 would cause retrieval of the hub document.
Note:There are many possibilities for specifying the graph of the documents to be retrieved - HyTime uses the term Bounded Object Set. The depth of the tree is the simplest and easiest for authors and processors.
In another example, extended links are grouped following a multi-level hierarchy, similar to the Domain Name Service. There is an extended link group for each level of the hierarchy, where the extended link group contains extended links relevant to the current level, extended link groups referencing each sub-level, and an extended link group referencing the parent extended link group.
There are three levels of XLink processing.
Issue (Extended Link Validation):We can't validate XLinks with a mandatory locator and optional arcs + locators. What does the DTD look like?
Issue (Link Processing):A specific subset of the XSL Integration overlap issue, is should a set of required XLink processing constructs be added to XLink to support inclusion/embedding prior to styling?
Note:There is no processing model for Extended Link Groups. There is no specification for what a processor is to do when it finds extended links in an extended link group document. A sample list of situations with unspecified results follows:
- Duplicate IDs between in-line versus the out-of-line links referenced in the extended link group.
- Retrieval process, especially errors and verbose documents.
- Circular and self references in the extended link groups.
An element conforms to XLink if:
xlink:typeattribute whose value is one of the attribute values prescribed by this specification, and
xlink:typeattribute value, as prescribed in this specification.
Note that conformance is assessed at the level of individual elements, rather than whole XML documents, because XLink and non-XLink linking mechanisms may be used side by side in any one document. Additionally, an XLink element may have attributes that are not XLink attributes.
An application conforms to XLink if it interprets XLink-conforming elements according to all required semantics prescribed by this specification and for any optional semantics it chooses to support, supports them in the way prescribed. A user agent application should allow their users to exercise control over document refresh/redirection, especially arcs with actuate="auto".
The required (normative) constructs for a conforming application are
The following shows a simple link
<student id="Fred" xmlns:xlink="http://www.w3.org/XML/XLink/0.9"> <name>Fred</name> <teacher xlink:href="teachers.xml#Joe" xlink:show="parsed"/> </student>
The following shows an extended link with the from element within the current document.
<xlink:extended xmlns:xlink="http://www.w3.org/XML/XLink/0.9"> <xlink:locator href="#Fred" id="student"/> <xlink:locator href="teachers.xml#Joe" id="teacher"/> <xlink:arc from="student" to="teacher" show="parsed"/> </xlink:extended> <student id="Fred"> <name>Fred</name> </student>
The following shows an XSLT stylesheet fragment that could be used transform the simple link shown in Simple Link #1. As the href attribute contains an XPointer, this example assumes that the XSLT Processor being used conforms with the XPointer specification as well.
<xsl:template match="*[@xlink:show='parsed'] xmlns:xlink="http://www.w3.org/XML/XLink/0.9"> <xsl:apply-templates select="document(@xlink:href)"> </xsl:template>
The simple title mechanism described in this draft is insufficient to cope with internationalization or the use of multimedia in link titles. A future version will provide a mechanism for the use of structured link titles.
Issue (XSL Integration):XSL introduces the possibility of potentially dramatic differences between the XML source document, and the result tree (generally presentation). One issue that arises in such systems is that a "user selection" may not be easily mappable to a corresponding range or set of ranges in the source tree. Further exploration of the relationship between link processing and XSL processing is needed.
Issue (HyperLinking versus Implicit Linking):There are many different approaches to link recognition.
The W3C's RDF (http://www.w3.org/TR/REC-rdf-syntax/) provides one approach where the entire RDF XML syntax is asserting links so recognition is unnecessary. Microsoft's BizTalk Canonical Format provides another where ID/IDREF and URI are used to recognize links. Jfinity's XArc(http://jfinity.com/xarc/spec-current/index.html) provides yet another that uses a streamlined version of XLink's simple link/locator that can express both binary links and compound links.
Some members of the WG believe that the vast majority of uses of ID/IDREF and URI valued attributes are intended to assert the existence of a link. In some cases the link will be intended for presentational use (hyperlink) while in others it will be intended to assert a non-presentational relationship. They further believe that these use cases should be considered for support by the XLink WG.
Hyperlinks are a specialized version of general links intended for presentational use that hardwire specific recognition mechanisms and metadata, including presentation behavior. XLink supports hyperlinks in a schema-less environment. It is a focused effort that has consciously decided to not support a more integrated linking model.
Issue (resource media specification):It's important that XLink does not result in a loss of functionality compared to HTML4 specific attributes. Particularly with regard to specifying the media type of the linked resource (as in the MEDIA attribute in HTML 4.0). There is a need to develop an extensible repertoire of role types, with common semantics so that they can be recognized and acted upon appropriately by a variety of user agents. HTML 4.0 LINK for instance suggests a simple set of pre-defined names for PREV NEXT, TOC, etc. XLink could go beyond these simple conventions and provide a more formal set and mechanism.
Issue (link events):Association of events with links: the XLink specification provides no counterpart to the HTML 4.0 attributes which permit script events to be attached to links. This issue is also related to the DOM work and the desire to provide a device-independent means of specifying and activating events.
Issue (title as element):The ability to include markup in the title (i.e. not an attribute but an element) is advantageous for accessibility, as it allows semantics distinctions (CODE, ABBR, etc., to take examples from HTML), special notations (E.G. mathematics) etc., to be preserved in the title text, using markup as appropriate. SVG is doing this as an example.
Remaining editorial work:
The editors would like to thank Eve Maler, Steve DeRose and Tim Bray for much early work and continuing input. Further, the editors would like to thank the XML Linking interest group and working group for their support and input. The editors would like to thank Gabe Beged-Dov for his XArc proposal.
|Steven J. DeRose and David G. Durand. 1995. "The TEI Hypertext Guidelines." In Computing and the Humanities29(3). Reprinted in Text Encoding Initiative: Background and Context, ed. Nancy Ide and Jean ronis , ISBN 0-7923-3704-2.|
|Vidur Apparao et al. DOM (Document Object Model) Level 1.Document Object Model (DOM) Level 1 Specification. 1998. (See http://www.w3.org/TR/REC-DOM-Level-1/).|
|IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource Locators. 1991. (See http://www.w3.org/Addressing/rfc1738.txt).|
|IETF (Internet Engineering Task Force). RFC 1808: Relative Uniform Resource Locators. 1995. (See http://www.w3.org/Addressing/rfc 1808.txt ).|
|IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers. 1995. (See http://www.ics.uci.edu/pub/ietf/uri/rfc2396.txt ).|
|ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology- Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended FacilitiesAnnex. [Geneva]: International Organization for Standardization, 1996. (See http://www.ornl.gov/sgml/wg8/docs/n1920/ ).|
|C. M. Sperberg-McQueen and Lou Burnard, editors.Guidelines for Electronic Text Encoding and Interchange. Association for Computers and the Humanities (ACH), Association for Computational Linguistics (ACL), and Association for Literary and Linguistic Computing (ALLC). Chicago, Oxford: Text Encoding Initiative, 1994.|
|Eve Maler and Steve DeRose, editors. XML Pointer Language (XPointer) V1.0. ArborText, Inso, and Brown University. Burlington, Seekonk, et al.: World Wide Web Consortium, 1998. (See http://www.w3.org/TR/WD-xptr .)|