我在架构中有以下内容:
<xs:element name="td">
<xs:complexType>
<xs:complexContent>
<xs:extension base="cell.type"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="cell.type" mixed="true">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element ref="p"/>
</xs:sequence>
</xs:complexType>
一些解析器允许PCDATA直接在元素中,而其他解析器则不允许。 XSD建议(3.4.2)中有一些内容表明当复杂类型具有复杂内容且两者都没有混合属性时,有效混合是假的。这意味着混合内容生效的唯一方法是,如果cell.type的扩展名导致mixed =“true”被继承。
更熟悉模式的人是否会对正确的解释发表评论?
(顺便说一下:如果我控制了架构,我会将mixed =“true”移动到元素定义,但这不是我的调用。)
答案 0 :(得分:4)
任何阅读我的问题的人都可能想要阅读this帖子(Damien)。看来我的答案并不完全正确:解析器/验证器不会以相同的方式处理基本/派生元素上的混合属性声明。
关于扩展复杂类型,W3C section 3.4.6规范的part 1中XML Schema的子节1.4.3.2.2.1表示
[derived和base] {content type}必须混合使用,或者两者都必须是仅元素的。
所以是的,它是继承的(或者更像是你不能覆盖它 - 最后一样)。
基本上,你所描述的是最理想的行为(而且就我而言)。
我创建了一个简单的模式,用Eclipse的XML工具运行一些测试。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="c">
<xs:complexType>
<xs:complexContent mixed="false">
<xs:extension base="a"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="a" mixed="true">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="b"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
上述架构是有效的,因为Eclipse和W3C的“官方”XML架构验证器都没有注意到它的任何问题。
以下XML对上述架构进行了验证。
<?xml version="1.0" encoding="UTF-8"?>
<c xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="test.xsd">
x
<b/>
y
</c>
所以基本上你不能覆盖复杂基类型的混合。要进一步支持此声明,请尝试并交换base和dervied类型的混合。在这种情况下,XML无法验证,因为派生类型不会混合,因为它(再次)不能覆盖基础的混合。
你也说过
一些解析器允许PCDATA直接在元素中,而其他解析器不允许
澄清你在谈论哪些解析器并不会有什么坏处。 good 解析器在遇到混合内容时不应该失败。如果在架构不允许的情况下遇到混合内容,则给定正确架构的验证解析器将失败。