XML標記的語義

艾蘭?瑞尼爾 戴維德?杜賓 斯芬伯格?麥奎因 克勞斯?惠特福德(著)王曉光 王俊芳(譯)

[摘 要] 盡管XML文檔類型定義提供了一種機器可讀形式的、能夠說明XML語言語法的機制，但目前并沒有類似的機制來指定XML詞匯表的具體語義。這意味著沒辦法說明XML標記的意義，由XML形式呈現的事實和關系無法清晰、全面和規范地定義。這在實踐和理論上都引起了嚴重的后果。從積極的方面看，XML結構能被賦予任意語義，并可用于最初的設計者無法預見的領域。從不太積極的方面來看，內容開發者和軟件工程師必須依靠乏味的文檔，或者更糟的情況是，只能依靠猜測標記語言設計者的意圖來開展工作。這一過程既費時費力，又易出錯，還無法核實驗證。即便是設計者當初的建檔工作做得相當完美，不如意的情況還是會發生。另外，對標記語義本質研究的匱乏也意味著屬于工程應用領域的數字文檔處理根本沒有什么理論。盡管目前正在進行的一些工程（XML模式、RDF、語義網）已經取得了一些成績，但是這些工程都沒有直接全面地解決XML標記語義的核心問題。本文回顧了標記意義這個概念的發展歷史，闡明了解釋XML正式語義的動機，并介紹了一個研究語義的科研項目——BECHAMEL 標記語義計劃。

[關鍵詞] SGML XML 標記 語義 知識表示

[中圖分類號] G238 [文獻標識碼] A [文章編號] 1009-5853 （2016） 04-0018-09

[Abstract] Although XML Document Type Definitions provide a mechanism for specifying， in machine-readable form， the syntax of an XML markup language， there is no comparable mechanism for specifying the semantics of an XML vocabulary. That is， there is no way to characterize the meaning of XML markup so that the facts and relationships represented by the occurrence of XML constructs can be explicitly， comprehensively， and mechanically identified. This has serious practical and theoretical consequences. On the positive side， XML constructs can be assigned arbitrary semantics and used in application areas not foreseen by the original designers. On the less positive side， both content developers and application engineers must rely upon prose documentation， or， worse， conjectures about the intention of the markup language designer — a process that is time?consuming， error-prone， incomplete， and unverifiable， even when the language designer properly documents the language. In addition， the lack of a substantial body of research in markup semantics means that digital document processing is undertheorized as an engineering application area. Although there are some related projects underway （XML Schema， RDF， the Semantic Web） which provide relevant results， none of these projects directly and comprehensively address the core problems of XML markup semantics. This paper （i） summarizes the history of the concept of markup meaning， （ii） characterizes the specific problems that motivate the need for a formal semantics for XML and （iii） describes an ongoing research project ： the BECHAMEL Markup Semantics Project —that is attempting to develop such a semantics.

[Key words] SGML XML Markup Semantics Knowledge representation

1 引 言

近年來，隨著數字出版的發展、萬維網應用的迸發以及電子商務領域的快速發展，我們日常的社會、商業、文化、生活等方方面面都開始應用閃標準化通用標記語言（Standard Generalized Markup Language，SGML）和可擴展標記語言（Extensible Markup Language，XML）的文本標記系統。SGML/XML是一種定義描述性標記語言的機器可讀技術。除去一些需要特別處理的部分，這種語言能清晰地定義文檔結構及其潛在意義。SGML/XML發展速度很快，廣泛使用這種技術能夠支持高性能的文檔互操作處理和出版。

這種美好的愿望已經部分實現了，SGML/XML的優越性超出了人們的預期，但是SGML/XML文檔系統在功能性、互操作性、多樣性和可獲取性上仍有待提高。若不抓住這個機會，后果會非常嚴重：實業界已經花費了高昂的財務成本，也失去了很多機會；在關鍵的安全應用上還有可能導致一些災難；對于殘疾人來說，這會阻礙他們平等地獲取當代社會文化和商業福利。此外，久已存在的一些問題也在不斷提醒我們，當下最好的數字文檔模型仍存在缺陷，至少是不夠完善的。

