XML標記語義的示例分析

這篇文章主要為大家展示了“XML標記語義的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“XML標記語義的示例分析”這篇文章吧。

 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相關的機器可處理的語義描述方面的設想還未形成，這是目前工程領域的問題和未來發展障礙的根源，相關的語義學研究也很少，但是很多學者已經開始關注此問題。W3CSchema方面的工作與此相關，但也只是覆蓋了這個問題中的很小一部分（比如數據類型）。W3C的“語義網”計劃也與此相關，但它是為了發展通用的基于XML的知識表示技術。我們的研究重點是文檔標記的語義，它隱藏在實際的文檔處理系統中。人們可能會說語義網的本質就是設計語義標記，然而在本文中，我們認為解決以上問題還必須要深入考慮標記的本質意義。
接下來，本文首先從歷史背景方面說明標記的意義問題（標記在文本處理方法的發展中扮演了有趣的角色）；其次，詳細描述是何種因素產生了形式語義標記需求，何種因素決定了語義需求；最后簡要介紹一項多個機構正在參與實施的研究計劃——BECHAMEL標記語義計劃，該計劃正努力解決標記的語義問題。
 2　歷史背景  
文檔“標記”大概可以算作傳播系統的一部分，包括早期的書寫、抄寫出版和印刷，但是隨著數字文本處理和排版的發展，標記的使用變得自覺又常見，同時也成了系統開發中一個重要的創新領域。20世紀60年代到80年代是文檔標記系統全面系統化發展的時期，重點工作是提升數字排版和文本處理的有效性和功能性。20世紀80年代初期，人們依舊致力于研究標記的理論框架，并利用該框架支持高性能系統的開發。這方面的一些成果已經發表，但大部分成果還只是記錄在工作文檔和各種標準形式的產品上。
在這個階段出現的一種觀點是，文檔作為一種智力成果，更適合被抽象為一系列對象（如章節、段落、公式等）的有序層次化結構模型，而不是一維文本字符流模型。字符流常夾雜著大量定義格式的編碼、描述設計布局的結構（如頁碼、分欄、印刷行）、像素值矩陣，以及其他一些在不同的文檔處理及存儲系統中潛在的表達形式。有序層級結構模型概括了兩種具有本質差別的標注，分別是識別編輯文本對象（標題、章節等）的標注和說明版面要求的標注。前者的應用已經取得一些成果。諸如標題、章節、段落、方程式、引文之類的相關文檔元素能被分隔標記清晰地標示出來，之后通過映射給元素類型的規則來對元素進行間接處理。這種內容和形式的分離，能夠以常見的組合經濟的方式實現基礎層面的間接性和抽象化。在文檔處理的所有方面，這種分離形式有巨大而多樣的實用價值，更重要的是它似乎說明了“文檔到底是什么”這個問題。用于實現如此功能的描述性標記不只是標出了元素的范圍，也攜帶了文檔模型想要揭示的意義（如這段文本是一個章節）。
20世紀80年代初期，美國國家標準化局（ANSI/ISO）發布了很有影響力的SGML文檔標記元語法，并梳理了標記和文檔結構方面之前所做的理論和分析工作。SGML為定義描述性標記語言提供了一種機器可讀的形式。作為一種元語法，SGML沒有定義標記語言，而是詳述了開發標記語言中的機器可讀的技術。這個定義的核心是一種類似于巴科斯-諾爾范式（Backus-Naur Form，BNF）的形式化表達機制。這一機制攜帶有用于定義類型化屬性及其取值的規則，以及其他一些用于進一步抽象化和間接化的設計（參見注釋中對文檔類型定義（Document Type Definitions，DTDs）和巴科斯-諾爾范式相似程度方面的總結）。從結構上來說，SGML文檔是一種具備有序分支和帶標記節點的樹，它是其相應的DTD的形式化產物。
經過多年的分析和實踐，SGML背后的基本理念已經眾所周知。利用元語法層面的行業級標準和詞表層面的本地化創新帶來的優點，SGML的特有機制（類巴科斯-諾爾范式的元語法，類型化屬性／屬性值對，實體引用等）在應用程序和工具方面得到了高效實現。SGML標記語言本身在發展中似乎也同時支持和優化用于文檔系統設計、實施和利用的理想的工作流程。20世紀80年代中期到90年代初期，大量基于SGML的標注系統發展起來。
盡管SGML的發展得到很多關注，其想法也不錯，并在多個領域成功實施，但在最初的十年里，幾乎沒人使用它。導致這個結果的因素有很多，但最重要的還是SGML自身過于復雜，特別是SGML中包含了許多復雜的可選屬性，對應的軟件可能根本沒必要對其實現，導致SGML軟件開發速度非常緩慢。更糟糕的是，如果文檔未經DTD驗證，進一步的分析就不可能實現。縮寫控制意味著如果不考慮文檔語法，元素邊界都無法確定下來。另外，SGML還包含了一些其他屬性，它們會導致已有的語法分析工具不適用于形式語法，無法進行高效的語法分析。
在網絡出版和交流方面，SGML系統可應用于HTML（超文本標記語言）方面。最初的HTML版本定義很松散，缺乏正式的語法說明。后來人們對HTML的SGMLDTD有了興趣，事實證明為已經成為“正確”實踐的東西設計DTD是很困難的。更重要的是，由于在最初的HTML說明書中，供應商隨意地把程序性標記（如<center>）添加到關鍵性的描述性標記中（如<title>），導致開發者和用戶同時忽略描述性標記和程序性標記的區別。HTML的描述性部分甚至不能很好地反映文檔的層級結構，說明書不能提供樣式表語言來支持間接性。最后，SGML的機制無法擴展元素集和使用替換元素集，HTML文檔似乎不能被通用的SGML處理器（允許拓展和替換DTDs）處理，而只能被特定的HTML格式化程序處理，配合處理器中硬編碼的格式規則處理HTML標簽。
HTML后續的發展可以看作原有松散的HTML語言努力向SGML語言序列轉變的過程。如果有足夠的時間和資源來應用那些成熟的文檔系統設計規則，那么這種轉變是可以實現的。不過，新成立的W3C機構在采納新元素集合以及在Web應用SGML上面臨很大的壓力。SGML的不足使其很難在Web上發揮SGML和描述性標記的優勢。主要問題是SGML中存在大量多選特征、復雜的形式化語法，以及必須依賴DTD確定元素等。
為了確保HTML和其他相關技術能夠充分利用元語法的優點，用戶能夠更便捷地開發和分享新的特定領域中的元素，文檔能夠不經DTD索引就被解析為元素樹，SGML工具和應用能夠協調發展，W3C創建了SGML的子集，希望能夠提供一個相對簡單的標準（無需進行選擇）、一些相對簡單的語法，以及一種無需DTD也能處理未經驗證的文檔格式的方法，于是XML應運而生。經過一年半的發展，XML被W3C以推薦標準在1998年正式推出。
自1998年開始，新穎的XML標記語言呈現爆炸式增長，這種快速發展的勢頭一直持續到今天。這種爆炸式發展的原因在于：
（1）特定領域的新型標注系統的需要。隨著科學、醫學、商業、法律、工程和這些大型學科的特定領域中的網絡電子出版應用的增長，新型標注系統需要開發。
（2）降低開發新型工具及其應用成本和復雜程度。與SGML相比，解析XML更加簡單。
（3）XML標記支持與出版相關的信息處理與傳播過程，以及與出版無關的應用。
值得慶幸的是，我們終于開發出有效又容易實施的技術，并以此來創造高性能的標記語言、數字文檔，以及與其他信息管理程序相融合的文檔處理和出版系統。特別需要指出的是，對文檔結構中潛在意圖進行深加工的需求促進了新的系統功能的產生，同時也提出信息自動處理的需求，至少是不用大量人工干預的新需求。
 3　問　題  
