符合中小企业对网站设计、功能常规化式的企业展示型网站建设
本套餐主要针对企业品牌型网站、中高端设计、前端互动体验...
商城网站建设因基本功能的需求不同费用上面也有很大的差别...
手机微信网站开发、微信官网、微信商城网站...
这篇文章主要为大家展示了“XML标记语义的示例分析”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“XML标记语义的示例分析”这篇文章吧。
创新互联建站自2013年起,先为利通等服务建站,利通等地企业,进行企业商务咨询服务。为利通企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
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说明书中,供应商随意地把程序性标记(如
参考如下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标记语义的示例分析”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注创新互联行业资讯频道!