递归 XML 的 XSD 架构 [英] XSD schema for recursive XML

问题描述

我在为某些 xml 创建 XSD 时遇到问题.

I'm having trouble creating an XSD for some xml.

了解一点背景可能会有所帮助.xml 用于消息传递.特别是，消息设计简单，易于交叉引用.在其核心是一个递归键值设置.

A bit of background might help. The xml is for messaging. In particular, the message is designed to be simple, and designed to be cross referenced easily. At its heart is a recursive key value set up.

简单的键值是这样的.

    <key name="quantity">5</key>
    <key name="price" representation="percentage">99.78</key>

有一个可选的表示属性，其中信息可以用两种不同的形式表示.

There is an optional representation attribute where the infromation could be represented in two different forms.

Reference Key Values 是这样的

Reference Key Values are like this

    <key name="currency" reference="instrument">
        <id name=" INSID" system="XXXX" instance="PROD">DEM</id>
        <id name=" EXTERN_ID1" system="XXXX" instance="PROD"> ext128k</id>
    </key>

这种形式用于外键引用或枚举引用.交叉引用服务将选择具有引用属性的所有键.然后它将获取该引用的所有可能的 id，并添加额外的 id字段，并用新版本替换该子元素.

This form is used for foreign key references or for references to enumerations. The cross reference service will select out all keys with an attribute of reference. It will then get all possible ids for that reference, and add in additional id fields, and replace that sub element with the new version.

ie "./key[@reference]" 作为 Xpath 可以得到所有的枚举和引用来自 xml

ie "./key[@reference]" as an Xpath can get all the enumerations and references from the xml

最后是递归结构.这里是键值的值部分，可以是键值本身.

Lastly there is a the recursive structure. Here the value part of the key value, can be a key value itself.

<key name="trade" type="trade">
    <key name="value_day">1999-03-12</key>
    <key name="quantity">5</key>
    <key name="leg" type="leg">
        <key name="rate">5.00</key>
        <key name="period">3m</key>
        <key name="cashflows" type="cashflows">
            <key name="cashflow">10</key>
            <key name="cashflow">20</key>
        </key>
    </key>
</key>

现在，我很难为这个结构创建 XSD.

Now, I'm having real trouble creating an XSD for this structure.

有人可以帮忙吗?

谢谢

尼克

推荐答案

如果我理解正确，您希望您可以这样编写 Schema:

If I understand correctly, you wish that you could write Schema like this:

<!-- WARNING: this is not valid Schema -->
<xs:complexType name="composite-key">
  <xs:choice maxOccurs="unbounded">
    <xs:element name="key" type="simple-key"/>
    <xs:element name="key" type="composite-key"/>
  </xs:choice>
  <xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>

simple-key 将在别处定义.这不是有效的架构，因为您不能两次使用相同的元素名称.如果 Schema 支持这一点，那么它会在一段时间内仅根据其结构来消除元素类型的歧义.

simple-key would be defined elsewhere. This is not valid Schema since you are not allowed to use the same element name twice. If Schema supported this, it would have a devil of a time disambiguating element types based upon their structure alone.

如果您可以控制 XML，则可以通过更改一个或两个元素名称来实现此目的.例如，可以将 val 用于简单值，obj 用于复合值:

If you have control over the XML, you can make this work by changing one or both of the element names. For example, one might use val for simple values and obj for composite ones:

<xs:complexType name="composite-key">
  <xs:choice maxOccurs="unbounded">
    <xs:element name="val" type="simple-key"/>
    <xs:element name="obj" type="composite-key"/>
  </xs:choice>
  <xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>

根据口味调整名称.这将是我推荐的解决方案，因为它强调清晰度.但是，元素名称可能不受您的控制.如果是这样，一个不太令人满意的解决方案如下:

Adjust the names to taste. This would be my recommended solution as it emphasizes clarity. However, the element names may be out of your control. If so, a less satisfactory solution would be as follows:

<xs:complexType name="key" mixed="true">
  <xs:sequence maxOccurs="unbounded">
    <xs:element name="key" type="key"/>
  </xs:sequence>
  <xs:attribute name="name" type="xs:string" use="required"/>
  <xs:attribute name="type" type="xs:string"/>
  <xs:attribute name="representation" type="xs:string"/>
</xs:complexType>

这里的主要区别在于混合内容类型，以及声明现在是简单和复合键类型的混合体这一不幸的事实.我说这不太令人满意"，因为现在你必须在你自己的代码中执行额外的有效性检查，在 Schema 完成之后.例如，您需要验证给定的属性集对于隐含的键类型是否有意义.此外，所写的示例允许文本出现在嵌套键元素之间的任何位置——可能是您不想要的.

The key differences here are the mixed content type, and the unfortunate fact that the declaration is now an amalgam of the simple and composite key types. I say that this is "less satisfactory" because now you must perform additional validity checking in your own code, after Schema has finished with it. For example, you would need to validate whether the set of attributes given make sense for the implied key type. Also, the example as written would permit text to appear anywhere between nested key elements -- probably something you do not want.

这篇关于递归 XML 的 XSD 架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！