【问题标题】:XSD attribut validation for MANY elements with the same name - not possible?对许多具有相同名称的元素进行 XSD 属性验证 - 不可能?
【发布时间】:2014-11-19 22:16:23
【问题描述】:



大家好,

情况是这样的:
我有一个 XML 文件,其中包含一个程序的许多 (>50) 配置属性。

这个 XML 内容看起来像这样:

<GlobalConfig>
    <ConfigurationSettings> 
        <Property Name="UseColors" Value="True" Visible="False"/>
        <Property Name="TitleMenu" Value="Configurator" Visible="True"/>
        <Property Name="InformationText" Value="For information please read readme.txt" Visible="True"/>
            [many more...]
    </ConfigurationSettings>
</GlobalConfig>


我现在想做的是创建一个 xsd 文件来验证这些东西。 对于每个属性,相应的 value-attribute 具有不同的 contenttype(具有某些限制,例如 enums 或 regEx),因此 value 内容的验证规则需要适应每种情况。大小写由“名称”-属性决定

我是 xsd 主题的新手,所以我尝试了一些开始:

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xs:element name="GlobalConfig">
        <xs:complexType>
            <xs:all>    

                <xs:element name="ConfigurationSettings">
                    <xs:complexType>
                        <xs:all>

                            <xs:element name="Property" minOccurs="0" maxOccurs="unbound">
                                <xs:complexType>                            
                                        <xs:attribute name="Name" fixed="UseColors" type="xs:string"/>
                                        <xs:attribute name="Value" default="True" type="xs:bool"/>
                                        <xs:attribute name="Visible" default="False" type="xs:bool"/>
                                </xs:complexType>
                            </xs:element>

                            <xs:element name="Property" minOccurs="0" maxOccurs="unbound">
                                <xs:complexType>                            
                                        <xs:attribute name="Name" fixed="TitleMenu" type="xs:string"/>
                                        <xs:attribute name="Value" default="Title" type="xs:string"/>
                                        <xs:attribute name="Visible" default="True" type="xs:bool"/>
                                </xs:complexType>
                            </xs:element>

                            <xs:element name="Property" minOccurs="0" maxOccurs="unbound">
                                <xs:complexType>                            
                                        <xs:attribute name="Name" fixed="InformationText" type="xs:string"/>
                                        <xs:attribute name="Value" default="See reedme.txt" type="xs:string"/>
                                        <xs:attribute name="Visible" default="True" type="xs:bool"/>
                                </xs:complexType>
                            </xs:element>

                        </xs:all>
                        <xs:attribute type="xs:string" name="Force"/>
                    </xs:complexType>
               </xs:element>

            </xs:all>
        </xs:complexType>
    </xs:element>

</xs:schema>

这不起作用,我想我明白为什么它不起作用: 问题是,我有许多同名的元素(“属性”)。

我有一种朦胧的感觉,这种方式实际上根本行不通,需要更改 configuration-xml 的结构,以便每个属性都有不同名称的元素。

我认为的原因是以下帖子中的第二个答案。这似乎满足了提问者的需求,但他只有两个同名的元素,他也不想检查它们的属性: XML Schema for sequence of elements with same name but different attribute values?

您同意它不适用于给定的 configuration-xml 结构吗?还是还有可能?

非常感谢!

【问题讨论】:

标签: xml xsd xml-validation


【解决方案1】:

XSD 有一个称为“元素声明一致”的约束,它实际上表示如果两个同级元素具有相同的名称,那么它们必须具有相同的类型。因此,互为兄弟的不同 Property 元素不可能有不同的验证规则。

在 XSD 1.1 中有一个使用类型替代的解决方案。这允许您根据元素的一个或多个属性(在本例中为 Name 属性)的值来确定元素的类型。

有什么特殊原因导致你不能设计配置文件,而不是

<Property Name="UseColors" Value="True" Visible="False"/>

你使用

<UseColors Value="True" Visible="False"/>

使用前一种(“通用”)设计的主要原因是架构不必知道所有可能的属性名称。但是您实际上想在架构中定义属性名称和有效值,因此第二种设计更合适。

【讨论】:

  • 感谢您的回答。在我看来,重新设计配置文件是最好的方法,是的。只是出于好奇:使用 XSD 1.1 是不是有些不好的做法?看起来 VisualStudio 不支持它(还没有?)。
  • XSD 1.1 非常有用,但您需要注意目前只有三种处理器可用:Saxon、Xerces 和 Altova。因此,您需要考虑这些好处是否证明您的技术选择的限制是合理的。您还应该知道,大约十年前,Microsoft 已经完全停止实施新的 W3C XML 标准,这越来越意味着您需要准备好研究第三方工具。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-03-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多