XSD 允许同一元素同时包含 simpleType 和 complexType 内容?
XSD allowing both simpleType and complexType content for same element?
我遇到的情况是,我有不同的 XML,这些 XML 具有不同类型的属性。有时,元素 HEADER
可能只有一个节点,或者某些 XML 可能在 HEADER
节点内包含元素,并在其中包含值。
示例 1(HEADER
只有文本):
<Details HeaderLabel="DETAILS">
<HEADER Label="Header">2.5%</HEADER>
</Details>
示例 2(HEADER
有两个子元素):
<Details HeaderLabel="DETAILS">
<HEADER Label="Header">
<HEAD Label="H1a">2.88%</HEAD>
<HEAD Label="H2b">3.24%</HEAD>
</HEADER>
</Details>
XSD 是这样工作的:
这将验证 示例 1:
<xs:element name="HEADER">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
这将验证 示例 2:
<xs:element name="HEADER">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="HEAD">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
我尝试使用 xs:choice
但它似乎效果不佳,或者我对如何在这种情况下实施选择没有清楚的了解。
在 XSD 中,您不能同时允许简单内容和复杂内容,除非您愿意通过 mixed="true"
混合元素和文本(在这种情况下不需要示例 1)。您 可以 然后使用 XSD 1.1 断言来排除两者同时出现。
<xs:element name="HEADER">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="HEAD">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
然而,你在这里逆水行舟。相反,接受您确实有两个不同的实体和两个不同的内容模型,并以不同的方式命名不同的实体:想到 SIMPLE_HEADER
和 COMPLEX_HEADER
。然后可以在Details
上使用xs:choice/maxOccurs="unbounded"
,让简单和复杂的header可以自由穿插。
如果实例已经存在,并且您无法更改它们,并且您正在尝试编写一个 XSD 模式来描述它们,并且它必须是一个描述所有它们的模式,那么您的选择非常有限。据我所知,唯一的解决方案是用混合内容定义 HEADER —— 这是一个糟糕的解决方案。通过使用 XSD 1.1 断言可以稍微改进(虽然不多)。
如果您可以删除任何这些要求(例如,如果您可以更改实例文档,或者如果您可以使用 RelaxNG 进行验证,或者如果您可以为每种文档类型使用不同的架构),那么您就拥有了有机会得到更令人满意的解决方案。
我遇到的情况是,我有不同的 XML,这些 XML 具有不同类型的属性。有时,元素 HEADER
可能只有一个节点,或者某些 XML 可能在 HEADER
节点内包含元素,并在其中包含值。
示例 1(HEADER
只有文本):
<Details HeaderLabel="DETAILS">
<HEADER Label="Header">2.5%</HEADER>
</Details>
示例 2(HEADER
有两个子元素):
<Details HeaderLabel="DETAILS">
<HEADER Label="Header">
<HEAD Label="H1a">2.88%</HEAD>
<HEAD Label="H2b">3.24%</HEAD>
</HEADER>
</Details>
XSD 是这样工作的: 这将验证 示例 1:
<xs:element name="HEADER">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
这将验证 示例 2:
<xs:element name="HEADER">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="HEAD">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
我尝试使用 xs:choice
但它似乎效果不佳,或者我对如何在这种情况下实施选择没有清楚的了解。
在 XSD 中,您不能同时允许简单内容和复杂内容,除非您愿意通过 mixed="true"
混合元素和文本(在这种情况下不需要示例 1)。您 可以 然后使用 XSD 1.1 断言来排除两者同时出现。
<xs:element name="HEADER">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="HEAD">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="Label" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
然而,你在这里逆水行舟。相反,接受您确实有两个不同的实体和两个不同的内容模型,并以不同的方式命名不同的实体:想到 SIMPLE_HEADER
和 COMPLEX_HEADER
。然后可以在Details
上使用xs:choice/maxOccurs="unbounded"
,让简单和复杂的header可以自由穿插。
如果实例已经存在,并且您无法更改它们,并且您正在尝试编写一个 XSD 模式来描述它们,并且它必须是一个描述所有它们的模式,那么您的选择非常有限。据我所知,唯一的解决方案是用混合内容定义 HEADER —— 这是一个糟糕的解决方案。通过使用 XSD 1.1 断言可以稍微改进(虽然不多)。
如果您可以删除任何这些要求(例如,如果您可以更改实例文档,或者如果您可以使用 RelaxNG 进行验证,或者如果您可以为每种文档类型使用不同的架构),那么您就拥有了有机会得到更令人满意的解决方案。