不幸的是，已有的一些經驗和反饋讓我們清醒地意識到，我們對描述性標記在傳達意義上的理解，以及目前的技術根本沒辦法滿足我們的期望。
20世紀80年代，文檔標記的系統化和體系化工作主要集中在三個方面。
（1）通用文檔模型的概念化。
（2）文檔標記語言相關的形式化規范、詞匯表和語法相關技術的開發。該文檔標記語言可以定義具體的文檔類，并對模型進行實例化呈現。
（3）標記語言的開發（如CALS、AAP、TEI、HTML等）。
使用描述性標記語言來識別和標注文檔的邏輯部分能清晰地傳遞以前只能以潛在形式存在的“意義”。至少程序性標記的意義可以十分明確、清晰，并適用于機器處理。
很多人將XML文檔稱為“自描述數據”。雖然早期有一些不同的聲音（參見Mamrak，最重要的是Raymond和Tompa的觀點），但在描述性標記發展的最初階段，文檔研究人員的熱情漸漸消失，似乎大多數人覺得沒必要再探索更費力的文檔表示方法。定義清晰的SGML標記語言表達了文檔結構的潛在意義，使其能充分、有效地用于機器處理。本文的一位作者曾經參與寫過這樣一句話，“最后，我們應當清楚地知道，對于相互競爭的標記系統來說，描述性標記不僅是最好的方法，而且是人們可以想到的最好方法”。
20世紀90年代的經驗表明，這份自信有些盲目。從實際的角度來看，今天的情況有了很大改善，但互操作性和功能性上的一再失敗表明，在為文檔提供潛在意義及計算機可處理形式方面，SGML/XML并沒有真正成功。在SGML/XMLDTD中，元素和屬性的精確度同其他相似的文檔類型定義中的精確度無法匹配，部分內容也不是形式化的，需要推斷的地方并沒有唯一肯定的答案。但是定性地來說，人們對文檔的認識與SGML出現之前不同，那個時候人們對文檔結構意義的認識來自于對那些相對隱晦不明的線索的反思。
DTD的本質屬性解釋了出現上述情況的原因：DTD僅僅顯示一個詞匯表及其對應的語法，并不表示詞匯之間的語義關系。一般意義上的“標題”元素是否用<title>表示，<title>是否與我們平常所說的“標題”概念類似，這些都不能由DTD決定。DTD只能表明有一個特定的元素，它的標簽是字符串“title”，該標簽可能會與其他元素一起使用，這些元素的定義方式都一樣。所以，使用標記語言來標注文檔的內容開發人員和軟件設計人員需要通過文本中與“title”相關的自然語言及其在上下文中的使用方式簡單地推斷<title>標簽表示的意義。也許最初的語言設計者也無法系統嚴格地定義<title>的意義。
當然，這夸大了實際情況。從某種意義上說，在標記語言開發人員提供的純自然語言文檔中，每個標記的意義基本可以表達清楚。但是，即使是工業和學術領域中標記格式最好的DTD文檔，也沒有從根本上解決問題。
設計一款反映標記語言中語義關系的軟件時，語言設計人員必須能夠將文檔中各部分之間的關系表示清楚；之后軟件工程師必須能夠（搜索、查找、打開）使用這個標記語言文檔，并設計應用程序來表現其優點。這兩個步驟都無法用機器進行驗證，可信度無法保證。如果要人工參與的話，就會有礙高性能網絡文檔處理和發布系統的發展。所以我們需要一個機制保證標記語言設計人員能夠詳細地、形式化地指定語義關系，還能被應用程序讀取加工，并完成自我配置，無需一個個地人工參與。
下面我們來看一些具體的語義關系。這些關系或多或少地存在潛在的實用價值，但目前它們無法方便系統地得以利用，因為尚無標準的機器可處理的表現形式。事實上，許多關系至關重要，軟件設計師常以特定的方式推斷它們在文檔中的存在，并構建特定的系統對其加以利用。
類關系。SGML/XML中不包含用以表達元素、特征或特征值中類的層級結構或類成員關系的通用結構。類是目前軟件工程主流結構中最基本和最實用的模塊。我們不能說，段落是一種結構上的元素（isa關系），或者所有結構元素都是可編輯的元素(ako關系)。兩種基本的SGML/XML設計有時可以按照屬性/值實現基礎分類（具體可以使用“type”和“class”這兩種屬性）。這種分類技術尚不夠成熟，SGML和XML沒能提供更好的機制來控制和限制其使用。在實際應用中，許多文檔類型設計師都采用類的層級結構來進行設計。XML Schema提供了類關系的清晰聲明，但它本身并不能在語義上說明這些復雜類型與其他復雜類型到底有哪些區別。
繼承關系。在許多標記語言（例如TEI和HTML4.0）中，某些屬性會被包含元素所繼承，某些情況下被包含的文本內容也會繼承這些屬性。例如，如果一個元素的屬性/值符號為“lang="de"”，這表明這一段文本是德語，那意味著它的所有子元素屬性都是德語。但是DTD沒有提供正式說明用以指定哪些特征可以被繼承。而且，這樣的繼承關系并不是固定不變的，有時也會因為包含元素的二次定義而改變。繼承的方式也有很多種，有些涉及元素的屬性，有些涉及屬性的屬性，另一些則涉及文本和元素的內容。例如，如果標記表示一個句子是德語，這意味著句子中的所有單詞（除非特殊情況）都是德語。同樣地，所有單詞短語中標記了刪除屬性的就刪掉，標記了重點屬性的就強調，將一部分內容標記為一個段落，就意味著這部分內容中的所有單詞（或元素）都屬于這個段落。無法指定DTD繼承哪些屬性，也不能指定其繼承邏輯（包括規則錯誤）。軟件設計師經常對特定標記語言中的這些關系進行推理（判斷正誤），然后在其開發的工具和應用程序中加以實現。
語境關系和引用關系。在許多標記語言中，即使某元素有一個固定的意義用于標記相同元素類型，這個元素也可能會因為上下文關系的不同而表示不同的含義。例如，某些文本的標記為“<title>”，其具體所指還要依賴文本的結構位置。“<head>”下的“<title>”是指對象“<document>”的標題，而“<chapter>”下的“<title>”是指這一章節部分的標題。判斷其為何種標題的標準并不存在。參考文獻中包含“<title>”元素的情況更復雜一些，這里的標題是文章外部的一個實體。類似這樣的關系不能用DTD表示，但可由軟件設計師推理得出，這對滿足文本的高效自動化處理很有必要（如果每個意義都用不同的通用標識符表示，那只能解決一小部分這樣的問題。因為仍然有必要說清楚屬性的二元特征，提供可解析的表達方式來定位屬性應用的對象）。
所指中的本質變化。有一種類似的但意義更加模糊的情況存在，同一對象有多種屬性，每種屬性都是用同樣的格式指向同一個指代物，但必須仔細解釋以確保其所指的明確性。例如，一個特定元素實例有以下三個特性：它是一個定理，它是德語寫的，它是字跡模糊的。這樣簡單直接的謂詞描述表示的是同一個東西(或元素實例)嗎？這樣表示知識足夠穩健嗎?實際上它的意思是這樣的，這些抽象的句子是德語寫的，它們表達的命題是定理，它們的具體表現樣式是模糊不清的。嚴格來說，沒有哪個東西擁有所有這些特性。
完全同義和部分同義。標記語言的完全或部分同義是一種極為重要的語義關系，而用于描述這種同義關系的機制缺失造成嚴重的異質性問題。使用單一標記語言也許能消除完全同義，但是隨著標記語言種類的增加，完全和部分同義仍舊是標記語言之間難以表示又重要的關系。目前我們還沒有合適的計算機可處理的形式化方法記錄不同標記語言中的元素、屬性和屬性值的同義性。建構形式（見下文）可以記錄多數完全同義的情況，但部分同義卻很難記錄，在實際應用中部分同義現象更為常見。由類包含關系表示的部分同義問題在解決異質性問題上還有很長的路要走。
 4　BECHAMEL計劃  
