在设计XMLSchema时，遵循一些约定和建议可以帮助创建更加清晰、易于维护的文档结构。本文将介绍元素与属性的使用时机、混合内容的处理、命名约定以及版本控制的策略。
在XML中，元素（Element）和属性（Attribute）的使用常常让人感到困惑。一些人认为元素用于描述数据，而属性用于描述元数据。另一种看法是属性用于存储小数据片段，如订单ID。但事实上，何时使用属性往往取决于个人偏好。通常，如果信息看起来像是数据，最好使用子元素。使用属性可能会遇到以下问题：
如果使用属性作为数据的容器，最终得到的文档将难以阅读和维护。因此，建议使用元素来描述数据。元数据（关于数据的数据）应该存储为属性，而数据本身应该存储为元素。
混合内容（Mixed Content）应该尽可能避免使用。虽然在Web上以XHTML的形式广泛使用，但它有许多限制。混合内容难以解析，并且可能导致数据结果的复杂性增加。XML数据绑定与之相关的限制使得操作这类文档变得困难。
所有元素和属性应使用UCC驼峰命名法，例如（PostalAddress），避免使用连字符、空格或其他语法。
可读性比标签长度更重要。在文档大小和可读性之间总是需要权衡，尽可能优先考虑可读性。
尽量避免缩写和首字母缩写用于元素、属性和类型名称。例外情况应该是在业务领域内众所周知的，例如，ID（标识符）和POS（销售点）。
为新类型后缀添加“Type”，例如，AddressType，USAddressType。
枚举应使用名称而不是数字，并且值应使用UCC驼峰命名法。
名称不应包含包含结构的名称，例如，CustomerName 应为 Name 在子元素 Customer 内。
只为可能被重用的类型产生复杂类型（complexTypes）或简单类型（simpleTypes）。如果结构仅在一个地方存在，应定义为匿名复杂类型。
避免使用混合内容。
只有在元素能够成为XML文档的根元素时，才定义根级别元素。
使用一致的命名空间别名：
在设计模式的早期阶段就考虑版本控制。如果新版本的模式需要向后兼容，那么模式的所有添加都应该是可选的。如果现有产品能够读取给定文档的新版本很重要，那么考虑在定义的末尾添加any和anyAttribute条目。
在模式中定义一个targetNamespace。这更好地标识了模式，并可以使模块化和重用变得更容易。
在模式元素中设置elementFormDefault="qualified"。这使得在结果XML中限定命名空间更简单（如果不是更冗长的话）。
以下是一个简单的XML Schema示例，展示了如何定义元素和属性：
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Customer">
<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Address" type="AddressType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="AddressType">
<xs:sequence>
<xs:element name="Street" type="xs:string"/>
<xs:element name="City" type="xs:string"/>
<xs:element name="PostalCode" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>