xml元素 xml属性_当XML元素的顺序重要时

最新推荐文章于 2022-03-25 22:37:27 发布

cuyi7076

最新推荐文章于 2022-03-25 22:37:27 发布

阅读量1.5k

点赞数

文章标签： python java 数据库编程语言大数据

原文链接：https://www.ibm.com/developerworks/xml/library/x-eleord/index.html

版权

xml元素 xml属性

在本系列的XML设计原理中，我已经展示了如何命名和组织XML元素。我尚未涉及的一个微妙但重要的考虑因素是是否为XML元素的子元素顺序赋予重要性。例如，您是否看到清单1和清单2中的文档相同？

清单1.一个示例XML文档

<?xml version='1.0' encoding='utf-8'?>
<memo>
  <title>
      With Usura Hath no Man a House of Good Stone
  </title>
  <date>2005-04-15</date>
  <from>Ezra Pound</from>
  <to>Employees</to>
  <body>It appears the art world requires a reminder 
of the fact that the best  art is created for the 
enjoyment of the first buyer, and not as mere 
investment.  As I've said before, none of the work 
of Duccio, Piero Della Francesca, Pietro Lombardo, 
Fra Angelico, Zuan Bellini or such others would have 
been of any value if guided by usurious motives.
  </body>
</memo>

清单2.具有不同元素顺序的示例XML文档

<?xml version='1.0' encoding='utf-8'?>
<memo>
  <date>2005-04-15</date>
  <to>Employees</to>
  <title>
      With Usura Hath no Man a House of Good Stone
  </title>
  <body>It appears the art world requires a reminder 
of the fact that the best  art is created for the 
enjoyment of the first buyer, and not as  mere 
investment.  As I've said before, none of the work 
of Duccio, Piero Della Francesca, Pietro Lombardo, 
Fra Angelico, Zuan Bellini or such others would have 
been of any value if guided by usurious motives.
  </body>
  <from>Ezra Pound</from>
</memo>

这些文档之间的唯一区别是memo元素的子项出现的顺序。所有这些元素都是集体同级，并且本文完全关注同级元素顺序的重要性。请注意，某些讨论也将与您将文本，注释和处理说明作为元素的同级相关，但是此讨论仅关注元素。

规格中的律师

首先要意识到的，也许会让您感到惊讶的是，XML 1.0规范本身不保证格式正确的部分中的元素顺序（有关有效性的部分与本文稍后的讨论更相关）。 XML 1.0格式正确的定义专门声明属性是无序的，但对元素没有任何说明。这意味着从技术上来讲，一个合格的XML解析器可以决定以任何顺序报告清单1中memo的子元素。您可能希望按照它们在实际XML文本中出现的顺序（在这种情况下，与所谓的document order相同 ）进行报告：

title
date
from
to
body

但是，XML解析器实际上可以自由地按字母顺序报告它们：

body
date
from
title
to

我知道没有一个XML解析器不会按文档顺序报告同级元素，仅出于以下实际原因：报告在解析时遇到的XML文档部分是最简单，最有效的。但是，意识到这种奇怪的安排对您来说是一件好事。我将术语“ 解析顺序”用于解析器报告元素的顺序。如您所见，元素顺序至少还有一个重要方面。

综上所述，我承认几乎没有人完全隔离地使用XML 1.0。人们通常使用基于 XML的技术。这些技术中的大多数确实为元素指定了一些排序规则，并且所施加的顺序几乎是通用的文档顺序。 XML信息集（信息集-请参阅相关信息），由W3C定义的核心XML数据模型，刻画元素孩子为：

子信息项的有序列表，按文档顺序 。该列表包含元素，处理指令，未扩展的实体引用，字符和注释信息项，每个元素一个，处理指令，对未处理的外部实体的引用，数据字符和立即出现在当前元素中的注释。如果元素为空，则此列表没有成员。

我用黑体字强调了关键部分。许多通用XML处理规范（例如Canonical XML）都从InfoSet派生而来，因此继承了此规则以用于同级顺序。其他诸如XPath（以及XSLT）和DOM定义了自己的数据模型，它们具有类似的兄弟规则。

元素顺序的架构约束

在设计XML词汇表时，您可以更精确地了解有效文档中允许的同级顺序规则。例如，如果您为清单1中的备忘录文档编写了RELAX NG模式，则可以使用清单3中的模式（采用RELAX NG紧凑语法）。兄弟元素子模式之间的逗号表示要求它们以给定顺序出现。

清单3.具有有序子元素的元素的RELAX NG模式