BECHAMEL標記語義計劃起源于20世紀90年代末，由Sperberg-Mcqueen（W3C／MIT）和其他機構的研究人員合作完成，他們來自文化科系、語言與信息技術部門機構、卑爾根大學研究基金會（Bergen University Research Foundation）、伊利諾伊大學香檳-厄巴納分校的圖書情報研究生院電子出版研究小組。此計劃的名稱由所有合作者所在城市名稱的縮寫形成（Bergen, Norway; Champaign, Illinois; Esp?ola, NewMexico）。
BECHAMEL計劃的研究目標如下。
（1）定義與文檔標記語義密切關聯的表示和推論問題，開發一種所有語義感知文檔處理系統都必須解決或面對的問題分類法和描述法。
（2）研究常見標記語言的屬性和語義關系，評估規范的知識表示技術（如語義網絡、框架、邏輯、形式語法和產生式規則）的適用性。為了對這些關系和屬性建模，還要考慮它們在知識表示上的充分性、優雅性、簡約性和計算效率等。
（3）開發并測試形式化的、機器可讀的表示框架，在這種框架需要能夠表示標記語言的語義。
（4）探索語義表示技術的應用形式，如支持轉碼、信息檢索、可獲得性增強等。目前我們關心的重點是支持文檔數據庫實例的語義推理，因為我們相信這是應用知識表示技術最好的著力點。
（5）與人文計算研究領域的數字圖書館內容編碼計劃合作，聯合軟件工具開發人員，進行語義表示方案的大規模測試。
早期的Prolog實驗臺已經全面發展成為一個知識表示原型平臺，用于表示結構性文檔中的事實和推理規則。該系統允許分析人員指定某些事實（如通用標識符和屬性值），并將其與語義實體和屬性有關的推論性事實分開。
該系統還提供了一個抽象層，使得標記的意義能夠以機器可讀的和可執行的形式明確表達。在此基礎上可以根據文檔組成部分進行推論，包括那些模糊的結構，如層次重疊的組成部分。我們已經開發出一個謂詞集合，能夠模仿W3C的文檔對象模型中用于節點層級結構導航的方法，并且可以在文檔類型定義中檢索各種屬性取值和有關信息。這樣就能明確區分解析器分析的語法信息，分析人員表達的文檔語義。
初步的研究結果顯示語義推理識別的復雜性以及語境不確定理解的復雜性。這個雛形推理系統證明有關標記的自動推理是可行的，并且Prolog的規則可以處理非單調性和情景模糊性等復雜情況。進一步的研究可以參考引文。
 5　標記的語義建模  