這些問題的根源在于，盡管SGML/XML能為文檔提供有意義的結構，但是SGML/XML不能以系統的機器可處理的方式來表示文檔組件和主題之間的基本語義關系。SGML/XML支持對機器可讀的“語法”進行說明，但是它沒有提供解釋某種語法的語義內涵的機制，所以一個SGML/XML詞匯的潛在意義到底是什么，還沒有辦法進行形式化表達。利用當下的SGML/XML甚至無法表達非常簡單的有關文檔標注系統的基本語義事實，這些事實通常是標記語言設計師預先設計的，但具體實現仍舊依賴于標記語言用戶和軟件。

這種表達功能的缺失使得SGML/XML用戶必須猜測標記語言設計師想到的但沒有形式化表達出來的那些語義關系。內容開發者必須猜測設計者的意圖，在內容編碼時依靠這些推斷開展工作，無法將自己的推斷和意圖清晰地表達給其他人或者傳遞給處理編碼內容的應用程序。軟件設計師也需要猜測標記語言設計師的可能意圖，并將這種猜想設計到軟件工具和應用系統中。有時候二階的猜想是必須的：軟件設計師要猜測內容開發者對標記語言設計師意圖的推斷。

很顯然，這些猜測是不完整的、易錯的和未經證實的。而且，制作和實現過程都費時費力，功能性和互操作性也很差。為一般的自然語言文檔配備一個SGML/XML的說明書并不能完美地解決這個問題。當然，普通的自然語言文檔能給內容提供者和軟件工程師提供一些提示，但是目前SGML/XML文檔還沒有通用的規則。不管怎么樣，普通的自然語言文檔不是機器可讀的形式，這就是我們要說的 SGML/XML標記系統的問題。

與SGML和XML相關的機器可處理的語義描述方面的設想還未形成，這是目前工程領域的問題和未來發展障礙的根源 [25] [23] [43] [25] [36]，相關的語義學研究也很少，但是很多學者已經開始關注此問題。W3C Schema方面的工作與此相關，但也只是覆蓋了這個問題中的很小一部分（比如數據類型）。W3C的“語義網”計劃也與此相關，但它是為了發展通用的基于XML的知識表示技術。我們的研究重點是文檔標記的語義，它隱藏在實際的文檔處理系統中。人們可能會說語義網的本質就是設計語義標記，然而在本文中，我們認為解決以上問題還必須要深入考慮標記的本質意義。

接下來，本文首先從歷史背景方面說明標記的意義問題（標記在文本處理方法的發展中扮演了有趣的角色）；其次，詳細描述是何種因素產生了形式語義標記需求，何種因素決定了語義需求；最后簡要介紹一項多個機構正在參與實施的研究計劃——BECHAMEL標記語義計劃，該計劃正努力解決標記的語義問題。

2 歷史背景

文檔“標記”大概可以算作傳播系統的一部分，包括早期的書寫、抄寫出版和印刷，但是隨著數字文本處理和排版的發展，標記的使用變得自覺又常見，同時也成了系統開發中一個重要的創新領域[4] [40]。20世紀60年代到80年代是文檔標記系統全面系統化發展的時期，重點工作是提升數字排版和文本處理的有效性和功能性[12] [22] [19] [10] [26] [17] [18]。20世紀80年代初期，人們依舊致力于研究標記的理論框架，并利用該框架支持高性能系統的開發。這方面的一些成果已經發表[11] [27] [4] [40]，但大部分成果還只是記錄在工作文檔和各種標準形式的產品上。

在這個階段出現的一種觀點是，文檔作為一種智力成果，更適合被抽象為一系列對象（如章節、段落、公式等）的有序層次化結構模型，而不是一維文本字符流模型。字符流常夾雜著大量定義格式的編碼、描述設計布局的結構（如頁碼、分欄、印刷行）、像素值矩陣，以及其他一些在不同的文檔處理及存儲系統中潛在的表達形式[5]。有序層級結構模型概括了兩種具有本質差別的標注，分別是識別編輯文本對象（標題、章節等）的標注和說明版面要求的標注。前者的應用已經取得一些成果[11] [27] [4]。諸如標題、章節、段落、方程式、引文之類的相關文檔元素能被分隔標記清晰地標示出來，之后通過映射給元素類型的規則來對元素進行間接處理。這種內容和形式的分離，能夠以常見的組合經濟的方式實現基礎層面的間接性和抽象化。在文檔處理的所有方面，這種分離形式有巨大而多樣的實用價值[4]，更重要的是它似乎說明了“文檔到底是什么”這個問題[5]。用于實現如此功能的描述性標記不只是標出了元素的范圍，也攜帶了文檔模型想要揭示的意義（如這段文本是一個章節）。