element memo {
  element title { text },
  element date { text },
  element from { text },
  element to { text },
  element body { text }
}

清单1在此模式下有效，但清单2无效。

清单4是类似的模式，但没有强制任何顺序。兄弟元素子模式之间的＆字符表示可以接受任何顺序。

清单4.带有未排序子元素的元素的RELAX NG模式

element memo {
  element title { text } &
  element date { text } &
  element from { text } &
  element to { text } &
  element body { text }
}

清单1和清单2都对此模式有效。

决定| 决定

问题是：什么时候使用逗号，什么时候使用管道？我称这种模式为模式顺序 ，可以是有序的也可以是无序的。对于元素架构顺序，我的主要经验法则是： 除非有特殊原因，否则请使用有序模式 。制定此规定的原因实际上有点哲学性，但是它们来自XML设计的经验，并观察了两种情况的影响。最后，我认为已经充分证明最好不要给用户和下游系统不必要的选择。如果您不下订单，那么他们通常必须提出一个订单，这会带来一些混乱的空间。

这个职位的一个问题是，它有点违反Postel的定律-“对所做的事情要保守，对别人接受的事情要放心”-这表明您应该对自己使用的命令有指导原则您控制的文档中的样式，但您不要太急于拒绝使用不同顺序的文档。遵守这一原则可能是不遵循我上面的规定的原因之一，尤其是如果您要处理的大多数文档不会由您控制下的人员或系统创建或修改。

订单的信息价值

要记住的一个重要区别是，如果选择有序模式，则解析顺序不会提供任何有用的信息，而如果您选择无序模式，则解析顺序可能会提供有用的信息。举例来说，如果使用清单3中的模式，您将始终知道元素在有效文档中的显示顺序，而如果您使用清单4中的模式，则可以使用该顺序告诉应用程序有关元素的信息。

假设您有一个应用程序，该应用程序使用清单4中的模式存储许多备忘录文档，并且其中包括针对它们的搜索引擎。搜索引擎应用程序可能会返回结果文档，以便用户搜索时始终首先显示该字段。因此，如果用户搜索标题中带有“ Usura”的所有文档，那么结果之一将是清单1中的文档（其中title元素是第一个同级）。如果用户搜索了所有日期为“ 2005-04-15”的文档，则结果之一将是清单2中的文档（其中date元素为第一个同级）。两者在此应用程序中都代表相同的备忘录实例，但是元素的顺序现在传达了有关该文档的一些有意义的信息，特别是用于检索该文档的搜索条件的形式。元素顺序因此成为有用的元数据。如果您认为将使用此类约定，则将要使用无序模式。

处理注意事项（以及文档与数据）

XML的某些使用更多地与数据库管理有关，而与文档和散文无关。有时称为面向记录的XML。在这种XML中，到处都使用有序模式可能是个问题。例如，如果您在应用程序域中管理哈希表中的数据或其他无序数据结构，则可能会面临将元素重新组装为模式设置的顺序的其他工作。在面向记录的XML中，除非有特殊原因（例如，在应用程序域模型中已指定特定顺序时），否则您应该使用无序模式。清单5是一个面向记录的XML的示例。

清单5.面向记录的XML的示例

<label>
    <occupation>Poet</occupation>
    <name>Ezra Pound</name>
    <address>
      <street>45 Usura Place</street>
      <city>Hailey</city>
      <state>ID</state>
    </address>
  </label>

在此示例中，您不需要在occupation ， name和address元素之间进行相对排序。但是，如果您定义了严格的命令，则处理软件将必须对此进行跟踪。例如，您不能只是按照通常的任意顺序从关系数据中提取信息并将其直接放入输出文档中。您将必须在应用程序中构建模式顺序信息，否则是不必要的。但是，应用程序本身可能会在street ， city和state之间定义有意义的顺序，因此，如果在模式中强制执行此顺序，则不会造成其他干扰。

另一方面，如果使用W3C XML架构（WXS），则可能会遇到由于语言限制而无法表达的几种无序模式。这些限制中的大多数不适用于RELAX NG，但是，如果您选择的模式语言是WXS，则无论您的词汇表是否面向记录，默认情况下，都要求默认顺序是确保WXS友好性的最简单方法。

结语

如果您一直在关注本系列，那么您可能已经意识到，实际上在XML中很少有设计注意事项。在决定信息顺序在模式中是否重要以及应用程序将如何处理有效的实例文档之前，请考虑XML的性质以及任一决定的含义。这样的含义可能很微妙，但是却可能产生令人惊讶的深远影响。

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