摘要
本规格说明定义了 XML 链接语言（XLink），该语言为了要创建并描述资源之间的链接，允许将元素插入 XML 文档。它使用 XML 语法创建即能描述与现今的 HTML 简单单向超链接类似的链接结构，有能描述复杂的链接。
本文档的地位
本文档已由万维网协会（W3C）组织成员和其他感兴趣的各方审阅，并已被组织理事批准为万维网协会（W3C）建议。这是一个稳定的文档，可以用作参考材料，也可以作为其他文档的标准参考文献。W3C 在建议制定过程中的作用是吸引对本规范的注意并促进它的广泛使用。这能增强 Web 的功能和互操作性。
关于可能由 XLink 使用的 XPointer 语言的资讯，参见［XPTR］。
本规格是 XML 链接工作组的工作成果，因此也是 W3C XML 制定工作（W3C XML Activity）的一部分。有关本工作的背景，请参见 XML 制定工作声明。
请报告本文档可能的错误到公共电子邮件列表 www-xml-linking-comments@w3.org（其存档在 http://lists.w3.org/Archives/Public/www-xml-linking-comments/）。本规格说明所有已证实的错误将列表在 http://www.w3.org/2001/06/xlink-errata。
英文版是唯一的正式版，本文档的翻译请参见 http://www.w3.org/2001/06/xlink-translations。
有关 XLink 设计原则的其它背景参见［XLDP］，本文档尝试满足的非标准的 XLink 需求参见［XLREQ］。XLink 不支援所有的现有的 HTML 链接构造；有关这种情形的讨论参见［XLinkNaming］
目前 W3C 建议和其他的技术上的文档列表在 http://www.w3.org/TR/.
目录
1 介绍
1.1 起源和目标
2 XLink 的概念
2.1 链接和资源
2.2 弧，游历和行为
2.3 与链接元素的实际位置有关的资源
3 XLink 的处理及一致性
3.1 处理的相关性
3.2 置标的一致性
3.3 应用程序一致性
4 XLink 置标的设计
4.1 XLink 属性用法模式
4.2 XLink 元素类型关系
4.3 属性值的缺省
4.4 整合 XLink 用法与其他的置标
4.5 与传统的置标一起使用 XLink
5 XLink 元素和属性
5.1 扩展链接（extended-类型元素）
5.1.1 扩展链接的本地资源（resource-类型元素）
5.1.2 扩展链接的远程资源（locator-类型元素）
5.1.3 扩展链接的游历规则（arc-类型元素）
5.1.4 扩展链接、定位器、及弧的标题（title-类型元素）
5.1.5 定位链接库（特别的弧角色）
5.2 简单链接（simple-类型元素）
5.3 XLink 元素类型属性（type）
5.4 定位器属性（href）
5.5 语义属性（role，arcrole，和 title）
5.6 行为属性（show 和 actuate）
5.6.1 show 属性
5.6.2 actuate 属性
5.7 游历属性（label，from，和 to）
附录
1 介绍
本规格说明定义了 XML 链接语言（XLink），该语言为了要创建并描述资源之间的链接，允许将元素插入 XML 文档。
XLink 提供了一个架构既适合于创建基本的单向链接又适合于创建较复杂的链接的结构。它允许 XML 文档：
-
宣称在两个以上的资源中的链接关系
-
宣称在两个以上的资源中的链接关系
-
在与被链接的资源不同的位置表示链接
XLink 的一个重要的应用程序是在有超链接的超媒体系统中。超链接的一个简单的情况是具有以下这些特性的一个 HTML 元素 A：
-
超链接使用 URIs 做为它的定位器技术。
-
超链接在它两个末端的中的一端表示。
-
超链接标示另一端。（ 虽然服务器可能有很大的自由来寻找或动态地创建目的地）
-
用户只能从超链接被表达的末端开始游历到另一端。
-
在视窗、图文框、返回列表、使用中的式样表等等的上超链接的效果由用户代理决定，而不是由超链接本身决定。例如，
A链接的游历通常代替目前的窗口，但也许由于用户的选择却开启一个新窗囗。
这组特性是功能强大的，但是他们所基于的模型限制了超链接可能的功能范围。本规格说明定义的模型和 HTML 都在使用 URI 技术的，但是超越了 HTML，它提供那些先前只有在专用的超媒体系统中才有的、使超链接更可调整和更有灵活性的功能。与链接数据结构一道，XLink 还提供了一个最小的链接行为模型；在 XLink 上的高层的应用程序通常将会指定可供选择的或是更复杂的表现和处理的方法。
诸如关系数据库的外部键和程序语言中的引用值，这些用于其他的技术领域的特殊链接的整合的处理方法都超出本规格说明的范围。
1.1 起源和目标
XLink 的设计受对已建立的超媒体系统和标准的认知的影响，尤其是下列各项标准的影响:
-
HTML ［HTML］: 定义了几个表现链接的元素类型。
-
HyTime ［ISO/IEC 10744］: 定义内链接、输入和第三方链接结构及一些与语义有关的功能，包括游历的控制和对象的表现形式。
-
本文编码起始指南 ［TEI］：提供了适合于创建链接、集合对象、和链接集合的结构。
许多其他的链接系统也影响了 XLink 的设计，尤其是 ［Dexter］、［FRESS］、［OHS］、［MicroCosm］、和 ［Intermedia］.
至于 XLink 设计的完整的解释，参见 XLink 需求文档［XLREQ］
2 XLink 的概念
本节在不讨论创建 XLink 构造的句法的情况下，描述那些对了解 XLink 来说是很重要的术语和概念。其他的几个额外的术语将在这一个规格说明的较后部份中介绍。
2.1 链接和资源
［定义： XLink 链接 是在资源或资源的部分之间的明确关系。］ ［定义：该关系是通过链接元素来明确的，这个链接是一个申明链接的存在、符合 XLink 的 XML 元素。］有六种 XLink 元素，其中只有两个被当作链接元素，其余的提供各种不同的描述链接特性的信息。（虽然不能避免非 XLink 链接构造被用做链接，本规格说明所用的术语 “链接”仅指 XLink 链接。）
资源的观念是对全球信息网通用的。［定义：正如在［IETF RFC 2396］中的讨论，资源是任何的可设定位址的信息或服务的单位。］其例子包括文件、图像、文档、程序和查询结果。设定资源位址的方法是 URI（统一资源识别符）引用（5.4 定位器属性（href）中有更多的描述）。对资源的某部分设定位址是可能的。举例来说，如果整个的资源是一个 XML 文档，那资源的有用部分可能是在文档之内一个特别的元素。跟随链接可能产生的结果，可以是比如说在对文档的那个元素进行高光或滚动到该元素。
［定义：当链接联合一系列资源的时候，那些资源就分享了该链接。］即使 XLink 链接一定得在 XML 文档中出现，他们却能够联合各种的资源而不是只是 XML 编码的文档资料。
XLink 的一个常见的使用是创建超链接。［定义：超链接主要的意图是呈现给人类的用户。］然而，在XLink 中没有任何的设计来阻止它仅仅被用做计算机处理。
2.2 弧，游历和行为
［定义：因任何的目的使用或跟随一个链接连结被称为游历。］即使一些类型的链接能联合任意数目的资源，游历总是包括一对资源（或他们的部分）；［定义：游历开始的资源是出发资源］ 和 ［定义：目的地的资源是终止资源］。注意以这种方式使用的术语“资源”可能有时是用于一个资源的部分而不是整个的资源。
［定义：游历一对资源的信息，包括游历的方向及应用程序可能的行为的信息被称为弧］。如果在链接中的两个弧描述相同的一对资源，但是却对换出发资源和终止资源，那么该链接是多方向的，这种情况与在游历一个链接之后只是简单的“返回”不同。
2.3 与链接元素的实际位置有关的资源
［定义： 本地资源是一个 XML 元素，该元素由于有它的父、或它本身是一个链接元素而分享一个链接］。［定义：任何的资源或资源的部分由于被 URI 引用定址而分享一个链接，该资源或该资源的一部分被视为远程资源，即使它是在同一 XML 文档之内的链接，或甚至在同一链接元素内。］换句话说法，本地资源“通过数值”来叙述，而且远程资源“通过引用”来叙述。
［定义：一个有本地出发资源和有远程终止资源的弧是在输出，也就是说，远离链接元素。］（有这种弧的链接的例子是 HTML 的 A 元素，HyTime 的“clinks”和本文编码起始的 XREF 元素）。［定义：如果弧的终止资源是在本地，但是它的出发资源是在远程，那么弧是在输入。］［定义：如果出发资源不是终止资源也不是在本地，那么则是第三方弧。］任何链接虽然不要求但是通常始终只是某种类型的弧，并因此可能被称为输入、输出或第三方链接。
为了创建一个发源于你没有（或选择不行使）书写存取权的资源，或没有提供插入链接构造方法的资源的链接有必要使用输入或第三者弧。当使用这样的弧的时候，显示该链接的条件高过输出弧。［定义：文档包含输入和第三方链接的集合叫做链接数据库，或链结库。］
3 XLink 的处理及一致性
本节详细说明对 XLink 应用程序和置标的处理及一致性的需求。
［定义：本规格说明中的关键字必须（must）、不能（must not）、必需的（required）、将（shall）、将不（shall not）、应该（should）、不应该（should not）、建议（recommended）、可能（may）、和可选的（optional）依照［IETF RFC 2119］所描述的进行解释。］
3.1 处理的相关性
XLink 的处理依照［XML］、［XML Names］、［XML Base］、以及［IETF RFC 2396］（由［IETF RFC 2732］更新）。
3.2 置标的一致性
XML 元素符合 XLink 如果:
-
它有一个来自 XLink 命名空间的
type属性，且其值为 “simple”、“extended”、“locator”、“arc”、“resource”、“title”、或“none” 中的一个，而且 -
如本规格说明所规定的，它依赖所选择的 XLink 元素类型来保证一致性的限制。
本规格说明没有对 DTD 增加更严的特别限制；一致性仅适用于元素和属性。
3.3 应用程序一致性
XLink 应用程序是任何用于解释包含 XLink 元素和属性的形式完整的 XML 文档、或包含信息项目和符合 XLink 元素和属性的特性的 XML 信息集［XIS］的软件模块。 （本文档提及元素和属性，但是所有这些规格说明适用于他们信息集的等价物）。这样的应用程序遵守一致性，如果：
-
它对本规格说明中所列的应用程序遵守强制性条件（“must”），且
-
对于任何的选择性的条件（“should”和“may”）它选择遵守，它以规定的方式遵守这些条件，且
-
它依照在本规格说明中出现的所有的一致性限制来测试置标的一致性。
4 XLink 置标的设计
本节描述 XLink 的置标字汇的设计。
为了能正确地游历及处理链接，链接的置标需被 XLink 应用程序可靠地识别。XLink 使用在 XML 命名空间建议［XML Names］中描述的机制来完成对 XLink 字汇中构造的识别。
由本规格说明定义的 XLink 命名空间具有下列的 URI：
http://www.w3.org/1999/xlink |
正如［XML Names］中所规定，使用 XLink 元素和属性需要声明 XLink 命名空间。例如，下列声明使前缀 xlink 在 myElement 元素内可用来表示 XLink 命名空间:
<myElement
xmlns:xlink="http://www.w3.org/1999/xlink">
...
</myElement>
|
注意：
本规格说明中大多数的代码例子都没有列出 XLink 命名空间声明。xlink 前缀始终是用来表示对那些在其范围内有这样标志的属性（在同一元素上或在某些祖先元素上带有这样的属性）的元素的 XLink 命名空间声明，而不论是否有 XLink 命名空间声明出现在例子中。
XLink 的命名空间提供全局属性给在任何的任意的命名空间中的元素使用。这些全局属性是 type、href、role、arcrole、title、show、actuate、label、from、和 to。文档作者在他们自己的命名空间内，或甚至在不属他们控制的命名空间内的元素使用 XLink 全局属性，这些元素都可看成是 XLink 元素。type 属性表明 XLink 元素的类型（simple、extended、locator、arc、resource、或 title）；元素类型规定 XLink 强制的约束，这些约束是 XLink 元素必须遵从的以及 XLink 应用程序遇到 XLink 元素必须采取的行为。
下面是一个有 XLink 全局属性的非 XLink 命名空间的 crossReference 元素的一个例子：
<my:crossReference
xmlns:my="http://example.com/"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:type="simple"
xlink:href="students.xml"
xlink:role="http://www.example.com/linkprops/studentlist"
xlink:title="学生名单"
xlink:show="new"
xlink:actuate="onRequest">
现有学生的名单
</my:crossReference>
|
使用全局属性总是需要在各个属性上使用命名空间前缀并在元素上使用类型属性。
4.1 XLink 属性用法模式
由于 XLink 属性使用命名空间机制而被看做是全局的时候，他们在任何一个 XLink 元素类型上所允许的组合极大地依赖于他们所在的元素的特定的 type 属性的值（更多的信息请参看5.3 XLink 元素类型属性（type））。本规格说明的一致性限制的注释详细说明了他们所允许的用法模式。以下是不同元素类型（列）所允许的全局属性（行）的概要，并给出其值是否是必有项（R）或可选项（O）：
simple |
extended |
locator |
arc |
resource |
title |
|
|---|---|---|---|---|---|---|
type |
R | R | R | R | R | R |
href |
O | R | ||||
role |
O | O | O | O | ||
arcrole |
O | O | ||||
title |
O | O | O | O | O | |
show |
O | O | ||||
actuate |
O | O | ||||
label |
O | O | ||||
from |
O | |||||
to |
O |
（另外参看B DTD 样本所提供的演示属性所允许模式的非标准的 DTD。）
本规格说明使用“xxx-类型元素”的格式来指那些必须附着于与 XLink 元素类型相关的有名称的限制集合的元素，而无论该元素实际上的名称是什么。例如，“locator-类型元素”会涉及所有的下列各项元素：
<locator xlink:type="locator" ... />
<loc xlink:type="locator" ... />
<my:pointer xlink:type="locator" ... />
|
4.2 XLink 元素类型关系
各种不同的 XLink 元素类型以其他的 XLink 元素类型的直接孩子的方式出现的时候，由本规格说明规定的他们特有的含义。以下是在特定的父母元素类型中扮演重要角色的孩子元素类型的概要（其他的组合则没有 XLink 规定的重要性）。
| 父类型 | 重要的自类型 |
|---|---|
simple |
none |
extended |
locator，arc，resource，title |
locator |
title |
arc |
title |
resource |
none |
title |
none |
4.3 属性值的缺省
使用 XLink 可能涉及使用很多的属性来提供重要的链接信息。在特定类型的所有文档的每一个实例中，期望的属性值都不变的情况下， 可能添加属性缺省值（固定的或不固定的）到 DTD 中，以便这些属性无须具体地出现在元素开始标签上。例如，在4 XLink 置标的设计 XLink 属性置标设计介绍中的例子中，如果对 xmlns:xlink，xmlns:my，type，show，和 actuate属性提供了的缺省，则该例看起来将会是这样：
<my:crossReference
xlink:href="students.xml"
xlink:role="http://www.example.com/linkprops/studentlist"
xlink:title="学生名单">
现有学生的名单
</my:crossReference>
|
在由 DTD 控制下生成的数据集合所有的属性值将已填写完成。
4.4 整合 XLink 用法与其他的置标
本规格说明只定义在 XLink 命名空间中的属性和属性值，没有限制非 XLink 属性与 XLink 属性一起使用。此外，大多数的 XLink 属性是可选项，而且选择简单或扩展链接是由置标设计者或文档创作者决定，因此，使用 XLink 特征的 DTD 不需要使用或声明整个的 XLink's 的属性集合。最后，虽然本规格说明在 XLink 置标上的只确定了最小限制，使用 XLink 的 DTD 可以随意的加强这些限制。XLink 的使用不排除有效的文档遵从它所属的 DTD 中所表达的限制。
以下是既有 XLink 又有非 XLink 属性的 crossReference 元素的例子：
<my:crossReference
xmlns:my="http://example.com/"
my:lastEdited="2000-06-10"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:type="simple"
xlink:href="students.xml">
现有学生的名单
</my:crossReference>
|
5 XLink 元素和属性
XLink 提供两种类型的链接：
- 扩展链接
-
扩展链接提供完整的 XLink 功能，比如输入和第三方弧，以及有任意数目分享资源的链接。作为结果，他们的结构可能是相当复杂的，包括指向远程资源的元素，含有本地资源的元素，指定弧游历规则的元素，以及用于描述人类可读的资源和弧的标题。
XLink 定义了一个方法来给扩展链接特别的语义以便寻找链结库；使用这种方法，扩展链接帮助 XLink 应用程序处理其他的链接。
- 简单链接
-
简单链接提供简写的语法给一种常用的链接类型，即一个输出链接带有正好两个分享资源（成为 HTML风格的
A和IMG链接状况）。因为简单的链接提供比扩展链接少的功能，他们没有特别的内在结构。简单链接从概念上是扩展链接的一个子集，但他们在语句构成上却不同。例如，把一个简单链接转换成扩展链接时，需要变化一些结构。
以下各节定义了 XLink 各类的元素和属性。
5.1 扩展链接（extended-类型元素）
［定义：扩展链接是一个联合任意个数目的资源的链接，分享资源可能是远程和本地的任何组合。］
唯一一种可以有输入和第三方弧的链接是扩展链接。在典型的情况下，扩展链接元素与它们相关联的资源分开储存（例如，存在完全地不同的文档中）。因此，扩展链接对以下几种情形是重要的：只读的分享资源；修改及更新资源的代价高，而修改及更新分开的链接元素的代价底；或是资源内在的格式并不支持植入链接（例如许多多媒体的格式）。
下列图表展示了一个联合五个远程资源的扩展链接。举例来说，这可以表示关于学生的课程负荷资讯：一个资源是一个学生的描述、一个为该学生的大学指导老师的描述、另外两个代表该学生正在参加的课程，最后的资源表现该学生旁听的课程。
没有扩展链接，资源可能完全不相关；例如，他们可能是在五个分开的文档中。从扩展链接发源的线表示它在资源之中创建的联系。虽然，线上没有标明定向性。定向性是与游历的规则一起表示的；没有提供这样的规则的话，资源的联系则没有特别的顺序，也没有提示资源是否和如何存取。
下面的图表显示了一个扩展链接联系了五个远程资源和一个本地资源（一个特别的元素在扩展链接元素之内）。这可以当然表现与上例相同的课程负荷例子，并附加了学生的平均分数的储存。同样，线仅仅只表示了表现了六个资源的联系，而没有游历的方向或行为提示。
用于扩展链接的 XLink 元素类型是任何有一个属于 XLink 命名空间的、且名为 type 值为“extended”的属性的元素。
extended-类型元素可能包含下列元素的任意顺序的混合并可能同其他的内容和置标混合在一起：
-
对分享链接的远程资源定位的
locator-类型元素 -
为链接分享的资源间提供游历规则的
arc-类型元素 -
给链接提供人类可读的标题的
title-类型元素 -
提供分享链接的本地资源的
resource-类型元素
extended-类型元素联合少于两个的资源并不是一个错误。如果这样的链接只有一个、或根本没有分享资源，它只是不能游历而已。这样的链接仍然可能是有用的，例如，可通过 XLink 属性来联系独立资源的特性，或者提供最终用于填充链接信息的占位符。
在 extended-类型父元素之内任何地方的 simple 或 extended 类型的子元素都没有 XLink 所载明的涵义。不是 extended-类型的直接孩子的 locator，arc 或 resource 类型的子元素则没有 XLink 所载明的涵义。
extended-类型元素可能有与语义有关的 role 和 title 属性（参看5.5 语义属性（role，arcrole，和 title））。它们提供链接整体上的与语义有关的资讯；role 属性指出整个链接所具有的特性，而 title 属性提供人类可读的整个链接的描述。如果其他 XLink 属性出现在该元素，他们对该链接都没有 XLink 所载明的关系。如果一个标题 title 属性和一个或多个的 title-类型属性出现在该元素，他们对该链接都没有 XLink 所载明的关系；在 XLink 上建造的高层应用程序或许将会对在这情况指定适当的处理方法例如，使用优先顺序）。
例子：extended-类型元素的声明和实例的范例
以下是一个声明 extended-类型元素及其子元素的非标准的集合。该例子的各部份被重复使用在本规格说明中各处。注意为了要突出在每一实例基础上变更的属性，type 属性及其他的一些属性在 DTD 中设为缺省。
<!ELEMENT courseload ((tooltip|person|course|gpa|go)*)>
<!ATTLIST courseload
xmlns:xlink CDATA #FIXED "http://www.w3.org/1999/xlink"
xlink:type (extended) #FIXED "extended"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED>
<!ELEMENT tooltip ANY>
<!ATTLIST tooltip
xlink:type (title) #FIXED "title"
xml:lang CDATA #IMPLIED>
<!ELEMENT person EMPTY>
<!ATTLIST person
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT course EMPTY>
<!ATTLIST course
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #FIXED "http://www.example.com/linkprops/course"
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!-- GPA = "平均分数" -->
<!ELEMENT gpa ANY>
<!ATTLIST gpa
xlink:type (resource) #FIXED "resource"
xlink:role CDATA #FIXED "http://www.example.com/linkprops/gpa"
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT go EMPTY>
<!ATTLIST go
xlink:type (arc) #FIXED "arc"
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED
xlink:from NMTOKEN #IMPLIED
xlink:to NMTOKEN #IMPLIED>
|
以下是 XML 元素使用这些声明看起来的可能的样子。
<courseload>
<tooltip>棒-琼斯的课程负荷</tooltip>
<person
xlink:href="students/patjones62.xml"
xlink:label="student62"
xlink:role="http://www.example.com/linkprops/student"
xlink:title="棒-琼斯" />
<person
xlink:href="profs/jaysmith7.xml"
xlink:label="prof7"
xlink:role="http://www.example.com/linkprops/professor"
xlink:title="笨-斯密司博士" />
<!-- 更多的教授、教学助手、及其他的远程资源 -->
<course
xlink:href="courses/cs101.xml"
xlink:label="CS-101"
xlink:title="计算机科学 101" />
<!-- 更多的课程、研究会、及其他的远程资源 -->
<gpa xlink:label="PatJonesGPA">3.5</gpa>
<go
xlink:from="student62"
xlink:to="PatJonesGPA"
xlink:show="new"
xlink:actuate="onRequest"
xlink:title="棒-琼斯的平均成绩" />
<go
xlink:from="CS-101"
xlink:arcrole="http://www.example.com/linkprops/auditor"
xlink:to="student62"
xlink:show="replace"
xlink:actuate="onRequest"
xlink:title="棒-琼斯，旁听本课程" />
<go
xlink:from="student62"
xlink:arcrole="http://www.example.com/linkprops/advisor"
xlink:to="prof7"
xlink:show="replace"
xlink:actuate="onRequest"
xlink:title="笨-斯密司博士，指导老师" />
</courseload>
|
5.1.1 扩展链接的本地资源（resource-类型元素）
扩展链接通过在扩展链接内出现的特定子元素的方式标明它所分享的本地资源。整个的子元素，连同它的全部内容一起构成本地资源。
本地资源的 XLink 元素是任何带有一个属于 XLink 命名空间的、名为 type 且值为“resource”的属性的元素。
resource-类型元素可能有任何的内容；不论出现的是什么内容对链接都没有 XLink 所载明的关系。resource-类型元素可能没有内容；在这样的情况下它被用作出发资源，预期在接到请求时开始游历，交互式 XLink 应用程序典型地将会产生一些内容以便给用户一个方法开始该游历。如果 resource-类型元素有除了 extended-类型元素之外的其它的父母，resource-类型元素则没有 XLink 所载明的涵义。
The resource-类型元素可能有与语义有关的 role 和 title属性（参看5.5 语义属性（role，arcrole，和 title））和游历的属性 label（参看5.7 游历属性（label，from，和 to））。语义有关的属性在引导它的特定弧的内容以外提供关于资源的总体资讯；role属性标示资源的一个特性，而和 title 属性标示人类可读的资源的描述。label 属性提供一个方法给 arc-类型元素在创建游历的弧时能引用它。
例子：resource-类型元素声明及实例的样本
以下是一个 resource-类型元素的声明的非标准集合。
<!ELEMENT gpa ANY>
<!ATTLIST gpa
xlink:type (resource) #FIXED "resource"
xlink:role CDATA #FIXED "http://www.example.com/linkprops/gpa"
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
|
以下是 XML 元素使用这些声明看起来的可能的样子。
<gpa xlink:label="PatJonesGPA">3.5</gpa>
|
5.1.2 扩展链接的远程资源（locator-类型元素）
扩展链接标示通过定位器元素分享的远程资源。
用于定位器的 XLink 元素是任何有一个属于 XLink 命名空间的、且名为 type 的值为 “locator” 的属性的元素。
locator-类型元素可能有任何的内容。除了 title-类型元素是直接的孩子外（参看5.1.4 扩展链接、定位器、及弧的标题（title-类型元素）），无论出现什么内容对链接都没有 XLink 所载明的关系。如果 locator-类型元素包含嵌套的 XLink 元素，有这样的包含元素对父链接则没有 XLink 所载明的关系。如果 locator-类型元素有除了扩展- 类型元素之外的父，该 locator-类型元素则没有 XLink 所载明的涵义。
locator-类型元素必须有定位器属性（参看5.4 定位器属性（href））。定位器属性（href）必须有提供一个数值。
locator-类型元素可能有与语义有关的 role 和 title 属性（参看 5.5 语义属性（role，arcrole，和 title））和游历的 label 属性（参看5.7 游历属性（label，from，和 to））。定位器属性提供识别一个远程资源的 URI 引用。与语义有关的属性在引导它的特别弧的内容外，提供关于资源的总体资讯；role 属性标示资源有的一个特性，而 title 属性标示人类可读的资源的描述。标示属性提供一个方法给一个 arc-类型元素在创造游历的弧方面引用它。
注意：
locator-类型元素本身不能构成一个链接因为它仅仅有一个定位器（href）属性；不像一个 simple-类型元素，它不生成在它本身和引用资源之间的由 XLink 管理的联系。
例子：locator-类型元素声明和实例的范例
以下是 locator-类型元素声明一个非标准集合。
<!ELEMENT person EMPTY>
<!ATTLIST person
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT course EMPTY>
<!ATTLIST course
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #FIXED "http://www.example.com/linkprops/course"
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
|
以下是 XML 元素使用这些声明看起来的可能的样子。
<person
xlink:href="students/patjones62.xml"
xlink:label="student62"
xlink:role="http://www.example.com/linkprops/student"
xlink:title="帕特 琼斯" />
<person
xlink:href="profs/jaysmith7.xml"
xlink:label="prof7"
xlink:role="http://www.example.com/linkprops/professor"
xlink:title="笨-斯密司博士" />
<course
xlink:href="courses/cs101.xml"
xlink:label="CS-101"
xlink:title="Computer Science 101" />
|
5.1.3 扩展链接的游历规则（arc-类型元素）
扩展链接可能通过一连串可选择的弧元素来表明分享链接的资源之间的游历规则。
用于弧的 XLink 元素是任何有一个属于 XLink 命名空间的、且名为 type 值为“arc”的属性的元素。
arc-类型元素可能有任何的内容。除了是直接孩子的 title-类型元素之外（参看 5.1.4 扩展链接、定位器、及弧的标题（title-类型元素）），无论什么内容都对链接都没有 XLink 所载明的关系。如果 arc-类型元素有除了extended-类型元素之外的任何元素为父，那么，该 arc-类型元素则没有 XLink 所载明的涵义。
arc-类型元素可能有游历属性 from 和 to（5.7 游历属性（label，from，和 to））、行为属性 show 和 actuate（参看5.6 行为属性（show 和 actuate））以及语义属性 arcrole 和 title（参看5.5 语义属性（role，arcrole，和 title））。
游历属性定义分享同一链接的资源对之间所期望的游历，这些资源由他们的 label 属性的值标示。 from 属性定义可能开始的资源，也就是出发资源，而属性 to 定义可能游历到的资源，也就是终止资源。行为属性为 XLink 应用程序指定游历向终止资源时所期望的行为。
语义属性描述与出发资源的有关的弧的终止资源的意义。arcrole 属性对应于［RDF］的特性概念，而 role 可以解释成“出发-资源 有弧-角色终止-资源。”当把这个与上下文有关的角色从这个特定的弧的上下文中拿走时，它可能不同于终止资源的意义。举例来说，资源可能关于泛泛地代表一个“人”，但是在特定的弧上下文中，它可能是个“母亲”的角色，在另一个不同弧的上下文中，它可能是个“女儿”的角色。
当同一资源在一些弧（不论是在一个单独链接中或跨越许多的链接）中都用作出发资源的时候，游历-请求行为不受本规格说明的限制，但是，对交互式应用程序来说的一种可能性是一个列出有关的弧、或链接标题的跳出式的菜单。
以下图表展示了联系五个远程资源的一个扩展链接，而且提供了在他们之中游历的规则。所有指定的弧都是第三方弧；也就是说，弧仅仅只在远程资源之间。像上面一样，无向性实线标示链接正联合着五个其它的资源；新的带箭头的虚线标示链接提供的游历的规则。注意一些资源享有相同的 label 值。
这一个图表反映按以下设置来建立的方向游历弧，在这些弧中的 A 和 C 都允许开始对所有的 B 的地方游历。因为有的标示在几个资源上都出现，每个弧的规格说明潜在地能同时产生几个游历弧：
<go xlink:type="arc" xlink:from="A" xlink:to="B" />
<go xlink:type="arc" xlink:from="C" xlink:to="B" />
|
作为另外个例子，假设一个包含五个定位器的扩展链接，其中两个 label 的值为 “parent” 而另外三个 label 的值为 “child” ：
<extendedlink xlink:type="extended">
<loc xlink:type="locator" xlink:href="..." xlink:label="parent" xlink:title="p1" />
<loc xlink:type="locator" xlink:href="..." xlink:label="parent" xlink:title="p2" />
<loc xlink:type="locator" xlink:href="..." xlink:label="child" xlink:title="c1" />
<loc xlink:type="locator" xlink:href="..." xlink:label="child" xlink:title="c2" />
<loc xlink:type="locator" xlink:href="..." xlink:label="child" xlink:title="c3" />
... <!-- arc-类型元素将出现在这里 -->
</extendedlink>
|
以下描述了从父资源到孩子资源的游历，包括所有的 p1-c1、p1-c2、p1-c3、p2-c1、p2-c2、和 p2-c3：
<go xlink:type="arc" xlink:from="parent" xlink:to="child" /> |
如果没有为 from 或 to 属性提供值，缺少的值被解释成代表在该 extended-类型元素里的所有 locator-类型元素上提供的标示。例如，以下描述了从父到孩子以及从孩子到孩子的游历，包括所有的 p1-c1、p1-c2、p1-c3、p2-c1、p2-c2、p2-c3、c1-c1、c1-c2、c1-c3、c2-c1、c2-c2、c2-c3、c3-c1、c3-c2、 and c3-c3：
<go xlink:type="arc" xlink:to="child" /> |
在这情况下，注意游历的规则包括带有相同的标示的从某些资源到其他资源的弧（从一个孩子到其它孩子），以及从一些资源到他们自己本身（从一个孩子到它本身）；这并不是一个错误。
在扩展链接里如果没有提供 arc-类型元素，那么，缺少的 from 和 to 通过扩展的值被解释成在那个链接里的所有的标示。这等价于对以下游历的规格说明：
<go xlink:type="arc" /> |
当超过一个定位器有相同的标示，带有相同的标示定位器的集合被理解成单独的定位器，而不是当做一个聚合资源；这样一个链接可能是与一个所有的定位器有不同的角色并指定适当的弧来生成相同的游历对的链接的游历行为相同。
如果扩展链接弧的游历规则省去任何可能的游历对，XLink 则没有对这些对定义游历。高层应用程序可能运行的一个非 XLink 引导的游历；例如，检查链接的步骤可能游历所有可能的资源对。
每一个 arc-类型元素必须有一对 from 和 to 的值，这些值（分别地）不与在同一的扩展链接中的任何其他的 arc-类型元素的 from 和 to 的值重复，也就是说，链接里的每一对必须是独一无二的。
例子：arc-类型元素声明和实例的范例
以下是一个 arc-类型元素声明的非标准的集合。
<!ELEMENT go EMPTY>
<!ATTLIST go
xlink:type (arc) #FIXED "arc"
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED
xlink:from NMTOKEN #IMPLIED
xlink:to NMTOKEN #IMPLIED>
|
以下是 XML 元素使用这些声明看起来的可能的样子。
<go
xlink:from="student62"
xlink:to="PatJonesGPA"
xlink:show="new"
xlink:actuate="onRequest"
xlink:title="棒-琼斯的平均成绩" />
<go
xlink:from="CS-101"
xlink:arcrole="http://www.example.com/linkprops/auditor"
xlink:to="student62"
xlink:show="replace"
xlink:actuate="onRequest"
xlink:title="棒-琼斯，旁听本课程" />
<go
xlink:from="student62"
xlink:arcrole="http://www.example.com/linkprops/advisor"
xlink:to="prof7"
xlink:show="replace"
xlink:actuate="onRequest"
xlink:title="笨-斯密司博士，指导老师" />
|
5.1.4 扩展链接、定位器、及弧的标题（title-类型元素）
extended-、locator-、和 arc-类型元素可能有 title 属性（更多信息参见5.5 语义属性（role，arcrole，和 title））。然而，他们也可能有一连串的一个或多个的 title-类型元素。例如，在人类可读的标示信息需要进一步地元素置标的情况下、或者是多个标题是必需的情况下，这样的元素很有用的。使用 title-类型元素的常见的一个动机是为了解决国际化和本地化的问题。例如，标题置标可能对双向性上下文或是在东亚语言中是必需的，而且多重标题对标题的不同自然语言版本可能是必需的。
用于标题的 XLink 元素是任何有一个属于 XLink 命名空间的、且名为 type 值为 “title” 的属性的元素。
title-类型元素可能有任何的内容。如果 title-类型元素包含有嵌套的 XLink 元素，有这样的嵌套元素对包含标题的父链接则没有 XLink 所载明的关系。如果 title-类型元素有除了 extended-、locator-、或 arc-类型元素以外的父，该 title-类型元素则没有 XLink 所载明的涵义。
例子：title-类型元素的声明和实例的范例
以下是一个关于 title-类型元素声明的非标准的集合。该元素已经被赋予 xml:lang 属性，这个属性可能与服务器的设定或其他的上下文的信息一起来决定所使用的标题。
<!ELEMENT advisorname (name)>
<!ATTLIST advisorname
xlink:type (title) #FIXED "title"
xml:lang CDATA #IMPLIED>
<!ELEMENT name (honorific?, given, family)>
<!-- 更多的 name 的子元素声明 -->
|
以下是 XML 元素使用这些声明看起来的可能的样子。
<advisor xlink:href="profs/jaysmith7.xml" ...>
<advisorname xml:lang="zh">
<name>
<honorific>博士</honorific>
<given>笨</given>
<family>斯密司</family>
</name>
</advisorname>
</advisor>
|
5.1.5 定位链接库（特别的弧角色）
对于要从出发资源游历到终止资源的 XLink 应用程，它需要找出出发资源和链接。在输出弧的情况下，找出这两个信息不是个问题，因为出发资源不是链接元素本身就是链接元素的一个孩子。但是，在输入和第三方弧的情况下，XLink 应用程序则需要以某种方式找到着两个信息。
在课程负荷例子中，扩展链接能联合远程资源对来表示学生和课程。为了使系统能以提供游历相关信息的方式（例如，允许用户在学生的名字上点一下来游历到她所注册的课程的关于资讯）载入并呈现一个“学生资源”（如一个人的描述和照片），它需要找出并且使用包含这些联系的扩展链接。
链结库常藉着将许多相关的链接元素聚集在一起，来使链接管理更加容易。XLink 提供让 XLink 应用程序存取可能的有关的链结库的方法。指令采用弧的规格说明（无论是在扩展链接中明确指定，或在简单链接中隐式地指定）的形式，该规格说明对于它的弧型角色属性有以下的值：
http://www.w3.org/1999/xlink/properties/linkbase |
在带有这个特定的值的弧的终止资源中所描述的任何链结库必须是 XML 文档。
（XLink 应用程序可能使用任何其他的方法找出并处理额外的链结库。）
处理链结库的弧非常像处理一般的弧，不是将它呈现给用户或运行一些另外地处理，除了游历需要载入终止资源（链结库）来析取它的链结以备稍后使用外。该处理在 XLink 应用程序在用户的选择下必须延缓链结库弧的游历方面也是特殊的。
尤其是在载入链结库弧时，XLink 应用程序应该保持跟踪什么是出发资源。每当载入包含出发资源的文档，和链结库弧的游历被激活时，应用程序应该访问链结库并析取在其中发现的任何的扩展链接。在被析取的资源是一个完全的 XML 文档的一部分时，例如一个范围或字串范围，应该仅仅可以使用那些完全地包含在析取部分内的扩展链接。
链结库弧游历的时间安排由弧的 actuate 属性来决定。例如，如果该值是 "onLoad"，则一旦载入出发资源，就载入链结库并析取它的链接。必须忽略任何在链结库弧上的 show 属性的值，因为游历在这情况下不需要承担呈现的任务。
链结库可能由于被用作出发资源同时又是另一个链结库弧而成为链状的。解释起始链结库弧的应用程序可能选择限制在链中处理步骤的数目。
应用程序应该维护一个处理链结库的检索结果的扩展链接的清单，而且不应该检索重复的的资源或存在循环依赖的情况下的链接。为了简化 XLink 的处理，文档创建者可能愿意在接近文档开始的地方定义链结库弧。
例子：注解一个规格说明
以下是一个关于专用于提供链结库弧的扩展链接声明的非标准的集合：
<!ELEMENT basesloaded ((startrsrc|linkbase|load)*)>
<!ATTLIST basesloaded
xlink:type (extended) #FIXED "extended">
<!ELEMENT startrsrc EMPTY>
<!ATTLIST startrsrc
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT linkbase EMPTY>
<!ATTLIST linkbase
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT load EMPTY>
<!ATTLIST load
xlink:type (arc) #FIXED "arc"
xlink:arcrole CDATA #FIXED "http://www.w3.org/1999/xlink/properties/linkbase"
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED
xlink:from NMTOKEN #IMPLIED
xlink:to NMTOKEN #IMPLIED>
|
以下是使用这些声明的一个 XML 元素看起来可能的样子。这表示当一个规格说明文档载入时，一个充满对它注解的链结库也应该自动地载入，这可能迫使重新解析整个的规格说明文档来揭示它里面的任何用作在链结库内发现的链接中的开始资源的区域。
<basesloaded>
<startrsrc xlink:label="spec" xlink:href="spec.xml" />
<linkbase xlink:label="linkbase" xlink:href="linkbase.xml" />
<load xlink:from="spec" xlink:to="linkbase" actuate="onLoad" />
</basesloaded>
|
如果在请求下载入了链结库，下面是使用这些声明的一个 XML 元素看起来可能的样子。这一次，出发资源由“点一下在这里查看注解。”这几个字所组成。当以上的例子中，如果出发资源是整个文档，证实的对话窗会是一个允许用户激活游历的合理的行为。
<basesloaded>
<startrsrc
xlink:label="spec"
xlink:href="spec.xml#string-range(//*,'点一下在这里查看注解。')" />
<linkbase xlink:label="linkbase" xlink:href="linkbase.xml" />
<load xlink:from="spec" xlink:to="linkbase" actuate="onRequest" />
</basesloaded>
|
5.2 简单链接（simple-类型元素）
［定义：简单链接是一个正好联合两个资源的链接，两个资源的一个为本地、一个为远程，弧从前者走向后者。因此，简单链接总是一个输出链接］。
简单链接的目的是作为等价的扩展链接的方便的简写。一个单独的简单链接元素联合了 extended-类型元素、locator-类型元素、arc-类型元素和 resource-类型元素的基本功能。
以下图表显示了简单链接的特性；它联合一个本地和一个远程资源，而且隐式地提供了一个单独的从本地资源到远程资源的游历弧。举例来说，这可以代表在本文中出现的学生名字，当点一下该名字时，则得到关于学生的资讯。
例子：通过扩展链接来实现简单链接的功能
简单链接能大致上用下面的方法由扩展链接来表现：
<studentlink xlink:type="extended">
<resource
xlink:type="resource"
xlink:label="local">棒-琼斯</resource>
<locator
xlink:type="locator"
xlink:href="..."
xlink:label="remote"
xlink:role="..."
xlink:title="..." />
<go
xlink:type="arc"
xlink:from="local"
xlink:to="remote"
xlink:arcrole="..."
xlink:show="..."
xlink:actuate="..." />
</studentlink>
|
简单链接综合上面 (除了类型和标示以外)的所有的功能在一个单独元素内。对于那些只需要这个特点子集的情况，简单链接元素可以是扩展链接元素的替换。从简单链接中失去的功能包括以下列各项：
-
提供任意数目的本地和远程资源
-
指定一个从远程资源到本地资源的弧
-
将标题与单独的硬连线弧相联系
-
将角色或标题与本地资源相联系
-
整个地将角色或标题与链接相联系
用于简单链接的 XLink 元素是任何有一个属于 XLink 命名空间的、且名为 type 值为 “simple” 的属性的元素。上述扩展链接的简单同价式等如下所示：
<studentlink xlink:href="...">棒-琼斯</studentlink> |
simple-类型元素可能有任何的内容。simple-类型元素本身，连同它全部的内容，是链接的本地资源，仿佛元素是一个 resource-类型元素。如果一个 simple-类型元素包含嵌套的 XLink 元素，有这样包含的元素对父链接的则没有 XLink 规定的关系。simple-类型元素可能没有内容；在链接因请求而期望进行游历的情况下，交户式 XLink 应用程序通常将会产生一些内容以便给用户一个开始游历的方法。
simple-类型元素有效地得到来自定位器的属性 href 和 locator-类型元素的语义属性 role 和 title、行为属性 show 和 actuate 、以及来自 arc-类型元素的单纯与语义有关的属性 arcrole。
simple-类型元素没有定位器（href）属性值并不是个错误。如果没有提供一个值，链接只是不能游历。这样的链接仍然可能是有用的，例如，通过 XLink 属性使特性和资源相联系。
例子：simple-类型元素声明和实例的范例
以下是一个simple-类型元素的声明的非标准的集合。
<!ELEMENT studentlink ANY>
<!ATTLIST studentlink
xlink:type (simple) #FIXED "simple"
xlink:href CDATA #IMPLIED
xlink:role NMTOKEN #FIXED "http://www.example.com/linkprops/student"
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED>
|
以下是一个 XML 文档使用这些声明可能看起来的样子。
．．．，而且<studentlink xlink:href="students/patjones62.xml">棒-琼斯</studentlink>在学生会里很受欢迎。 |
5.3 XLink 元素类型属性（type）
用于指定 XLink 元素类型的属性是 type。
当 type 属性的值为“none”时，元素则没有 XLink 所载明的意义，而且任何 XLink 相关的内容或属性对该元素都没有 XLink 所载明的关系。
例子：type 属性声明范例
以下是一个关于预定要成为 simple-类型的元素其上的 type 的非标准的属性列表的声明。
<!ATTLIST xlink:simple
xlink:type (simple) #FIXED "simple"
...>
|
对于一个只在一些场合上作为 XLink 元素的元素，其声明可能如下，其中文档创建作者在一些情形下设定该值为 “simple” 而在其它的情形下设定该值为 “none”。在帮助 XLink 应用程序避免检查是否有 href 的值方面，使用 “none” 可能是有用的。
<!ATTLIST commandname
xlink:type (simple|none) #REQUIRED
xlink:href CDATA #IMPLIED>
|
5.4 定位器属性（href）
提供数据给 XLink 应用程序寻找远程资源（或资源片段）的属性是 href。它可能使用在 simple-类型元素上，而必须使用在 locator-类型元素上。
href 属性的值必须是由［IETF RFC 2396］所定义的 URI 引用，或者，在使用了下面所描述的转码过程后的结果必须是 URI 引用。该过程使用在将 URI 引用传递给 URI 解析器的时候。
一些字符即使在 XML 中是允许使用的，但在 URI 引用中却不允许。不允许的字符包括所有非 ASCII 字符、以及在［IETF RFC 2396］的第 2.4 节中列出的拒绝接纳的字符，除了在［ IETF RFC 2732 ］中重新允许的数目符（#）、百分号（%）和方括符外。不允许的字符必须依下列各项来转码：
-
每个不允许的字符转换成一个或多个的 UTF-8［IETF RFC 2279］字节。
-
与不允许的字符所对应的任何字节通过 URI 的转换机制来转换（也就是说，转换成
%HH，HH 是字节值的十六进制的表示法）。 -
原来的字符由生成的字符序列来代替。
因为由任何应用程序来检查一个值是否是 URI 引用是不切实际的，本规格说明在这个问题上依照［IETF RFC 2396］的引导，而没有对 XLink 应用程序强制一致性测试这样的需求。
URI 引用是相对的，它的绝对的版本在使用前必须按照［XML Base］的方法来计算。
对于进入 XML 资源内部的定位器，在 URI 引用里面使用的片段的识别符（如果有的话）的格式，则由XPointer 规格说明［XPTR］来指定。
例子：href 属性声明范例
以下是一个关于预定要成为 simple-类型的元素其上的 href 的非标准的属性列表的声明。
<!ATTLIST simplelink
xlink:href CDATA #REQUIRED
...>
|
5.5 语义属性（role，arcrole，和 title）
在链接的上下文里面描述资源的意义属性是 role、arcrole、和 title。role 属性可能用在 extended-、simple、locator-、和 resource-类型元素上。arcrole 属性可能用在 arc-、和 simple-类型元素上。title 属性可能用在所有这些类型的元素上。
role 或 arcrole 属性的值必须是由［IETF RFC 2396］所定义的 URI 引用，除了如果所使用的 URI 方案允许有绝对的和相对的形式，URI 部分必须是绝对的。URI 引用标示一些描述想要的特性的资源。没有提供值的时，则不会推导出特别的 role 值。这些属性中所不允许的 URI 引用字符必须按5.4 定位器属性（href）所描述的特别地转码。
title 属性同 role 或 arcrole 属性一起（不过，也参看5.1.4 扩展链接、定位器、及弧的标题（title-类型元素））以人类可读的形式来描述链接或资源的意义。值是可选项；如果提供一个值，它应该包含一个描述资源的字串。这项信息的使用极大地依赖于正在进行处理的类型。举例来说，它可能提供标题给视觉上有弱视的用户的应用程序，或生成一个链接的列表，或当用户用鼠标指在出发资源上方附近的时候出现帮助本文。
例子：role 和 title 属性声明的范例
以下是一个关于预定要成为 simple-类型的元素其上的 role 和 title 的非标准的属性列表的声明。
<!ATTLIST simplelink
...
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
...>
|
以下是一个关于预定要成为 arc-类型的元素其上的 arcrole 和 title 的非标准的属性列表的声明。
<!ATTLIST go
...
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
...>
|
5.6 行为属性（show 和 actuate）
行为属性是 show 和 actuate。他们可能用在 simple- 和 arc-类型元素。当用在 simple-类型元素上时，他们向单个的远程终止资源发出游历行为意图的信号。当用在 arc-类型元素上时，他们向由该弧指定的所有（远程或本地的）终止资源发出游历行为意图的信号。
show 和 actuate 属性不是必须有的。当使用他们时，遵从 XLink 的应用程序应该按本节指定的方式使用。因为它们对像是浏览器这样的交互式应用程序是有意义的，而对像 robot 这样的非交互式应用程序是却不太可能有意义，所以对这种使用没有硬性（“must”）的要求。虽然如此，所有的应用程序应该在选择不同的线路之前考虑忽略指定的行为的完全的含意。
例子：show 和 actuate 属性声明的范例
以下是一个关于预定要成为 simple-类型的元素其上的 show 和 actuate 的非标准的属性列表的声明。
<!ATTLIST simplelink
xlink:type (simple) #FIXED "simple"
...
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED
...>
|
遇到在链结库列表中的 arc-类型类型元素的应用程序必须使用其行为属性，仿佛他们被指定成 show="none" 和 actuate="onLoad"，即使已指定了其他的值。
5.6.1 show 属性
show 属性用来传达来自出发资源的游历上所期望的终止资源的表现方法。
如果提供了show 属性的值，则该值必须是 “new”、“replace”、“embed”、“other”、和 “none” 中的一个。
遵从 XLink 的应用程序应该对 show 值使用下列的处理：
- “new”
-
游历到终止资源的一个应用程序应该载入到新的窗囗、图文框、窗格、或其他的有关表现方法的上下文中。这与下列 HTML 片段所达成的效果类似：
<A HREF="http://www.example.org" target="_blank">...</A>
- “replace”
-
游历到终止资源的应用程序应该载入与载入出发资源的相同的窗囗、图文框、窗格、或其他的有关表现方法的上下文中。这与下列 HTML 片段所达成的效果类似：
<A HREF="http://www.example.org" target="_self">...</A>
- “embed”
-
游历到终止资源的应用程序应该载入到出发资源的呈现的地方。这与下列 HTML 片段所达成的效果类似：
<IMG SRC="http://www.example.org/smiley.gif" ALT=":-)">
出发资源典型地的表现方法不是由整个的文档组成；只有当文档的根元素是一个简单的链接时候，它才会是整个的文档。因此，嵌入通常与替换的效果明显不同。
正如 HTML
IMG元素，嵌入只影响相关的资源表示。它不表示出发资源的永久变化。换种说法，当处理嵌入的 XLink 时，链接的终止资源的式样结果融入到它所嵌入资源的式样结果中。相反地，当解析像 XInclude 元素 ［XInclude］ 这样的构造的时候，原来的 XML 实际上被转换到包括该引用的内容中。在本规格说明的本版本中没有定义当嵌入基于 XML（［IETF RFC 2376］ 或 ［IETF I-D XMT］）的终止资源时，遵从 XLink 的应用程序的行为。
嵌入的资源表现方法依赖于应用程序。
- “other”
-
游历到终止资源穿越的应用程序的行为不受本规格说明约束。应用程序应该在链接中寻找其他出现的置标来决定适当的行为。
- “none”
-
游历到终止资源的应用程序的行为不受本规格说明约束。没有其他出现的置标来帮助应用程序决定适当的行为。
像是在资源中不同的位置的一连串的字串范围，如果出发或终止资源由非邻近的多重的位置所组成，那么，应用程序行为则不受约束。（选择 XML 文档的部分的更多资讯参看［XPTR］。）
注意：
非邻近的终止资源的应用程序一些可能的行为包括：高光每个位置；生成对话框允许读者在位置之中做选择，好像有不同的弧引领到每一个位置；连接所有的位置内容一起表示，等等。非邻近的出发资源的应用程序行为可能包括连接和表现成为一个独立的单位，或创建一个弧发源于每个邻近的部分。
5.6.2 actuate 属性
actuate 属性用来传达从出发资源到终止资源的游历所期望的时机。
如果提供了 actuate 属性的值，则该值必须是 “onLoad”、“onRequest”、“other”、和 “none” 中的一个。
遵从 XLink 的应用程序应该对 actuate 值使用下列的处理：
- “onLoad”
-
在载入出发资源时，应用程序应该立即游历到终止资源。当用户代理设置成显示图像时，这与下列 HTML 片段所达成的有代表性的效果类似：
<IMG SRC="http://www.example.org/smiley.gif" ALT=":-)">
如果单个资源包含多个行为设定为
show="replace" actuate="onLoad"的弧，则应用程序的行为不受 XLink 的约束。 - “onRequest”
-
应用程序应该只在载入后有打算游历的事件触发后，才从出发资源到终止资源的游历。一个这样事件的例子可能是用户点击出发资源的显示，或者一个软件模块在改向之前完成倒数计时。
- “other”
-
游历到终止资源的应用程序的行为不受本规格说明约束。应用程序应该在链接中寻找其他出现的置标来决定适当的行为。
- “none”
-
游历到终止资源穿越的应用程序的行为不受本规格说明约束。没有其他出现的置标来帮助应用程序决定适当的行为。
A 参考资料
A.1 标准参考资料
- IETF I-D XMT
- XML Media Types. Makoto, M., St. Laurent, S. and D. Kohn, editors. Internet Engineering Task Force, 2001. (See http://www.ietf.org/rfc/rfc3023.txt.)
- IETF RFC 2396
- IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers. 1995. (See http://www.ietf.org/rfc/rfc2396.txt.)
- IETF RFC 2279
- RFC 2279: UTF-8, a transformation format of ISO 10646. Internet Engineering Task Force, 1998. (See http://www.ietf.org/rfc/rfc2279.txt.)
- IETF RFC 2376
- RFC 2376: XML Media Types. Internet Engineering Task Force, 1998. (See http://www.ietf.org/rfc/rfc2376.txt.)
- IETF RFC 2732
- RFC 2732: Format for Literal IPv6 Addresses in URL's. Internet Engineering Task Force, 1999. (See http://www.ietf.org/rfc/rfc2732.txt.)
- XML
- Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, and Eve Maler, editors. Extensible Markup Language (XML) 1.0 (Second Edition). World Wide Web Consortium, 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006.)
- IETF RFC 2119
- S. Bradner, editor. Key words for use in RFCs to Indicate Requirement Levels. March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
- XML Base
- Jonathan Marsh, editor. XML Base (XBase). World Wide Web Consortium, 1999. (See http://www.w3.org/TR/2001/REC-xmlbase-20010627/.)
- XML Names
- Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. World Wide Web Consortium, 1999. (See: http://www.w3.org/TR/1999/REC-xml-names-19990114/, See also: 中文翻译 [简体中文] ).
A.2 非标准参考资料
- CHUM
- Steven J. DeRose and David G. Durand. 1995. "The TEI Hypertext Guidelines." In Computing and the Humanities 29(3). Reprinted in Text Encoding Initiative: Background and Context, ed. Nancy Ide and Jean Ronis, ISBN 0-7923-3704-2.
- Dexter
- Halasz, Frank. 1994. “The Dexter Hypertext Reference Model.” In Communications of the Association for Computing Machinery 37 (2), February 1994: 30-39.
- FRESS
- Steven J. DeRose and Andries van Dam. 1999. “Document structure in the FRESS Hypertext System.” Markup Languages 1 (1) Winter. Cambridge: MIT Press: 7-32.（另参看 http://www.stg.brown.edu/~sjd/fress.html for more information.)
- HTML
- HTML 4.01 Specification. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/1999/REC-html401-19991224/.)
- Intermedia
- Yankelovich, Nicole, Bernard J. Haan, Norman K. Meyrowitz, and Steven M. Drucker. 1988. “Intermedia: The Concept and the Construction of a Seamless Information Environment.” IEEE Computer 21 (January, 1988): 81-96.
- ISO/IEC 10744
- 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 Facilities Annex. [Geneva]: International Organization for Standardization, 1996. (See http://www.y12.doe.gov/sgml/wg8/document/1920.htm.)
- MicroCosm
- Hall, Wendy, Hugh Davis, and Gerard Hutchings. 1996. Rethinking Hypermedia: The Microcosm Approach. Boston: Kluwer Academic Publishers. ISBN 0-7923-9679-0.
- OHS
- van Ossenbruggen, Jacco, Anton Eliens and Lloyd Rutledge. “The Role of XML in Open Hypermedia Systems.” Position paper for the 4th Workshop on Open Hypermedia Systems, ACM Hypertext '98. (See http://aue.auc.dk/~kock/OHS-HT98/Papers/ossenbruggen.html.)
- RDF
- Ora Lassila and Ralph Swick, editors. Resource Description Framework (RDF) Model and Syntax Specification. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.)
- TEI
- 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.
- XIS
- John Cowan and Richard Tobin, editors. XML Information Set. World Wide Web Consortium, 2001. (See http://www.w3.org/TR/2001/CR-xml-infoset-20010514/.)
- XLinkToRDF
- Ron Daniel, editor. Harvesting RDF Statements from XLinks. World Wide Web Consortium, 2000. (See http://www.w3.org/TR/2000/NOTE-xlink2rdf-20000929/.)
- XLinkNaming
- Eve Maler, Daniel Veillard and Henry S. Thompson, editors. XLink Markup Name Control. World Wide Web Consortium, 2000. (See http://www.w3.org/TR/2000/NOTE-xlink-naming-20001220/.)
- XInclude
- Jonathan Marsh and David Orchard, editors. XML Inclusions (XInclude) Version 1.0. World Wide Web Consortium, 2000. (See http://www.w3.org/TR/2001/WD-xinclude-20010516/.)
- XLREQ
- Steven DeRose, editor. XML XLink Requirements Version 1.0.World Wide Web Consortium, 1999. (See http://www.w3.org/TR/1999/NOTE-xlink-req-19990224/.)
- XLDP
- Eve Maler and Steve DeRose, editors. XML Linking Language (XLink) Design Principles.World Wide Web Consortium, 1998. (See http://www.w3.org/TR/1998/NOTE-xlink-principles-19980303.)
- XPTR
- Ron Daniel, Steve DeRose, and Eve Maler, editors. XML Pointer Language (XPointer) V1.0.World Wide Web Consortium, 1998. (See http://www.w3.org/TR/2001/WD-xptr-20010108/.)
B DTD 样本（非标准）
以下 DTD 对本规格说明没有指定的所有行为构造了一个不完整的 (为了争论的目的) XLink 构造。 它只提供方便给应用程序的开发者；它没有标准的地位。
对本 DTD 有以下的假设：
-
只允许那些有 XLink 定义的意义的构造。
-
因为 DTD 不能很好处理命名空间，所以在其中不混合“外来的”字汇。
-
使用ANY意味着通常在该元素中提供内容被 XLink 以某种方法使用。
-
使用
(title*)构造意味着任何提供非-title的内容都没有 XLink 定义的用途。 -
元素依它们代表的 XLink 元素类型来命名。
其他的假设和条件出现在 DTD 的注解之中。
<!ELEMENT simple ANY>
<!ATTLIST simple
xlink:type (simple) #FIXED "simple"
xlink:href CDATA #IMPLIED
xlink:role CDATA #IMPLIED
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED>
<!ELEMENT extended ((title|resource|locator|arc)*)>
<!ATTLIST extended
xmlns:xlink CDATA #FIXED "http://www.w3.org/1999/xlink"
xlink:type (extended) #FIXED "extended"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED>
<!ELEMENT title ANY>
<!-- xml:lang is not required, but provides much of the motivation
for title elements in addition to attributes, and so is provided
here for convenience -->
<!ATTLIST title
xlink:type (title) #FIXED "title"
xml:lang CDATA #IMPLIED>
<!ELEMENT resource ANY>
<!ATTLIST resource
xlink:type (resource) #FIXED "resource"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT locator (title*)>
<!-- label is not required, but locators have no particular XLink
function if they are not labeled -->
<!ATTLIST locator
xlink:type (locator) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:label NMTOKEN #IMPLIED>
<!ELEMENT arc (title*)>
<!-- from and to have default behavior when values are missing -->
<!ATTLIST arc
xlink:type (arc) #FIXED "arc"
xlink:arcrole CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:show (new
|replace
|embed
|other
|none) #IMPLIED
xlink:actuate (onLoad
|onRequest
|other
|none) #IMPLIED
xlink:from NMTOKEN #IMPLIED
xlink:to NMTOKEN #IMPLIED>
|
C 工作组成员及感谢（非标准）
这一个规格说明是 XML 链接工作小组的工作成果，并藉由以下在完成本规格说明中的活跃的成员:
- Peter Chen, LSU, Bootstrap Alliance
- Ron Daniel, Interwoven
- Steve DeRose, Brown University Scholarly Technology Group (XLink co-editor)
- David Durand, University of Southhampton, Dynamic Diagrams
- Masatomo Goto, Fujitsu Laboratories
- Paul Grosso, Arbortext
- Chris Maden, Lexica
- Eve Maler, Sun Microsystems (co-chair and XLink co-editor)
- Jonathan Marsh, Microsoft
- David Orchard, Jamcracker (XLink co-editor)
- Henry S. Thompson, University of Edinburgh, W3C
- Daniel Veillard, W3C staff contact (co-chair)
编者愿感谢来自 Tim Bray 实质上的贡献，他先前担任共同编者和共同主席；以及先前担任共同编者 Ben Trafford。我们也愿感谢 Gabe Beged-Dov 的重要贡献，他写了 XArc 提议。最后，我们也愿感谢 XML 链接兴趣小组的支持和投入，以及 Henry Thompson 在本出版物出版之前的最近几数个月担任小组主席及职员连络。