如何编写模式(XSD1.0)来验证具有不同内容的同名元素? (有可能吗?初步调查似乎表明这违反了“元素声明一致性”,但我可能错了。)
下面的片段说明了我的需要 - 基本上,我可以出现“ParentTag”(它深深地嵌套在我的文档中),它可以包含下面3种变体中定义的任何内容。我应该注意,“ParentTag”只在祖先元素下看到一次,因此在树的特定分支中只遇到一个变体。
我是XML的使用者,而不是生成器,并且无法更改源XML。似乎我想做一些类似于“选择”(或者可能是“联合”?)的事情,但这个定义让我望而却步。
作为一个后备(丑陋的kludge),似乎我能够做的最好的事情是使用'any'然后依靠我消耗的应用程序代码(我控制)来“完成”验证,因为它解析XML。
变式1:
<ParentTag>
<!-- '<value>' can repeat -->
<value>some value</value> <!--(type="xsd:string" minOccurs="1" maxOccurs="unbounded")-->
</ParentTag>
变式2:
<ParentTag>
<!-- Note: order of subelements not guaranteed: 'all', not 'sequence' -->
<minValue>v1</minValue> <!--(type="xsd:int" minOccurs="1" maxOccurs="1")-->
<maxValue>v2</maxValue> <!--(type="xsd:int" minOccurs="1" maxOccurs="1")-->
</ParentTag>
变式3:
<ParentTag>
<specialValue>special value</specialValue> <!--(type="xsd:string" minOccurs="1" maxOccurs="1")-->
</ParentTag>
答案 0 :(得分:0)
不,在XSD 1.0中,拥有不同的内容模型需要不同的元素名称 1 。这不是一个繁重的要求,因为同名真的应该暗示同一性。
XSD 1.1允许类型根据属性值(Conditional Type Assignment)而变化。 XSD 1.1也有断言,它提供了额外的类型规范灵活性。
鉴于你已经说过你坚持使用这种(糟糕的)XML设计,你的选择是有限的,并且不满意。如果您不想使用xsd:any
路由,则可以使用xs:choice
并以此方式指定每个可能的内容模型。
<子> 1。例外:通过名称空间区分的相同本地名称或通过分层遗产区分的相同名称(如Michael Kay mentions)可以具有不同的内容模型。
答案 1 :(得分:0)
你说&#34;在树的特定分支中只遇到一个变体。&#34;
如果不同类型的ParentTag出现在不同的上下文中,则可以为ParentTag提供不同的内容模型。例如:
<xs:element name="Customer">
<xs:complexType>
<xs:sequence>
<xs:element name="Address">
<xs:complexType>
<xs:element name="Street" type="xs:string"/>
<xs:element name="City" type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Supplier">
<xs:complexType>
<xs:sequence>
<xs:element name="Address">
<xs:complexType>
<xs:element name="Road" type="xs:string"/>
<xs:element name="Town" type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
因此,供应商地址与客户地址完全不同。
通常区别比这更微妙:例如,在XPath 3.1规范中JSON的XML表示的模式中,<array>
中包含的<map>
与内容模型略有不同<array>
出现在其他任何地方。