这篇文章主要为大家展示了“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标记语义的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注云行业资讯频道！