|
第四部分 补充技术本部分包括以下各章: 第16章--XLink 第17章--XPointer 第18章--命名域 第19章--资源描述框架 注意:本章内容基于XLink的早期草案,与现在的规范有较大出入。但为了保证完整性,我们仍将本章完整刊出。本章的最新英文版本见http://www.ibiblio.org/xml/books/bible/updates/16.html,XLink规范最新版本见http://www.w3.org/TR/xlink/。 XML中国论坛 第16章 XLinkXLL(可扩展的链接语言,eXtensible Linking Language)分为两部分:XLink和XPointer。XLink(即XML链接语言,XML Linking Language)定义一文档如何与另一文档的链接。XPointer(即XML指针语言,XML Pointer Language)定义文档的各部分如何寻址。XLink指向URI(实际为URL),以指定特定的资源。此URL可能包含XPointer部分,更明确地标识目标资源或文档所期望的部分或节。本章探讨XLink,下一章将探讨XPointer。 本章的主要内容如下: · XLink与HTML链接的对比
16.1 XLink与HTML链接的对比Web征服已经建立起来的Gopher协议的一个主要原因是:在文档中可嵌入超文本链接。这些链接可以嵌入影像或让用户从一文档内部跳转到另一文档或同一文档的另一部分。在某种程度内,XML可转变成其他格式以便于浏览,HTML用于链接的句法与XML文档中使用的句法是一样的。使用XSL,可将各自的句法转变成HTML句法,就像第14章的几个例子中所看到的那样。 但是,HTML链接具有局限性。首先,URL通常只限于指向单一文档。如果比这种要求更为详细如链接于一文档中第17段的第三句,就需要手工在目标文件中插入命名的定位符(锚)。如果对链接的文档没有写访问权,是不会做到这一点的。 而且,HTML链接不保留文档之间的历史或关系内容。尽管浏览器可以跟踪浏览的一系列文档的路径,但这种跟踪是很不可靠的。从HTML内部,没有任何方法知道读者是从哪里来的。链接纯粹是单方向的。用来链接的文档知道它正与谁进行链接,但反过来则不行。 XLL可获得文档间的更强有力的链接。它是专为XML文档设计的,但有些部分也可以与HTML文档一起使用。XLL可以实现使用HTML的基于URL超文本链接和定位可获得的任何功能。但是,除此之外,它还支持多方位的链接,即以多个方向同时进行链接。任何元素都可以成为一个链接,而不仅仅是A元素。甚至不需要将链接保存在与链接文档相同的文件中。此外,XPointer部分(将在下一章讨论)允许对XML文档中的任意位置进行链接。这些功能使XLL不仅更适合于新的用途,而且还适合于只使用HTML要花很大气力才能达到的功能,如交叉引用、脚注、尾注、互连数据等等。 请读者注意,直到编写此书时(1999年春天),XLL仍处于重大的开发和修改阶段。尽管正在逐渐成形,但在读者阅读本书时可能会或多或少地发生变化。 此外,到目前为止,还没有任何一个多用途的应用程序能支持任意的XLink。这是因为XLink的适用性要比HTML链接广得多。XLink不仅仅用于超文本的连接,还可用于在文档中嵌入影像。可被任何一个需要在文档和文档的局部之间建立连接的常用应用程序用于任何目的。因此,甚至当XLink在浏览器中得以完整执行时,也许并非总是单击可跳转到另一页的蓝色下划线文本。可以是那样,但也可以根据需要决定蓝色的下划线文本的多寡。 16.2 简单链接在HTML中,链接是用<A>标记来定义的。但就像XML使用描述元素的标记更灵活一样,使用引用外部资源的标记也更为灵活。在XML中,几乎任何标记都可以是一个链接。包括链接的元素称作链接元素(linking element)。 链接元素是由值为simple或extended的xlink:form特性来标识的。而且,每个链接元素包含一个值为链接资源的URI的href特性。例如,下面是三个链接元素: <FOOTNOTE xlink:form=”simple” href=”footnote7.xml”>7</FOOTNOTE> <COMPOSER xlink:form=”simple” inline=”true” href=”http://www.users.interport.net/~beand/”> Beth Anderson </COMPOSFR> <IMAGE xlink:form=”simple” href=”logo.gif”/> 注意,此元素具有描述它们所包含内容的语义名称,而不是这些元素如何表现。这些元素使链接的信息包含在标记的特性中。 这三个例子是简单的XLink。简单的XLink类似于标准的HTML链接,并在更复杂(以及功能强大)的扩展链接之前很可能为应用程序的软件所支持,所以,我首先使用它们。扩展链接在下节讨论。 在上面的FOOTNOTE实例中,链接目标特性名为href。其值为相对的URL footnote7.xml。此文档的协议、主机以及路径都取自出现这种链接的文档中的协议、主机以及路径。 在上面的COMPOSER示例中,链接目标特性名为href。此href特性值为绝对的URL http: //wwwusers.interport.net/~beand/。在上面的第三个示例IMAGE中,链接目标特性名为href。此href特性值为相对的URL logo.gif。这时同样本文档的协议、主机以及路径都取自出现这种链接的文档中的协议、主机以及路径。 如果文档有一个DTD,那么这些特性必须和其他特性一样进行声明。例如,FOOTNOTE、COMPOSER和IMAGE元素的DTD声明可以按下面的方式进行: <!ELEMENT FOOTNOTE (#PCDATA)> <!ATTLIST FOOTNOTE xlink:form CDATA #FIXED “simple” href CDATA #REQUIRED > <!ELEMENT COMPOSER (#PCDATA)> <!ATTLIST COMPOSER xlink:form CDATA #FIXED “simple” href CDATA #REQUIRED > <!ELEMENT IMAGE EMPTY> <IATTLIST IMAGE xlink:form CDATA #FIXED “simple” href CDATA #REQUIRED > 使用这些声明,xlink:form特性就有一个确定值。所以,这一特性就不需要包括在元素的实例中,现在可以将这些元素按照下列方式书写得更简洁一些: <FOOTNOTE href=”footnote7.xml”>7</FOOTNOTE> <COMPOSER href=”http://www.users.interport.net/~beand/”> Beth Anderson </COMPOSER> <IMAGE href=”logo.gif”/> 使一元素成为链接元素对元素的其他特性或内容不存在限制。链接元素可以包含任意的子元素或其他特性,当然总是受制于DTD。例如,下面为IMAGE元素的更真实的声明。注意,大多数特性与链接无关。 <!ELEMENT IMAGE EMPTY> <!ATTLIST IMAGE xlink:form CDATA #FIXED “simple” href CDATA #REQUIRED ALT CDATA #REQUIRED HEIGHT CDATA #REQUIRED WIDTH CDATA #REQUIRED > 16.2.1 本地资源的描述链接元素可以包含可选的content-role和content-title元素,这两个元素用于在链接元素出现的文档内提供附加的信息,并进一步描述此链接的目的。例如: <AUTHOR href=http://www.macfaq.com/personal.html content-title="author of the page" content-role="whom to contact for questions about this page"> Elliotte Rusty Harold </AUTHOR> content-role和content-title特性描述本地资源,即链接元素的内容(本例中的Elliotte Rusty Harold)。但是,这些特性不描述远程的资源(如本例中为位于http://www.macfaq.com/personal.html处的文档)。因此,本例说明Elliotte Rusty Harold具有“author of the page”的头衔,其作用为“whom to contact for questions about this page”。本例也无需与在http://www.macfaq.com/personal.html处找到的文档有任何关系。 content-title特性通常是由读入XML的应用程序所使用,以便在用户将鼠标移到链接的元素之上时,在浏览器状态条上或通过工具提示为用户显示一些附加信息。但是,应用程序不一定要为用户显示这种信息。如果此特性选择了这么做,那么它就只能如此。 content-role特性表示文档中链接元素的目的。此特性与准备将数据传递给读入XML的应用程序中的处理指令相类似。可是,它的真正目的并不是作为XML来使用,并且应用程序可以任意忽略此特性。 像所有的其他特性一样,content-title和content-role为了用于包含它们的所有元素也应在DTD中进行声明。例如,下面的合理声明可用于上面的AUTHOR元素: <!ELEMENT AUTHOR (#PCDATA)> <IATTLIST AUTHOR xlink:form CDATA #FIXED "simple" href CDATA #REQUIRED content-title CDATA #IMPLIED content-role CDATA #IMPLIED 16.2.2 远程资源的描述链接元素可以包含可选的role和title特性,用来描述远程资源,即链接所指向的文档或其他资源。例如: <AUTHOR href=http://www.macfaq.com/personal.html title="Elliotte Rusty Harold s personal home page" role="further information about the author of this page" content-title="author of the page" content-role="whom to contact for questions about this page"> Elliotte Rusty Harold </AUTHOR> role和title特性描述远程资源,而不是本地元素。在上面的实例中,远程资源就是http://www.macfaq.com/personal.html处的文档。因此,下面的实例说明http://www.macfaq.com/personal.html处的网页标题为“Elliotte Rusty Harold s personal home page”,作用为“further information about the author of this page”。要使title与链接网页的TITLE元素内容相同是很平常的,尽管不必这样做。 读入XML的应用程序可以使用这两个特性来为用户显示附加的信息。但应用程序无需将这种信息显示给用户或用它来做任何事。 在链接文档(链接出发的文档)中,role特性说明远程资源(被链接的文档)的目的。例如,可用特性来区别脚注、尾注和引文。 与所有的其他特性一样,为了用于包含它们的所有元素,应在DTD中声明title和role特性。例如,下面的合法声明可用于上面的author元素: <!ELEMENT AUTHOR (#PCDATA)> <!ATTLIST AUTHOR xlink:form CDATA #FIXED "simple" href CDATA #REQUIRED content-title CDATA #IMPLIED content-role CDATA #IMPLIED title CDATA #IMPLIED role CDATA #IMPLIED > 16.2.3 链接行为链接元素可以包含三个可选特性,这些特性可以建议应用程序如何将远程资源与当前页关联。下面即为这三种特性: 1.show 2.actuate 3.behavior show特性提示当激活链接时,应如何显示内容,例如,通过打开一个新窗口来保存内容。actuate特性提示此链接是否可以自动切断或是否要求有明确的用户请求。behavior特性可为应用程序提供有关如何准确地切断链接的详细信息,如在切断链接之前的一段时间迟延。但是,这些特性都是与应用程序相关的,并且应用程序可任意忽略这些提示。 16.2.3.1 show特性 show特性有三个合法值:replace、new和embed。 当激活链接(通常是由单击此链接而发生的,至少在GUI浏览器中是如此)时使用replace值,则链接的目标代替同一个窗口中的当前文档。这是HTML链接的缺省行为。例如: <COMPOSER href="http://www.users.interport.net/~beand/" show="replace"> Beth Anderson </COMPOSER> 使用new值时,激活链接就打开新的窗口,以显示目标资源。这种行为与target特性设置为_blank时的HTML链接类似。例如: <WEBSITE href="http://www.quackwatch.com/" show="new"> Check this out, but don t leave our site completely! </WEBSITE> 读者不希望在单击链接后打开新的窗口,倒希望在单击链接后,把新页加载到当前窗口中,除非明确地要求在新窗口中打开这种链接。 有些公司相当自傲,以至他们认为任何一个用户从不会离开他们自己的站点。于是,他们就“帮助”读者打开新的窗口。在大多数时候,这只能使读者感到困惑和厌恶。如果没有一个很好的理由,就不要改变用户所期望的那种行为。让读者在站点上花费额外的两秒钟,或者多浏览一页,多看一页的广告,这种浮浅的欲望是毫无道理的。 使用embed值,激活链接将会在现有的文档中插入目标资源。其准确的含义是与应用程序相关的。但是,可以想象,此值用于Web页的客户端“嵌入”功能。例如,下面的这个元素(并没有直接包括家庭成员的各个元素)将家庭成员的各个元素从各自的文件ThomasCorwinAnderson.xml、LeAnahDeMintEnglish.xml、JohnJayAnderson.xml和SamuelEnglishAnderson.xml中复制出来。 <FAMILY ID="f732"> <HUSBAND href="ThomasCorwinAnderson.xml" show="embed"/> <WIFE href="LeAnahDeMintEnglish.xml" show="embed"/> <CHILD href="JohnJayAnderson.xml" show="embed"/> <CHILD href="SamuelEnglishAnderson.xml" show="embed"/> </FAMILY> 切断链接并将其内容嵌入到FAMILY元素中之后,结果如下所示: <FAMILY ID="f732"> <PERSON ID="plO35" SEX="M"> <NAME> <GIVEN>Thomas Corwin</GIVEN> <SURNAME>Anderson</SURNAME> </NAME> <BIRTH> <DATE>24 Aug 1845</DATE> </BIRTH> <DEATH> <PLACE>Mt. Sterling, KY</PLACE> <DATE>18 Sep 1889</DATE> </DEATH> </PERSON> <PERSON ID="pl098" SEX="F"> <NAME> <GIVEN>LeAnah (Lee Anna, Annie) DeMint</GIVEN> <SURNAME>English</SURNAME> </NAME> <BIRTH> <PLACE>Louisville, KY</PLACE> <DATE>1 Mar 1843</DATE> </BIRTH> <DEATH> <PLACE>acute Bright s disease, 504 E. Broadway</PLACE> <DATE>31 Oct 1898</DATE> </DEATH> </PERSON> <PERSON ID="pll02" SEX="M"> <NAME> <GIVEN>John Jay (Robin Adair )</GIVEN> <SURNAME>Anderson</SURNAME> </NAME> <BIRTH> <PLACE>Sideview</PLACE> <DATE>13 May 1873</DATE> </BIRTH> <DEATH> <DATE>18 Sep 1889 </DATE> </DEATH> </PERSON> <PERSON ID="p37" SEX="M"> <NAME> <GIVEN>Samuel English</GIVEN> <SURNAME>Anderson</SURNAME> </NAME> <BIRTH> <PLACE>Sideview</PLACE> <DATE>25 Aug 1871</DATE> </BIRTH> <DEATH> <PLACE>Mt. Sterling, KY</PLACE> <DATE>10 Nov 1919</DATE> </DEATH> </PERSON> </FAMILY> 尽管每个PERSON元素都存在于独立的文件中,但处理全部的FAMILY元素就像是在一个文件中一样。 像合法文档中的所有特性一样,对于DTD的链接元素,show特性必须在<!ATTLIST>声明语句加以声明。例如: <!ELEMENT WEBSITE (#PCDATA)> <!ATTLIST WEBSITE xlink:form CDATA #FIXED "simple" href CDATA #REQUIRED show (new | replace | embed) "new" > 16.2.3.2 actuate特性 链接元素的actuate特性有两个可能的值:user和auto。user值为缺省值,它指定仅当用户请求时,才切断链接。另一方面,如果链接元素的actuate特性设置成auto,则在同一个链接元素的其他目标资源被切断时,都要切断此链接。 正如合法文档中的所有特性一样,对于出现链接的链接元素,actuate特性必须在DTD的<!ATTLIST>声明语句中声明。例如: <!ELEMENT WEBSITE (#PCDATA)> <IATTLIST WEBSITE xlink:form CDATA #FIXED "simple" href CDATA #REQUIRED show (new | replace | embed) "new" actuate (user | auto) "user" > 16.2.3.3 behavior特性 behavior特性用来将任意格式的任意数据传递给读入此数据的应用程序中。应用程序使用这些数据来对如何进行链接作出附加说明。例如,如果要指定在切断链接时,播放声音文件fanfare.au,可按下面进行编写: <COMPOSER xlink:form="simple" href="http://www.users.interport.net/-beand/" behavior="sound: fanfare.au"> Beth Anderson </COMPOSER>
但是,这样就要求读入XML文件的应用程序理解带有值为sound:fanfare.au的behavior特性即意味着当切断链接时,应播放fanfare.au声音文件。大多数(或许所有的)应用都不能理解这种含义。但是,它们可以将behavior特性当作易于使用的保存它们确实能够理解的非标准信息的地点。 正如合法文档中的所有特性一样,对于出现链接的链接元素,其behavior特性必须在DTD中声明才行。例如:下面的COMPOSER元素可按下面方式声明: <!ELEMENT COMPOSER (#PCDATA)> <!ATTLIST COMPOSER xlink:form CDATA #FIXED "simple" href CDATA #REQUIRED behavior CDATA #IMPLIED > 16.3 扩展链接简单链接的效果或多或少地与HTML中已经熟悉了的标准链接类似。每个简单链接都包含一个本地资源和对一个远程资源的引用。本地资源为链接元素的内容,而远程资源则为链接的目标。 但是,扩展链接(Extended link)实质上超越了HTML链接所能达到的程度,以便在许多文档和外联链接之间包括多方向的链接。扩展链接由xlink:form特性来指定,其值为extended,如: <WEBSITE xlink:form="extended"> 扩展链接的第一个作用就是指向多个目标。为此,扩展链接将目标保存在链接元素的子locator元素中,而不像简单链接那样保存在链接元素的唯一的href特性中。例如: <WEBSITE xlink:form="extended">Cafe au Lait <locator href="http://metalab.unc.edu/javafaq/"> North Carolina </locator> <locator href="http://sunsite.univie.ac.at/jcca/mirrors/javafaq/"> Austria </locator> <locator href="http://sunsite.icm.edu.pl/java-corner/faq/"> Poland </locator> <locator href="http://sunsite.uakom.sk/javafaq/"> Slovakia </locator> <locator href="http://sunsite.cnlab-switch.ch/javafaq/"> Switzerland </locator> </WEBSITE> 本例中的链接元素WEBSITE本身和各locator子元素都可以有特性。链接元素只有适用于整个链接以及本地资源的特性,如content-title和content-role。locator元素具有应用于特定的远程资源(locator元素链接于这些资源)的特性,如role和title。例如: <WEBSITE xlink:form="extended" content-title ="Cafe au Lait" content-role="Java news"> <locator href="http://metalab.unc.edu/javafaq/" title="Cafe au Lait" role=".us"/> <locator href="http://sunsite.univie.ac.at/jcca/mirrors/javafaq/" title="Cafe au Lait" role=".at"/> <locator href="http://sunsite.icm.edu.pl/java corner/faq/" title="Cafe au Lait" role=".pl"/> <locator href="http://sunsite.uakom.sk/javafaq/" title="Cafe au Lait" role=".sk"/> <locator href="http://sunsite.cnlab-switch.ch/javafaq/" title="Cafe au Lait" role=".ch"/> </WEBSITE> actuate、behavior和show(如果存在)属于各个locator元素。 在有些情况下,如上面的实例所示,各定位符(locator)指向同一页面和镜像副本,对于各个locator元素来说,远程资源特性可以相同,都指向链接元素。在此情况下,可以在链接元素中使用远程资源特性。这些特性应用于各个locator子元素(对于同一个特性各子元素声明为相同的值)。例如: <WEBSITE xlink:form="extended" content-title="Cafe au Lait" content-role="Java news" title="Cafe au Lait"> <locator href="http://metalab.unc.edu/javafaq/" role=".us"/> <locator href="http://sunsite.univie.ac.at/icca/mirrors/javafaq/" role=".at"/> <locator href="http://sunsite.icm.edu.pl/java-corner/faq/" role=".pl"/> <locator href="http://sunsite.uakom.sk/javafaq/" role=".sk"/> <locator href="http://sunsite.cnlab switch.ch/javafaq/" role=".ch"/> </WEBSITE>
就像通常的那样,在合法的文档中,链接元素及其所有可能的特性都必须在DTD中声明。例如,下面声明上面实例中使用的WEBSITE和locator元素及其特性: <!ELEMENT WEBSITE (locator*) > <!ATTLIST WEBSITE xlink:form CDATA #FIXED "extended" content-title CDATA #IMPLIED content-role CDATA #IMPLIED title CDATA #IMPLIED > <!ELEMENT locator EMPTY> <!ATTLIST locator xlink:form CDATA #FIXED "locator" href CDATA #REQUIRED role CDATA #IMPLIED > 16.4 外联链接迄今为止所考虑的链接(简单和扩展)都是内联链接。内联链接(如在HTML中熟悉的A元素)使用内联元素的内容作为包含链接的文档部分。通过这种方式展示给读者。 XLink也可以是外联方式。外联链接可能不存在于它所连接的任何文档中,而是将链接保存在各个独立的链接文档中。例如,使用这种方法来维护幻灯片放映是很有用的,因为在幻灯片放映过程中,各幻灯片都需要前后链接。改变链接文档中的幻灯片顺序,即可以改变每页上的前后链接的目标,而无需编辑幻灯片本身。 要将链接标记为外联,可将inline特性设置成false值。例如,下面的简单的外联链接使用空元素来描述Web站点。空元素没有任何内容;在链接的情况下,它没有本地资源。所以,它没有描述本地资源的content-role和content-title特性。但像下面的这个例子那样,可以有描述远程资源的role和title特性。 <WEBSITE xlink:form="simple" inline="false" href="http://metalab.unc.edu/xml/" title = "Cafe con Leche" role="XML News"/> 由于到目前为止所看到的所有链接都是内联链接,所以链接隐式地具有值为true(缺省值)的inline属性。 简单的外联链接(如上面的例子)都是相当少见的。极其常用并且非常有用的是外联扩展链接,如下面所示: <WEBSITE xlink:form="extended" inline="false"> <locator href="http://metalab.unc.edu/javafaq/" role=".us"/> <locator href="http://sunsite.univie.ac.at/jcca/mirrors/javafaq/" role=".at"/> <locator href "http://sunsite.icm.edu.pl/java-corner/faq/" role=".pl"/> <locator href="http://sunsite.uakom.sk/javafaq/" role=".sk"/> <locator href="http://sunsite.cnlab-switch.ch/javafaq/" role=".ch"/> </WEBSITE> 有些链接(如上面的链接)可能保存在已知位置的Web服务器上的独立文件中,在此位置浏览器可以找到并且询问此链接,以便确定对浏览器正在寻找最近的页面镜像。但是,外联性就是该元素不出现在激活链接的文档中。 这样就将样式单的提取扩大到链接域。样式单完全与其描述的文档分离,并且提供的规则可以用来修改文档向读者显示的方式。包含外联链接的链接文档与它所连接的文档分离,但仍给读者提供必要的链接。这种方法有几个优点,其中包括可以使更多面向展示的标记保持与文档分离,以及允许只读文档的链接。 样式单链接的范围比外联链接要广得多。目前还没有如何将“链接单(link sheet)”加到XML文档中的一般性的建议,更不用说如何确定文档中的哪个元素与哪个链接相关联。 显而易见,可以将<?xml-linksheet?>处理指令加到文档的前言中,以指定在何处找到链接。链接单本身可以使用类似于XSL的内容来选择模式,以便将链接映射到各XML元素中。甚至选择符也会成为locator元素的role特性的值。 16.5 扩展链接组扩展链接组(extended link group)元素包含连接一组特定文档的链接。依靠扩展链接文档元素,组中的每个文档都作为目标来定位。应用程序负责推定如何激活组成员中的连接、并怎么理解这种连接。 我不得不提醒读者,在撰写这本书时,应用程序支持链接组最多只是一种假定。尽管我可以显示如何书写这样的链接,但真正执行并支持可能还需要一段时间。有些细节无法确定,很可能以销售商指定的方式执行,至少开始就是如此。还有,这些链接能够获得比HTML更为复杂的链接。 16.5.1 一个实例例如,我已经将我讲授的Java课程的注解放在我的Web站点上。图16-1显示前言页。这个特别的课程由13个课时组成,每个课时含有30~60页的注解。然后为各个课时提供一张目录。这几百页组成整个站点,其中的每一页都与前面文档、下个文档以及每周目录(顶端链接)相链接,如图16-2所示。把这些页放在一起,这样总计多达几千页,这些页可以在文档内相互连接。 图16-1 用于类Web站点的前言页显示13个星期的讲稿注解 可能相互连接数随着文档数量呈指数增长。每当一个文档移动、改名或分成更小的块时,就需要在页面上、在这组文档的前和其后的页面上以及每周目录上调整链接。坦率地说,这项工作比原先的更加艰苦,所以这妨碍了对课程注解的必要的修改和更新。 图16-2 显示Previous、Next和Top链接的一页讲稿注解 如果HTML支持的话,要做的更有意义的事就是将连接保存在独立的文档中。然后编辑此文档,就可以重新组织页。HTML链接不支持这种方式,但XLink却支持。不是以内联的方式将链接保存在HTML文件中,而是将它们通过外联的方式保存在组元素中。例如: <COURSE xlink:form="group"> <CLASS xlink:form="document" href="weekl/index.xml"/> <CLASS xlink:form="document" href="week2/index.xml"/> <CLASS xlink:form="document" href="week3/index.xml"/> <CLASS xlink:form="document" href="week4/index.xml"/> <CLASS xlink:form="document" href="week5/index.xml"/> <CLASS xlink:form="document" href="week6/index.xml"/> <CLASS xlink:form="document" href="week7/index.xml"/> <CLASS xlink:form="document" href="week8/index.xml"/> <CLASS xlink:form="document" href="week9/index.xml"/> <CLASS xlink:form="document" href="week10/index.xml"/> <CLASS xlink:form="document" href="weekll/index.xml"/> <CLASS xlink:form="document" href="weekl2/index.xml"/> <CLASS xlink:form="document" href="weekl3/index.xml"/> </COURSE> 这样就将COURSE元素定义成扩展链接组,此组由13个扩展链接文档元素(即CLASS元素)组成。 16.5.2 steps特性应用程序使用链接组可以做的事情之一是,预加载链接组中的所有文档。这些文档可以包含它们各自的链接组。例如,上面的每个CLASS元素都引用一个特定星期的站点目录,如图16-3所示。然后这些文档就可以加载。例如,文件week6/index.xml就包含这种链接组: <CLASS xlink:form=”group”> <SLIDE xlink:form=”document” href=”O1.xml”/> <SLIDE xlink:form=”document” href=”02.html”/> <SLIDE xlink:form=”document” href=”06.html”/> <SLIDE xlink:form=”document” href=”12.html”/> <SLIDE xlink:form=”document” href=”13.html”/> <SLIDE xlink:form=”document” href=”16.html”/> <SLIDE xlink:form=”document” href=”17.html”/> <SLIDE xlink:form=”document” href=”19.html”/> <SLIDE xlink:form=”document” href=”21.html”/> <SLIDE xlink:form=”document” href=”22.html”/> <SLIDE xlink:form=”document” href=”24.html”/> </CLASS > 图16-3 显示周讲稿注解的目录页面 现在假定有一个文档反过来引用原文档。这有可能触发无限的回归,即重复加载同一个文档,直到应用程序将内存耗尽为止。为了防止这种情况的发生,组元素可以包含steps特性,用它来指定递归跟随链接组的层数。例如,要指定预加载不能达到当前文档三层以上,可以这样来编写: <group xlink:form=”group” steps=”3”> 坦率地说,我不敢确定steps特性有多重要。要使应用程序注意何时它已经到达某个文档,但根本不再次处理此文档并非困难。我认为,更好的方法是,由XML处理器而不是网页作者来防止递归。 steps特性可以用来限制预发生加载的数量。例如,在课时注解实例中,尽管有可能他或她想打印或复制所有的课程注解,不可能任何人一次要阅读整个内容。在任何情况下,将steps特性设置为1,就可以将横穿的深度限制为指定的页面而不是课程中的几百页。 就像常常要做的那样,这些元素及其特性必须在它们的任何合法文档的DTD中声明。实际上,xlink:form是固定的,所以不需要包括在元素的实例中。例如: <!ELEMENT CLASS (document*)> <!ATTLIST CLASS xlink:form CDATA #FIXED “group” steps CDATA #IMPLIED > <!ELEMENT SLIDE EMPTY> <!ATTLIST SLIDE xlink:form CDATA #FIXED “document” href CDATA #REQUIRED > 16.6 重命名XLink特性XLink有十个特性,这在前节中已经讨论过。现列于下面: xlink:form href steps title role content-title content-role show actuate behavior 可以想像,这些特性之一或多个已用作特定XML应用程序中的特性名。title特性似乎特别要加以考虑。只有一个特性不能用于其他用途,这就是xlink:form。 XLink规范预料到这个问题,所以可以利用xml:attributes特性将XLink特性重新命名为更便于使用的名称。在DTD的<!ATTLIST>中将此特性声明为一个固定的属性,类型为CDATA,而值为以空格分开的标准名和新名对的列表。 这种问题可以使用命名域(在第18章中讨论)来解决。如果在未来的XLL草案中将此结构整个地删除,并用简单的命名域作前缀(如xlink:)时,我并不感到惊讶。 例如,本章展示的链接元素有点滑稽,因为标准名都是小写字母,而本书的约定都是用大写字母。按照下面的方法,使用声明语句,就很容易将XLink特性变成大写字母: <!ELEMENT WEBSITE (#PCDATA)> <!ATTLIST WEBSITE xlink:form CDATA #FIXED "simple" xml:attributes CDATA #FIXED "href HREF show SHOW actuate ACTUATE" HREF CDATA #REQUIRED SHOW CDATA (new | replace | embed) "new" ACTUATE CDATA (user | auto) user > 现在就可以更谐调地重新编写WEBSITE例子: <WEBSITF HREF="http://www.microsoft.com/" SHOW="new"> Check this out, but don t leave our site completely! </WEBSITE> 上面的ATTLIST声明只改变WEBSITE元素的特性。如果要在其他多个例子中用同样的方式改变这些特性,最容易的方法就是使用参数实体: <!ENTITY LINK_ATTS xlink:form CDATA #FIXED "simple" xml:attributes CDATA #FIXED "href HREF show SHOW actuate ACTUATE" HREF CDATA #REQUIRED SHOW CDATA (new | replace | embed) "new" ACTUATE CDATA (user | auto) "user" > <!ELEMENT WEBSITE (#PCDATA)> <!ATTLIST WEBSITE %LINK_ATTS:> <!ELEMENT COMPOSER (#PCDATA)> <!ATTLIST COMPOSER %LINK_ATTS;> <!ELEMENT FOOTNOTE (#PCDATA)> <!ATTLIST FOOTNOTE %LINK_ATTS;> 16.7 本章小结在本章中学习了XLink。特别是学习了如下内容: XLink可以做HTML链接能够做的任何事情,并还会更多,但不为当前的应用程序所支持。 简单链接特别类似于HTML链接,但不受单个<A>标记的限制。 链接元素使用xlink:form和href来指定。 链接元素使用content-title和content-role来描述本地资源。 链接元素使用title和role来描述链接的远程资源。 链接元素使用show特性来告诉应用程序当激活链接时应如何显示内容,如打开一个新的窗口。 链接元素使用behavior特性来将详细的、由应用程序决定的有关如果准确地切断此链接的信息提供给应用程序。 链接元素使用actuate特性来告诉应用程序没有明确的用户请求是否应切断链接。 扩展链接可以在链接元素中包括多个URI。目前,由应用程序来决定如何在不同的可能性中挑选。 扩展链接组元素包含连接特定一组文档的链接列表。 可在DTD中使用xml:attributes特性来对标准的XLink特性(如href和title)重新命名。 在下一章中,将会看到如何使用XPointer来链接远程文档,而且如何与远程文档的特指元素进行链接。 特别提醒:我在制作这个文档的时候,因为文档的刊登站点提醒第17章(Xpoint)已经和现有的标准有很大的出入,所以我没有再将第17章提取下来,有要的朋友请自己到http://www.xml.net.cn/ 去察看 Chicken |