文檔標記的語義是能夠被標記語言用戶理解的抽象結構、屬性和關系，標記及其語法隱含著這種語義線索。標記的語義可以借助知識表示技術通過明確結構、關系和屬性來構建相應的計算化模型。

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

熟悉結構

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

明顯的標記是為方便人類讀者而設計的。這些標記并不能借助文檔語法分析器，從數據結構中抽取出來。正如圖1所示，解析樹（樣式表程序員所用）展示了頭部、引文以及引文前后的文本，這些部分每個都是段落的獨立子節點，但解析樹沒法展示以下特征：頭部是整個段落的一個屬性，文本是內容結構中的兩個部分，引文嵌入在文本內部。
事實上，數據結構本身并沒有段落和引文之分或與之相關的東西。數據結構僅僅是關聯信息的圖型結構，就像一個有著“段落”取值的通用標識符。程序應當能推斷出文檔意義與使用標簽之間的一致性，并能在樹形結構從一種形式轉換為另一種形式時利用這種知識。但是，這種轉換（例如，通過XSLT、DSSSL或者類似C++的程序語言進行轉換）依靠的是語義推理，而不是顯性的編碼

圖2展示了如何通過利用語義知識來豐富和增強語法樹。利用知識表示技術能夠在更高的層面上將整體和部分之間的關系進行編碼，更適合計算機處理。此圖展示了一種傳統的語義網絡表示方法，當然其他的方法也正在發展中，包括框架表示法、規則表示法、形式語法以及基于邏輯的表示法等。語義網計劃（本文第八部分）的發展甚至能為標記語言本身提供合適的表示方法。問題的關鍵在于，要為無法由傳統的XML/SGML解析器建模和執行的抽象概念、關聯和約束建立一個層次體系。
在機器可讀的文件（如DTD或者語法結構）里的編碼知識能夠被用于驗證文檔的語義約束，為應用程序提供更強大的文檔模型。這些更有表現力的表示方法為更好的文檔處理系統的設計和實現提供了強有力的支持。
6　應　用
近年來，許多新技術的發展使得常規的結構化標注越來越盛行。這些技術在信息管理中主要強調以下幾個方面的問題。
轉換和聯合。對于SGML/XML開發人員來說，最常見的工作就是設計轉換形式，從一種應用語法轉換到另一種應用語法。這樣做是為了創建新型文件表示方式，或者方便其存儲于數據庫中。有時候，開發人員需要整合或調整大型的數字文檔集合，每個數字文檔都由一種無法進行互操作的標記語言表示。不考慮轉換的范圍大小，常規的解決方式是使用一種在語法解析樹上起直接作用的轉換程序語言。源文件分析中產生的樹結構轉換成目標語言的樹結構實例。轉換之后的樹被序列化成新的文檔實例、圖形或音頻。
信息孤島。這個問題與上述的轉換問題很相似，但是其目標不是將一個形式的文檔轉換為另一種形式的文檔，而是允許分布存儲的文檔或文檔片段能夠向系統用戶提供一個通用的透明訪問接口。盡管沒必要將文檔從一種標記語言逐字逐句地轉換成另一種標記語言，但是系統必須能夠保證文檔內容表面上看起來是無縫融合的，盡管文檔的編碼可能差別很大。
可獲得性。創作工具逐漸接受了結構化標記，這已經成為視覺障礙用戶獲取數字文檔的福音。聲明性標記使得人們能夠借助屏幕閱讀器或盲文顯示器進行閱讀，并在助記符幫助下進行推斷，而不是利用圖形線索。但是，目前這樣的應用需要依賴用戶自身的能力或界面軟件，基于獨立的標簽內容或語法得出的結構性推論。正如標簽集文檔中描述的一樣，標記語法約束及標記的意義和使用都嚴格地依賴于文檔作者的可信性。遺憾的是，作者經常會誤用標簽，最糟糕的例子就是在web頁面上使用“頭部”標簽來標記某些特別的版式。
安全處理。發展更有表達力的標記模式語言（比如W3C的XML Schema語言）的部分動力是人們認識到標記錯誤、誤用和濫用的后果遠比糟糕的格式化輸出要嚴重得多。聲明性標記不僅用于電子商務，也用于安全信息領域，比如醫療記錄和航空工業。這些領域的開發人員不但要確保數字文檔的語法結構規范，也要確保其遵守某些安全協議，以保證文檔的安全處理、存儲、傳輸和表示。
7　標記語義的優點
目前BECHAMEL計劃的調研結果顯示，標記語義能夠通過以下幾種方式解決上述問題。
聲明性的、機器可讀的語義描述。就目前的實際情況而言，結構化標記語言設計師用自然語言文本表達了標簽的意義，明確了其合適的使用方式。形式化的標記語義體系使得本體之間的聯系能被計算機程序清晰地表達，并實現自動化處理。
假設的驗證。在沒有形式化標簽集的文檔環境中，擁有標記語義解釋能力的系統提供了一種測試猜測和驗證假設的環境。在這種環境中，未公開的標記語言用戶會對那些他認為在文檔數據庫中持續應用的屬性和規則進行推測。之后文檔處理軟件就會檢索那些與假設規則兼容或不兼容的文檔元素。
語義約束的增強。支持有效性驗證的解析器不僅能夠像常規語義解析器一樣完成語法驗證，也能夠在發現或編寫語義的過程中同時驗證這種猜測，這樣的解析器同樣能夠加強語義約束。這項操作同假設驗證一致，但是在這種情況下，語義約束是已知且規范的。
優化的更有表現力的APIs。使用SGML和XML應用程序轉換或表示數字文檔時，都會使用標記語義。但是只有在執行程序時，更高級別的屬性和關聯才會顯示出來。形式化的、機器可讀的語義會豐富應用程序的接口，加快軟件設計速度，隨著標記語言的發展和變化，這些軟件維護起來也能更加方便和安全。
8　相關工作
針對上述挑戰和問題，還有很多其他的文檔處理技術、標準和研究計劃。接下來我們梳理一下試圖解決這些問題的現有想法。
語義網。語義網指的是眾多相互聯系的研究和標準化工作，就像當下一些有關標記和知識表示技術的想法。最核心的當屬W3C的資源描述框架，當然也包括其他的技術，比如ISO的主題圖技術。語義網的范圍很廣，目標宏大，旨在利用通用知識表示技術來完善標記語言，從而“促進人類知識的全面發展”。語義網的研究和標準化不同于當下的想法：不是對特定領域進行語義描述，而是實現對所有領域的知識進行語義標注。當前研究的目標特別盯在“文檔標記語義”上，而非“通用的語義標記”。語義網技術的進步會讓我們利用語義網標記語言對標記的語義進行編碼成為可能。
W3C的文檔對象模型。文檔對象模型是一個應用程序接口，是對XML文檔進行分析后生成的層級式數據結構。人們想設計能為標記語義提供各種接口的系統，類似于DOM所提供的標記語法相關的形式，最終能夠形成“語義DOM”，對W3C的語法DOM形成補充。
W3C的Schema。XML Schema是一門基于XML的語言，能夠替代傳統的DTDs，用于約束XML文檔。DTDs的局限性推動了這門語言的發展，這些局限同我們在BECHAMEL計劃中面對的問題是類似的。Schema允許文檔類設計師定義復雜的數據類型，就像在高級程序語言里面的做法一樣。但是，為了對標簽集建檔中的所有關系和約束進行編碼，我們還需要比當下的XML Schema更強大的表達形式。超媒體／時基結構語言（Hypermedia/Time based Structuring Language，HyTime）的架構形式。適應性廣泛的架構技術來自于這樣一種認識，即不同的標記語言應用程序常常通過樣式各不相同但語義上等價的結構進行編碼。架構形式允許文檔類設計師將其自有的特定元素實例映射到更通用的各種架構實例上，這些架構實例更便于在不同的應用程序之間進行映射。這些映射的確表示了語義知識的約束形式，有利于解決上述轉換和集成上的挑戰。BECHAMEL計劃在某種程度上就是要建立一個比架構形式表達更多語義關系的模型。

以上是“XML標記語義的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！