20世紀80年代初期，美國國家標準化局（ANSI/ISO）發布了很有影響力的SGML文檔標記元語法，并梳理了標記和文檔結構方面之前所做的理論和分析工作。SGML為定義描述性標記語言提供了一種機器可讀的形式。作為一種元語法，SGML沒有定義標記語言，而是詳述了開發標記語言中的機器可讀的技術。這個定義的核心是一種類似于巴科斯-諾爾范式（Backus-Naur Form，BNF）的形式化表達機制。這一機制攜帶有用于定義類型化屬性及其取值的規則，以及其他一些用于進一步抽象化和間接化的設計（參見注釋[30]中對文檔類型定義（Document Type Definitions，DTDs）和巴科斯-諾爾范式相似程度方面的總結）。從結構上來說，SGML文檔是一種具備有序分支和帶標記節點的樹，它是其相應的DTD的形式化產物。

經過多年的分析和實踐，SGML背后的基本理念已經眾所周知。利用元語法層面的行業級標準和詞表層面的本地化創新帶來的優點，SGML的特有機制（類巴科斯-諾爾范式的元語法，類型化屬性/屬性值對，實體引用等）在應用程序和工具方面得到了高效實現。SGML標記語言本身在發展中似乎也同時支持和優化用于文檔系統設計、實施和利用的理想的工作流程。20世紀80年代中期到90年代初期，大量基于SGML的標注系統發展起來[1] [42] [39]。

盡管SGML的發展得到很多關注，其想法也不錯，并在多個領域成功實施，但在最初的十年里，幾乎沒人使用它。導致這個結果的因素有很多，但最重要的還是SGML自身過于復雜，特別是SGML中包含了許多復雜的可選屬性，對應的軟件可能根本沒必要對其實現，導致SGML軟件開發速度非常緩慢。更糟糕的是，如果文檔未經DTD驗證，進一步的分析就不可能實現。縮寫控制意味著如果不考慮文檔語法，元素邊界都無法確定下來。另外，SGML還包含了一些其他屬性，它們會導致已有的語法分析工具不適用于形式語法，無法進行高效的語法分析。

在網絡出版和交流方面，SGML系統可應用于HTML（超文本標記語言）方面。最初的HTML版本定義很松散，缺乏正式的語法說明。后來人們對HTML的SGML DTD有了興趣，事實證明為已經成為“正確”實踐的東西設計DTD是很困難的。更重要的是，由于在最初的HTML說明書中，供應商隨意地把程序性標記（如）添加到關鍵性的描述性標記中（如

當然，這夸大了實際情況。從某種意義上說，在標記語言開發人員提供的純自然語言文檔中，每個標記的意義基本可以表達清楚。但是，即使是工業和學術領域中標記格式最好的DTD文檔，也沒有從根本上解決問題。

設計一款反映標記語言中語義關系的軟件時，語言設計人員必須能夠將文檔中各部分之間的關系表示清楚；之后軟件工程師必須能夠（搜索、查找、打開）使用這個標記語言文檔，并設計應用程序來表現其優點。這兩個步驟都無法用機器進行驗證，可信度無法保證。如果要人工參與的話，就會有礙高性能網絡文檔處理和發布系統的發展。所以我們需要一個機制保證標記語言設計人員能夠詳細地、形式化地指定語義關系，還能被應用程序讀取加工，并完成自我配置，無需一個個地人工參與。

下面我們來看一些具體的語義關系。這些關系或多或少地存在潛在的實用價值，但目前它們無法方便系統地得以利用，因為尚無標準的機器可處理的表現形式。事實上，許多關系至關重要，軟件設計師常以特定的方式推斷它們在文檔中的存在，并構建特定的系統對其加以利用。

