XSD定义任意数量无序同名子元素的实现方案（含基数约束）

你对原有实现的判断是对的，嵌套仅含单个元素的xs:choice属于语义矛盾的冗余写法，而且你对xs:sequence的顺序约束存在认知误区：xs:sequence的顺序约束仅针对不同名称/类型的子元素，当子元素全为同名的component时，不存在顺序限制的问题。

符合要求的最简实现 #

<xs:element name="componentDefinitions">
   <xs:complexType>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
         <xs:element name="component">
            <xs:complexType>
               <xs:attribute name="id" type="xs:string" use="required" />
            </xs:complexType>
         </xs:element>
      </xs:sequence>
   </xs:complexType>
</xs:element>

约束匹配说明 #

这个写法完全覆盖你提的所有规则：

• 全局仅定义了一个componentDefinitions元素声明，自然满足“仅存在一个节点块”的根节点约束
• xs:sequence设置minOccurs="0"，支持componentDefinitions为空（不包含任何子节点）的场景；maxOccurs="unbounded"支持包含任意数量的component子元素
• 由于所有子元素都是同名的component节点，xs:sequence不会产生任何顺序校验限制——不管你怎么排列这些component节点，都能通过校验，完全满足“子元素可按任意顺序出现”的要求。

常见误区澄清 #

很多人对XSD的三个组合节点的适用场景理解有偏差：

• xs:choice的语义是“从多个不同子选项中选择一个”，仅包含单个子元素时使用xs:choice完全不符合语义设计，虽然部分解析器可能兼容，但可读性和规范性都很差
• xs:all的设计目标是支持不同类型子元素各出现0/1次、顺序任意的场景，XSD 1.0规范下它本身就不支持子元素设置maxOccurs="unbounded"，你的需求场景本来就不适合用xs:all
• 当子元素为单一类型、需要支持多实例时，直接使用xs:sequence是最符合规范的写法，不存在多余的顺序限制。

内容的提问来源于stack exchange，提问作者1um0