设计XML模式的最佳实践是什么？

Question

作为业余软件开发人员(我还在学术界),我为XML文档编写了一些模式.我经常遇到导致丑陋的XML文档的设计漏洞,因为我不完全确定XML的语义究竟是什么.

我的假设:

<property> value </property>

property = value

<property attribute="attval"> value </property>

具有特殊描述符的属性,属性.

<parent>
  <child> value </child>
</parent>

父母有一个特征"孩子",其价值"值".

<tag />

"标签"是一个标志或直接转换为文本.我不确定这个.

<parent>
  <child />
</parent>

"孩子"描述"父母"."child"是一个标志或布尔值.我也不确定这个.

如果你想做一些代表笛卡尔坐标的事情,就会出现歧义:

<coordinate x="0" y="1 />

<coordinate> 0,1 </coordinate>

<coordinate> <x> 0 </x> <y> 1 </y> </coordinate>

哪一个最正确？基于我目前对XML模式设计的概念,我倾向于第三种,但我真的不知道.

有哪些资源简洁地描述了如何有效地设计xml架构？

Answer 1

一般(但重要的!)建议永远不要在单个节点(无论是文本节点还是属性节点)中存储多个逻辑数据片段.否则,您最终需要在您通常从框架中免费获得的XML解析逻辑之上使用自己的解析逻辑.

因此,在你的坐标例如, <coordinate x="0" y="1" /> 并且 <coordinate> <x>0</x> <y>1</y> </coordinate> 都是合理的,我.

但是<coordinate> 0,1 </coordinate>不是很好,因为它在一个XML节点中存储两个逻辑数据片段(X坐标和Y坐标) - 迫使消费者解析XML解析器之外的数据.虽然用逗号分割字符串非常简单,但仍然存在一些含糊之处,比如如果最后有一个额外的逗号会发生什么.

Answer 2

查看教程:

• Roger Costello的 " XML Schemas:Best Practices " .

我还建议:

• Priscilla Walmsley的书" Definitive XML Schema ".

• Jeni Tennison的 XML Schema页面

Answer 3

我同意下面的cdragon建议,以避免选项#2.#1和#3之间的选择很大程度上取决于风格.我喜欢将属性用于我认为是实体的属性,以及我认为是数据的元素.有时,很难分类.尽管如此,两者都不是"错误的".

虽然我们正在讨论模式设计的主题,但我会在我的首选(最大)重用(元素和类型)中加上我的两分钱,这也可以促进这些实体的外部"逻辑"引用,比如说,存储在数据库中的数据字典.

请注意,虽然"伊甸园"模式模式提供了最大程度的重用,但它也涉及最多的工作.在这篇文章的底部,我提供了博客系列中涵盖的其他模式的链接.

• 伊甸园的方法 http://blogs.msdn.com/skaufman/archive/2005/05/10/416269.aspx

通过全局定义所有元素来使用模块化方法,并且像Venetian Blind方法一样,所有类型定义都是全局声明的.每个元素全局定义为节点的直接子节点,其type属性可以设置为指定的复杂类型之一.

<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema targetNamespace="TargetNamespace" xmlns:TN="TargetNamespace" 
  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified" attributeFormDefault="unqualified"/> 
<xs:element name="BookInformation" type="BookInformationType"/> 
  <xs:complexType name="BookInformationType"/> 
    <xs:sequence> 
      <xs:element ref="Title"/> 
      <xs:element ref="ISBN"/> 
      <xs:element ref="Publisher"/> 
      <xs:element ref="PeopleInvolved" maxOccurs="unbounded"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:complexType name="PeopleInvolvedType"> 
    <xs:sequence> 
      <xs:element name="Author"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:element name="Title"/> 
  <xs:element name="ISBN"/> 
  <xs:element name="Publisher"/> 
  <xs:element name="PeopleInvolved" type="PeopleInvolvedType"/> 
</xs:schema>

这种方法的优点是模式是可重用的.由于元素和类型都是全局定义的,因此两者都可以重用.此方法提供最大量的可重用内容.缺点是模式很冗长.当您创建通用库时,这将是一个合适的设计,您可以在其中对架构元素和类型的范围及其在其他架构中的使用做出任何假设,特别是在引用可扩展性和模块性方面.

由于每个不同的类型和元素都具有单个全局定义,因此这些规范粒子/组件可以与数据库中的标识符一对一关联.虽然它可能乍一看似乎是一个令人厌倦的持续手动任务来维护文本XSD粒子/组件与数据库之间的关联,但SQL Server 2005实际上可以通过语句生成规范的模式组件标识符

CREATE XML SCHEMA COLLECTION

http://technet.microsoft.com/en-us/library/ms179457.aspx

相反,要从规范粒子构造模式,SQL Server 2005提供了

SELECT xml_schema_namespace function

http://technet.microsoft.com/en-us/library/ms191170.aspx

ca·non·i·cal与数学有关.(方程式,坐标等)"最简单或标准形式" http://dictionary.reference.com/browse/canonical

其他的,更容易构造,但更少的可恢复/更"非规范化/冗余"的模式模式包括

• 俄罗斯娃娃方法http://blogs.msdn.com/skaufman/archive/2005/04/21/410486.aspx

模式只有一个全局元素 - 根元素.所有其他元素和类型逐渐深入嵌套,因为每个类型都适合上面的类型,因此给它起名称.由于此设计中的元素是在本地声明的,因此它们不能通过import或include语句重用.

• Salami Slice方法 http://blogs.msdn.com/skaufman/archive/2005/04/25/411809.aspx

所有元素都是全局定义的,但类型定义是在本地定义的.这样,其他模式可以重用这些元素.使用此方法,具有本地定义类型的全局元素提供元素内容的完整描述.此信息"切片"是单独声明的,然后聚合在一起,也可以拼凑在一起构建其他模式.

• 威尼斯盲人方法 http://blogs.msdn.com/skaufman/archive/2005/04/29/413491.aspx

与俄罗斯玩偶方法类似,它们都使用单一的全局元素.Venetian Blind方法通过全局命名和定义所有类型定义来描述模块化方法(与Salami Slice方法相反,该方法在全局声明元素并在本地类型化).每个全局定义的类型描述单个"板条",并且可以由其他组件重用.此外,所有本地声明的元素都可以是命名空间限定或命名空间不合格(板条可以"打开"或"关闭"),具体取决于模式顶部的elementFormDefault属性设置.