類關系。SGML / XML中不包含用以表達元素、特征或特征值中類的層級結構或類成員關系的通用結構。類是目前軟件工程主流結構中最基本和最實用的模塊。我們不能說，段落是一種結構上的元素（isa關系），或者所有結構元素都是可編輯的元素（ako關系）。兩種基本的SGML/XML設計有時可以按照屬性/值實現基礎分類（具體可以使用“type”和“class”這兩種屬性）。這種分類技術尚不夠成熟，SGML和XML沒能提供更好的機制來控制和限制其使用。在實際應用中，許多文檔類型設計師都采用類的層級結構來進行設計。XML Schema提供了類關系的清晰聲明，但它本身并不能在語義上說明這些復雜類型與其他復雜類型到底有哪些區別。

繼承關系。在許多標記語言（例如TEI 和HTML4.0）中，某些屬性會被包含元素所繼承，某些情況下被包含的文本內容也會繼承這些屬性。例如，如果一個元素的屬性/值符號為“lang="de"”，這表明這一段文本是德語，那意味著它的所有子元素屬性都是德語。但是DTD沒有提供正式說明用以指定哪些特征可以被繼承。而且，這樣的繼承關系并不是固定不變的，有時也會因為包含元素的二次定義而改變。繼承的方式也有很多種，有些涉及元素的屬性，有些涉及屬性的屬性，另一些則涉及文本和元素的內容。例如，如果標記表示一個句子是德語，這意味著句子中的所有單詞（除非特殊情況）都是德語。同樣地，所有單詞短語中標記了刪除屬性的就刪掉，標記了重點屬性的就強調，將一部分內容標記為一個段落，就意味著這部分內容中的所有單詞（或元素）都屬于這個段落。無法指定DTD繼承哪些屬性，也不能指定其繼承邏輯（包括規則錯誤）。軟件設計師經常對特定標記語言中的這些關系進行推理（判斷正誤），然后在其開發的工具和應用程序中加以實現[36] 。

語境關系和引用關系。在許多標記語言中，即使某元素有一個固定的意義用于標記相同元素類型，這個元素也可能會因為上下文關系的不同而表示不同的含義。例如，某些文本的標記為“”，其具體所指還要依賴文本的結構位置。“

（3）開發并測試形式化的、機器可讀的表示框架，在這種框架需要能夠表示標記語言的語義。

（4）探索語義表示技術的應用形式，如支持轉碼、信息檢索、可獲得性增強等。目前我們關心的重點是支持文檔數據庫實例的語義推理，因為我們相信這是應用知識表示技術最好的著力點。

（5）與人文計算研究領域的數字圖書館內容編碼計劃合作，聯合軟件工具開發人員，進行語義表示方案的大規模測試。

早期的Prolog 實驗臺[36]已經全面發展成為一個知識表示原型平臺，用于表示結構性文檔中的事實和推理規則[6] [38]。該系統允許分析人員指定某些事實（如通用標識符和屬性值），并將其與語義實體和屬性有關的推論性事實分開。

該系統還提供了一個抽象層，使得標記的意義能夠以機器可讀的和可執行的形式明確表達。在此基礎上可以根據文檔組成部分進行推論，包括那些模糊的結構，如層次重疊的組成部分。我們已經開發出一個謂詞集合，能夠模仿W3C的文檔對象模型中用于節點層級結構導航的方法，并且可以在文檔類型定義中檢索各種屬性取值和有關信息。這樣就能明確區分解析器分析的語法信息，分析人員表達的文檔語義。

初步的研究結果顯示語義推理識別的復雜性[36][29]以及語境不確定理解的復雜性[28]。這個雛形推理系統證明有關標記的自動推理是可行的，并且Prolog的規則可以處理非單調性和情景模糊性等復雜情況[37]。進一步的研究可以參考引文[38][35]。

5 標記的語義建模

文檔標記的語義是能夠被標記語言用戶理解的抽象結構、屬性和關系，標記及其語法隱含著這種語義線索。標記的語義可以借助知識表示技術通過明確結構、關系和屬性來構建相應的計算化模型。

參考如下XML標記文檔的片段：

The Translation Problem

Translation between different

SGML/XML applications， or

reconciliation of incompatible

document classes is a well-known

challenge Fausey and Shafer

（1997）. A variety of

techniques are used...

