xml 名称空间_谨慎使用XML名称空间

xml 名称空间

XML的大多数常规用户都非常熟悉XML名称空间,并接受它们作为XML的基本组成部分。 他们偶尔对名称空间感到陌生,但通常不会给他们太多思考。 但是,在XML专家中,XML名称空间从一开始就引起了很大争议。 引起争议的原因是充分的:命名空间解决了一个难题,并且是解决此问题的许多方法之一,每种方法各有利弊。 W3C XML名称空间规范是一个折衷,与所有折衷一样,它经常无法满足每个用户的需求。 即使经过了这么长时间,事实证明,很难将命名空间平稳地整合到XML信息体系结构中,并且对命名空间的疏忽会给XML处理工具带来很多麻烦。 在本文中,我将介绍设计注意事项,这些注意事项可以帮助您避免在使用XML名称空间时出现此类问题。 通常,我建议的指南将以黑体显示。

本文将介绍XML名称空间1.0(包括所有勘误)。 XML名称空间1.1的更改非常适度,但是它是一个全新的规范,尚未得到工具的很好支持。 我希望XML名称空间1.1很快会成为规范(与XML 1.1不同,我不确定XML 1.1是否会真正流行)。

基本原则

XML名称空间的机制有几个移动部分:本地名称,名称空间URI,前缀和声明。 有效使用命名空间的最重要步骤是学习如何保持命名空间的一致性。

本地名称

命名空间的要点是,您可以为每个上下文中的每个元素或属性使用最佳的简洁名称,然后将这些名称放在区分上下文的命名空间中。 名称的简洁部分仅需要在其自身的上下文中是唯一的,即本地名称 。 确保利用可区分的上下文,并且不要在本地名称中重复名称空间本身已经固有的信息 。 例如,您无需在XHTML命名空间xhtml-link中设置链接元素的本地名称。 由于它已经在XHTML名称空间中本地存在,因此只需要link 。 由于历史原因,XHTML规范本身在命名根元素html时违反了该准则。 也可以将其重命名为document

命名空间URI

名称空间是具有URI语法(通常多余地称为“名称空间URI”)的字符串。 命名空间是元素名称或属性名称的组成部分。 本地名称和名称空间的组合称为通用名称 。 为了强调名称空间的重要性,XML先驱James Clark开发了通用名称的表示法,该符号强调了从根本上如何绑定名称空间和本地名称(请参阅参考资料 )。 例如,具有本地零件customer和命名空间http://uche.ogbuji.net/eg/ns的通用名称以Clark的{http://uche.ogbuji.net/eg/ns}customer书写。

选择名称空间URI很重要。 争论的根源是使用URL还是使用URN。 前者具有熟悉的优点,但是人们通常会创建没有任何相应资源的名称空间URL,也就是说,如果浏览到等效URL,则会出现404“未找到”错误。 URN的优点是它们不鼓励人们尝试在浏览器中查找它们。 如果您小心地在URL上放置一些对读者有用的文档,请使用URL作为名称空间。 我建议放置RDDL 1.0文档(请参阅相关主题的URL)的对应的命名空间,除非有更多的专业约定适用。 例如,在RDF / XML文档中,名称空间在解析为URL时通常会导致RDF模式文档。 URN具有许多类(URN的类正式称为“命名空间”,不要与XML命名空间混淆)。 如果您不希望使用URL, 则在您的组织可以管理和解决合适的URN类的情况下,请使用URN 。 URN名称空间的示例包括oid (ISO认可的系统,用于将数字编码的标识符分配给网络节点)和publicid (如SGML和XML中定义的正式公共标识符实体)。

前缀

在XML文档中指定通用名称时,您可以使用基于附加到本地名称的可选前缀的缩写。 此缩写称为限定名称qname 。 前缀是可选的,因为特殊的语法形式使您可以指定与没有前缀的qname关联的默认名称空间 。 前缀严格来说是语法上的方便; 通常,这实际上不是XML语言设计的问题,而是作者或工具偏好的问题。 我称这类问题为实例的详细信息,而我仅在设计人员根据经验无法选择时才在设计方面的文章中进行介绍。 我建议您发布名称空间的众所周知的前缀,但不要使任何前缀成为必需。 创建文档时为名称空间选择众所周知的前缀,在阅读文档时接受名称空间的任何选定前缀

命名空间声明

名称空间声明是一种语法设备,通过它可以将前缀分配给XML文档中的名称空间。 从技术上讲,这是一个实例详细信息,但重要的是,我专门将一节(请参阅下文 )用于命名空间声明的准则。

命名空间的使用和演变