熟悉結構化標記的讀者自然知道文檔元素中的標簽P代表段落，該段落有一個標題，標題元素之后的段落內容形成了文本主體，它從標題元素之后開始，并在段落結束標簽之前結束。標簽的意義和用法并不一目了然，所以作者或讀者可以參考標記集合的說明文檔。

明顯的標記是為方便人類讀者而設計的。這些標記并不能借助文檔語法分析器，從數據結構中抽取出來。正如圖1所示，解析樹（樣式表程序員所用）展示了頭部、引文以及引文前后的文本，這些部分每個都是段落的獨立子節點，但解析樹沒法展示以下特征：頭部是整個段落的一個屬性，文本是內容結構中的兩個部分，引文嵌入在文本內部。

事實上，數據結構本身并沒有段落和引文之分或與之相關的東西。數據結構僅僅是關聯信息的圖型結構，就像一個有著“段落”取值的通用標識符。程序應當能推斷出文檔意義與使用標簽之間的一致性，并能在樹形結構從一種形式轉換為另一種形式時利用這種知識。但是，這種轉換（例如，通過XSLT、DSSSL或者類似C++的程序語言進行轉換）依靠的是語義推理，而不是顯性的編碼。

圖2展示了如何通過利用語義知識來豐富和增強語法樹。利用知識表示技術能夠在更高的層面上將整體和部分之間的關系進行編碼，更適合計算機處理。此圖展示了一種傳統的語義網絡表示方法，當然其他的方法也正在發展中，包括框架表示法、規則表示法、形式語法以及基于邏輯的表示法等[31] [41]。語義網計劃（本文第八部分）的發展甚至能為標記語言本身提供合適的表示方法。問題的關鍵在于，要為無法由傳統的XML/SGML解析器建模和執行的抽象概念、關聯和約束建立一個層次體系。

在機器可讀的文件（如DTD或者語法結構）里的編碼知識能夠被用于驗證文檔的語義約束，為應用程序提供更強大的文檔模型。這些更有表現力的表示方法為更好的文檔處理系統的設計和實現提供了強有力的支持。

6 應 用

近年來，許多新技術的發展使得常規的結構化標注越來越盛行。這些技術在信息管理中主要強調以下幾個方面的問題。

轉換和聯合。對于SGML/XML開發人員來說，最常見的工作就是設計轉換形式，從一種應用語法轉換到另一種應用語法[21]。這樣做是為了創建新型文件表示方式，或者方便其存儲于數據庫中。有時候，開發人員需要整合或調整大型的數字文檔集合，每個數字文檔都由一種無法進行互操作的標記語言表示[3] [32]。不考慮轉換的范圍大小，常規的解決方式是使用一種在語法解析樹上起直接作用的轉換程序語言[8]。源文件分析中產生的樹結構轉換成目標語言的樹結構實例。轉換之后的樹被序列化成新的文檔實例、圖形或音頻。

信息孤島。這個問題與上述的轉換問題很相似，但是其目標不是將一個形式的文檔轉換為另一種形式的文檔，而是允許分布存儲的文檔或文檔片段能夠向系統用戶提供一個通用的透明訪問接口[9] [13]。盡管沒必要將文檔從一種標記語言逐字逐句地轉換成另一種標記語言，但是系統必須能夠保證文檔內容表面上看起來是無縫融合的，盡管文檔的編碼可能差別很大。

可獲得性。創作工具逐漸接受了結構化標記，這已經成為視覺障礙用戶獲取數字文檔的福音。聲明性標記使得人們能夠借助屏幕閱讀器或盲文顯示器進行閱讀，并在助記符幫助下進行推斷，而不是利用圖形線索。但是，目前這樣的應用需要依賴用戶自身的能力或界面軟件，基于獨立的標簽內容或語法得出的結構性推論。正如標簽集文檔中描述的一樣，標記語法約束及標記的意義和使用都嚴格地依賴于文檔作者的可信性。遺憾的是，作者經常會誤用標簽，最糟糕的例子就是在web頁面上使用“頭部”標簽來標記某些特別的版式。

安全處理。發展更有表達力的標記模式語言（比如W3C的XML Schema語言）的部分動力是人們認識到標記錯誤、誤用和濫用的后果遠比糟糕的格式化輸出要嚴重得多。聲明性標記不僅用于電子商務，也用于安全信息領域，比如醫療記錄[33]和航空工業[7]。這些領域的開發人員不但要確保數字文檔的語法結構規范，也要確保其遵守某些安全協議，以保證文檔的安全處理、存儲、傳輸和表示。

7 標記語義的優點

目前BECHAMEL計劃的調研結果顯示，標記語義能夠通過以下幾種方式解決上述問題。

聲明性的、機器可讀的語義描述。就目前的實際情況而言，結構化標記語言設計師用自然語言文本表達了標簽的意義，明確了其合適的使用方式。形式化的標記語義體系使得本體之間的聯系能被計算機程序清晰地表達，并實現自動化處理。

假設的驗證。在沒有形式化標簽集的文檔環境中，擁有標記語義解釋能力的系統提供了一種測試猜測和驗證假設的環境。在這種環境中，未公開的標記語言用戶會對那些他認為在文檔數據庫中持續應用的屬性和規則進行推測。之后文檔處理軟件就會檢索那些與假設規則兼容或不兼容的文檔元素。

語義約束的增強。支持有效性驗證的解析器不僅能夠像常規語義解析器一樣完成語法驗證，也能夠在發現或編寫語義的過程中同時驗證這種猜測，這樣的解析器同樣能夠加強語義約束。這項操作同假設驗證一致，但是在這種情況下，語義約束是已知且規范的。

優化的更有表現力的 APIs。使用SGML和XML應用程序轉換或表示數字文檔時，都會使用標記語義。但是只有在執行程序時，更高級別的屬性和關聯才會顯示出來。形式化的、機器可讀的語義會豐富應用程序的接口，加快軟件設計速度，隨著標記語言的發展和變化，這些軟件維護起來也能更加方便和安全。

8 相關工作

針對上述挑戰和問題，還有很多其他的文檔處理技術、標準和研究計劃。接下來我們梳理一下試圖解決這些問題的現有想法。

語義網[2]。語義網指的是眾多相互聯系的研究和標準化工作，就像當下一些有關標記和知識表示技術的想法。最核心的當屬W3C的資源描述框架，當然也包括其他的技術，比如ISO的主題圖技術[16]。語義網的范圍很廣，目標宏大，旨在利用通用知識表示技術來完善標記語言，從而“促進人類知識的全面發展”[2]。語義網的研究和標準化不同于當下的想法：不是對特定領域進行語義描述，而是實現對所有領域的知識進行語義標注。當前研究的目標特別盯在“文檔標記語義”上，而非“通用的語義標記”。語義網技術的進步會讓我們利用語義網標記語言對標記的語義進行編碼成為可能。

W3C的文檔對象模型。文檔對象模型是一個應用程序接口，是對XML文檔進行分析后生成的層級式數據結構。人們想設計能為標記語義提供各種接口的系統，類似于DOM所提供的標記語法相關的形式，最終能夠形成“語義DOM”，對W3C的語法DOM形成補充。

W3C 的Schema。XML Schema是一門基于XML的語言，能夠替代傳統的DTDs，用于約束XML文檔。DTDs的局限性推動了這門語言的發展，這些局限同我們在BECHAMEL計劃中面對的問題是類似的。Schema允許文檔類設計師定義復雜的數據類型，就像在高級程序語言里面的做法一樣。但是，為了對標簽集建檔中的所有關系和約束進行編碼，我們還需要比當下的XML Schema更強大的表達形式。

超媒體/時基結構語言（Hypermedia/Time-based Structuring Language ，HyTime）的架構形式。適應性廣泛的架構技術來自于這樣一種認識，即不同的標記語言應用程序常常通過樣式各不相同但語義上等價的結構進行編碼[15]。架構形式允許文檔類設計師將其自有的特定元素實例映射到更通用的各種架構實例上，這些架構實例更便于在不同的應用程序之間進行映射[34]。這些映射的確表示了語義知識的約束形式，有利于解決上述轉換和集成上的挑戰。BECHAMEL計劃在某種程度上就是要建立一個比架構形式表達更多語義關系的模型。

注 釋

[1] AAP. Authors Guide to Electronic Manuscript Preparationand Markup. Electronic Manuscript Series. Association of American Publishers， Washington， DC， 1986. Current

version： ANSI/NISO/ISO 12083 - 1995 Electronic Manuscript Preparation and Markup， National Information Standards Organization， 1995