一些设计师开始不使用名称空间,后来又采用名称空间,因为他们觉得需要混合词汇。 考虑到命名空间的复杂性,这种谨慎的方法似乎是明智的。 问题在于,由于名称空间是XML名称的基本组成部分,因此此更改比您可能意识到的要重要得多。 它要求对工具和其他相关材料进行大量更改。 您可以通过其他方式处理名称冲突。 除名称空间外,主要方法是基于SGML 体系结构形式的思想,其中,在发生冲突的情况下,名称可以通过工具直接声明和修改。 尝试尽可能多地考虑XML设计的未来发展,并决定是否处理名称冲突以及如何处理。 我已经同意了对XML名称空间的许多批评,并非常希望有一种在工具中已建立的更清洁的机制。 出于实际经验,基于我的经验,这些天来,我几乎在所有XML设计中都使用了名称空间。

决定何时演化或区分名称空间也很困难。 命名空间可用于版本控制或区分域中的概念。 最好决定何时执行此操作的关键是记住名称空间是名称的基本组成部分。 仅当您要进行定义每个元素和属性的真实的基本区别时,才更改或区分名称空间。 如果版本更改极大地改变了XML词汇表中名称的含义,则名称空间更改可能是有序的。 否则,请使用其他版本控制机制,例如将version属性添加到顶级元素。

通过示例可以很好地说明使用名称空间在域内进行区分的陷阱。 XHTML 1.0在1999年成为最终定案。 它实际上只是HTML 4.01上的XML变体,它具有三个独立的DTD:严格,过渡和框架集。 XHTML工作组决定为相应的XHTML DTD使用三个单独的命名空间。 这个决定在XML社区引起了轩然大波。 主要问题是,即使存在三个单独的DTD,每个元素的含义也不会从一个到另一个显着变化。 XHTML过渡DTD中的code元素实质上与XHTML严格DTD中的code元素具有相同的含义。 通过在每种情况下更改名称,XHTML设计正与这一事实背道而驰。 最后,XHTML工作组通过发布在XHTML 1.0域中使用单个名称空间的新规范来纠正了问题。 您应该认真听好这一课。 仅当命名的事物之间确实存在区别时,才在XML名称空间中进行区别。

不幸的是,事情很少是黑白的。 常见的情况是,新版本的词汇表增加了新元素。 残留元素的含义可能没有更改,因此名称空间更改似乎不合适。 但是,如果使用相同的旧命名空间,将添加在新词汇表中的元素放置在原始命名空间中似乎也不合适。 仅对新元素使用不同的名称空间很少是明智的选择。 最后,您必须根据自己的判断来决定是否使用词汇表来扩展命名空间。 与命名空间的一些技巧,可以给你其他的选择(参见相关主题有关使用命名空间的版本小费),但你应该甚至这些谨慎使用。

命名空间完整性的Joe英语隐喻

XML名称空间声明是有作用域的 ,这意味着声明发生的元素(及其后代元素)对声明的前缀(或默认名称空间)有效,除非另一个名称空间声明覆盖了它。 但是,这种灵活性可能会导致一些处理问题。 乔英,一个XML专家,先进的旋翼机科技公司工作,著名的解释使用精神健康的比喻,我复制以下(看到这些问题相关主题的原创文章)。 以下是我建议避免使用的命名空间使用模式。

边界文档(可能是对边界人格障碍的引用)中,多个前缀映射到一个名称空间:

<org>
  <a:employee xmlns:a='urn:bogus:ns'>EP</a:employee>
  <b:employee xmlns:b='urn:bogus:ns'>TSE</b:employee>
</org>

神经质文档中,相同的前缀用于多个名称空间:

<h:memo xmlns:a='urn:bogus:ns'>
  <h:body xmlns:a='http://www.w3.org/1999/xhtml'>
    Now hear <h:i>this</h:i>
  </h:body>
</h:memo>

以我的经验,这种模式是最常见的,在这种情况下,作者会尽力避免出现前缀。 请看下面的例子,这很神经质,因为默认名称空间根据您在文档中的位置而有所不同:

<memo xmlns='urn:bogus:ns'>
  <body xmlns='http://www.w3.org/1999/xhtml'>
    Now hear <i>this</i>
  </body>
</memo>

精神病性文档中,为同一作用域中的同一作用域声明了两个不同的前缀:

<org xmlns:a='urn:bogus:ns' xmlns:b='urn:bogus:ns'>
  <a:employee>EP</a:employee>
  <b:employee>TSE</b:employee>
</org>

如果所有名称空间声明都在根元素上,并且没有为同一名称空间声明两个前缀,则文档采用名称空间普通格式:

<memo xmlns='urn:bogus:ns' xmlns:html='http://www.w3.org/1999/xhtml'>
  <html:body>
    Now hear <html:i>this</html:i>
  </html:body>
</memo>

避免使用边缘性,神经质和精神病性文件。 尽量使用名称空间普通格式的文档,因为它们最易于阅读和处理。

结语

XML名称空间从表面上看很简单,但是如果您在使用它们时不注意,它们的细微差别就会带来真正的复杂性和笨拙的危险。 透彻理解构成XML名称空间机制的各种概念的含义,规则和含义,并在使用名称空间设计词汇表并创建实际的实例文档时始终坚持简单的约定。


翻译自: https://www.ibm.com/developerworks/xml/library/x-namcar/index.html

xml 名称空间

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值