[2] BERNERS-LEE， T.， HENDLER， J.， AND LASSILA， O. The semantic web. Scientific American 284， 5 （May 2001）， 35-43

[3] COLE， T.， AND KAZMER， M. SGML as a component of the digital library. Library High Tech 13， 4 （1995）， 75-90

[4] COOMBS， J. H.， RENEAR， A. H.， AND DEROSE， S. J. Markup systems and the future of scholarly text processing. Communications of the Association for Computing Machinery 30， 11 （1987）， 933-947

[5] DEROSE， S. J.， DURAND， D.， MYLONAS， E.， AND RENEAR， A. H. What is text， really？ Journal of Computing in Higher Education 1， 2 （1990）， 3-26

[6] DUBIN， D.， RENEAR， A.， SPERBERG-MCQUEEN， C. M.， AND HUITFELDT， C. A logic programming environment for document semantics and inference. Presented at

ALLC/ACH， T¨ubingen， Germany， July 2002

[7] ENSIGN， C. SGML： The Billion Dollar Secret. Prentice Hall， Upper Saddle River， NJ， 1997， ch. 5： United Technologies Sikorsky Aircraft Corporation

[8] FAUSEY， J.， AND SHAFER， K. All my data is in SGML. Now what？ Journal of the American Society for Information Science 48， 7 （1997）： 638-643

[9] FAY， C. The document management alliance. Bulletin of the American Society for Information Science 25， 1 （October/November 1998）， 20-24

[10] GOLDFARB， C. F. Document Composition Facility： Generalized Markup Language （GML） Users Guide. IBM General Products Division， 1978. SH20-9160-0

[11] GOLDFARB， C. F. A generalized approach to document markup. In Proceedings of the ACM SIGPLAN-SIGOA Symposium on Text Manipulation （New York， 1981）， ACM：68-73

[12] IBM CORP. Application Description， IBM System/360 Document Processing： System. White Plains， NY， 1967. Form No. H20-0315

[13] IDE， N. M.， AND SPERBERG-MCQUEEN， C. M. Toward a unified docuverse： Standardizing document markup and access without procrustean bargains. In Proceedings of the 60th Annual Meeting of the American Society for Information Science （Medford， NJ， 1997）， C. Schwartz and M. Rorvig， Eds.， Information Today， Inc.， pp. 347-360

[14] ISO. ISO 8879-1986 （E）. Information processing — Text and Office Systems — Standard Generalized Markup Language （SGML）. International Organization for Standardization， Geneva， 1986

[15] ISO. ISO/IEC 10744：1997： Information processing - Hypermedia/Time-based Structuring Language （HyTime）， second ed. International Organization for Standardization， Geneva， May 1997， appendix A.3 Architectural Form Definition Requirements

[16] ISO. ISO/IEC 13250： 2000 Information technology - SGML Applications - Topic Maps. International Organization for Standardization， Geneva， 2000

[17] KNUTH， D. E. TEX and Metafont： New Directions in Typesetting. Digital Press， Bedford， MA， 1979

[18] LAMPORT， L. LATEX - A document preparation system. Addison-Wesley， Reading， MA， 1985

[19] LESK， M. E. Typing Documents on UNIX and GCOS： The -ms Macros for Troff， 1977

[20] MAMRAK， S. A.， BARNES， J.， HONG， H.， JOSEPH， C.， KAELBLING， M.， NICHOLAS， C.， OCONNELL， C.， AND SHARE， M. Descriptive markup - the best approach？ Communications of the Association for Computing Machinery 31， 7 （1988）， 810-811

[21] MAMRAK， S. A.， KAELBLING， M. J.， NICHOLAS， C. K.， AND SHARE， M. A software architecture for supporting the exchange of electronic manuscripts. Communications of the ACM 30， 5 （1987）， 408-414

[22] OSSANNA， J. F. NROFF/TROFF users manual. Tech. Rep. 54， Bell Laboratories， Murray Hill， NJ， October 1976. [23] RAMALHO， J. C.， AND HENRIQUES， P. R. Beyond DTDs： constraining data content. In Proceedings of SGML/XML Europe 98 （Paris， May 1998）， GCA

[24] RAYMOND， D. R.， AND TOMPA， F. W. Markup reconsidered. Technical Report 356， Department of Computer Science， The University of Western Ontario， 1993. Presented at the First International Workshop on the Principles of Document Processing， Washinton DC， October 21-23 1992； an earlier version was circulated privately as ”Markup Considered Harmful” in the late 1980s

[25] RAYMOND， D. R.， TOMPA， F.W.， AND WOOD， D. From data representation to data model： Meta-semantic issues in the evolution of sgml. Computer Standards and Interfaces 18， 1 （January 1996）， 25-36

[26] REID， B. K. Scribe Introductory Users Manual， first ed. Carnegie-Mellon University， Computer Science Department， Pittsburgh， PA， August 1978

[27] REID， B. K. Scribe： A Document Specification Language and its Compiler. PhD thesis， Carnegie-Mellon University， Pittsburgh， PA， 1981. Also available as Technical Report CMU-CS-81-100

[28] RENEAR， A. The descriptive/procedural distinction is flawed. Markup Languages： Theory and Practice 2， 4 （2000）， 411-420

[29] RENEAR， A. Raising the bar： Text encoding from a logical point of view. CLIP 2001： Computers， Literature， Philology， Gerhard-Mercator University， Duisburg， Germany， December 2001

[30] RIZZI， R. Complexity of context-free grammars with exceptions and the inadequacy of grammars as models for XML and SGML. Markup Languages： Theory and Practice 3， 1 （2002）：107-116

[31] ROWE， N. C. Artificial Intelligence through Prolog. Prentice Hall， Englewood Cliffs， NJ， 1988

[32] SCHATZ， B.， MISCHO， W. H.， COLE， T.W.， HARDIN， J. B.， BISHOP， A. P.， AND CHEN， H. Federating diverse collections of scientific literature. Computer 29 （May 1996）， 28-36

[33] SHOBOWALE， G. SGML， XML， and the document-centered approach to electronic medical records. Bulletin of the American Society for Information Science 25， 1 （October/November 1998）， 7-10

[34] SIMONS， G. F. Using architectural forms to map TEI data into an object-oriented database. Computers and the Humanities 33， 1-2 （1999）， 85-101. Originally delivered in 1997 at the TEI 10 conference in Providence， RI

[35] SPERBERG-MCQUEEN， C. M.， DUBIN， D.， HUITFELDT， C.， AND RENEAR， A. Drawing inferences on the basis of markup. In Proceedings of Extreme Markup Languages 2002 （Montreal， Canada， August 2002）， B. T. Usdin and S. R. Newcomb， Eds

[36] SPERBERG-MCQUEEN， C. M.， HUITFELDT， C.， AND RENEAR， A. Meaning and interpretation of markup. Markup Languages： Theory and Practice 2， 3 （2000）：215-234

[37] SPERBERG-MCQUEEN， C. M.， HUITFELDT， C.， AND RENEAR， A. Practical extraction of meaning from markup. Paper delivered at ACH/ALLC 2001， New York， 2001

[38] SPERBERG-MCQUEEN， C. M.， RENEAR， A.， HUITFELDT， C.， AND DUBIN， D. Skeletons in the closet： Saying what markup means. Presented at ALLC/ACH， T¨ubingen， Germany， July 2002

[39] SPERBERG-MCQUEEN， M.， AND BURNARD， L.， Eds. Guidelines for Text Encoding and Interchange （TEI P3）. ACH/ALLC/ACL Text Encoding Initiative， Chicago， Oxford， 1994

[40] SPRING， M. B. The origin and use of copymarks in electronic publishing. Journal of Documentation 45， 2 （June 1989）， 110-123

[41] TANIMOTO， S. L. The Elements of Artificial Intelligence. Computer Science Press， Rockville， MD， 1987

[42] UNITED STATES DEPARTMENT OF DEFENSE. MIL-M-28001 Military Specification： Markup Requirements and Generic Style Specification for Electronic Printed Output and Exchange of Text， 1988

[43] WELTY， C.， AND IDE， N. Using the right tools： Enhancing retrieval from marked-up documents. Computers and the Humanities 33， 1-2 （1999）， 59-84. Originally delivered in 1997 at the TEI 10 conference in Providence， RI

——本文注釋標注順序遵英文原文，未作改動。