复杂类型的 XML 模式限制:完全重新定义? [英] XML Schema Restriction for Complex types : Complete Redefinition?

查看:31
本文介绍了复杂类型的 XML 模式限制:完全重新定义?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在 XML Schemas 中对 complexTypes 添加限制时,是否需要重写 complexType 定义中使用的所有元素?如果是这样,为什么不能重用现有的元素定义并覆盖新的受限元素?

When adding restrictions to complexTypes in XML Schemas , is it necessary to rewrite all the elements used in the definition of the complexType? If so , Why can't it just reuse the existing element definitions and overwrite the new restricted ones?

例如,在下面;当我只想限制字段 country 时,我应该重新重写所有 3 个字段吗?

For example , In the below ; When I just want to restrict the field country , Should I rewrite all the 3 fields again?

<xs:complexType name="customer">
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
    <xs:element name="country" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="Norwegian_customer">
  <xs:complexContent>
    <xs:restriction base="customer">
      <xs:sequence>
        <xs:element name="firstname" type="xs:string"/>
        <xs:element name="lastname" type="xs:string"/>
        <xs:element name="country" type="xs:string" fixed="Norway"/>
      </xs:sequence>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType> 

所以,从下面的答案中很清楚为什么我们必须重写整个类型.

So , It is pretty clear from the answer below as to why we have to rewrite the whole type.

后续问题

那么这个限制功能有什么用呢?

What's the use of this restriction feature then?

一种情况,我能想到;是当您必须验证包含受限类型而不是 xml 架构中的基本类型的实例文档时.

One situation , I can think of ; is when you have to validate instance documents containing restricted types in place of base types in xml schema.

说,如果B"是基本类型并且它被限制为B*".在架构文档期望类型为B"的元素的位置包含B*"的任何实例文档都可以工作.我们不必为每个受限类型编写单独的规则.(属性xsi:type"在实例文档将使用正确的类型对其进行验证.)对吗?

Say , If "B" is the base type and its restricted to "B*". Any instance document containing "B*" at the place where an element of type "B" is expected by the Schema Document would work.We would not have to write separate rules for each restricted type.(The attribute "xsi:type" in the instance document will validate it with the correct type.)Right?

此功能还有其他用途吗?

Any Other uses of this feature?

推荐答案

您的第一个问题是在 XML Schemas 中对 complexTypes 添加限制时,是否需要重写所有在 complexType 定义中使用的元素?";不,只有那些你想成为受限类型定义的一部分.但是,是的,所有这些都应该成为限制的一部分.限制中的内容模型必须独立作为类型的内容模型的完整定义.(另一方面,它不必指定所有属性;除非另有说明,否则它们将被继承而不更改.)

Your first question is "When adding restrictions to complexTypes in XML Schemas, is it necessary to rewrite all the elements used in the definition of the complexType?" No, only the ones you want to be part of the definition of the restricted type. But yes, all of the ones that should be part of the restriction. The content model in the restriction must stand on its own as a complete definition of the content model of the type. (It does not, on the other hand, have to specify all the attributes; they are inherited without change unless otherwise specified.)

您的第二个问题是为什么不能重用现有的元素定义并覆盖新的受限元素定义?";这是一个合理的问题.答案有点棘手:考虑两个任意的内容模型 E 和 F.现在,我们想将 F 解释为 E 的限制,仅提及我们想要更改的 E 中的元素和模型组,并省略任何提及的元素和我们想要单独的模型组.在一般情况下,这是一个可解决的问题吗?是否保证有唯一的解决方案?在你看来,这两种情况的答案都是肯定的,但在当时的 XSD 设计者看来并不明显,今天对我来说似乎也不明显.

Your second question is "Why can't it just reuse the existing element definitions and overwrite the new restricted ones?" It's a reasonable question. The answer is slightly tricky: Consider two arbitrary content models E and F. Now, we want to interpret F as a restriction of E that mentions only the elements and model groups in E that we want to change, and omits any mention of the elements and model groups we want alone. Is this a soluble problem, in the general case? Is it guaranteed to have a unique solution? It may seem obvious to you that the answer is yes in both cases, but it did not seem obvious to the designers of XSD at the time, and it does not seem obvious to me today.

例如,设 E

(a+, b+, c*){2}, (a+, b*, c+){3}

让 F 成为

a{3,4}

如果我们假设 F 中的所有内容都是 E 中某些内容的限制,而 E 中的其他所有内容都应该保留,那么 F 是否意味着我们要将 E 限制为

If we assume that everything in F is a restriction of something in E and everything else in E should be left alone, does F mean we want to restrict E to

(a{3,4}, b+, c*){2}, (a+, b*, c+)

或到

(a+, b+, c*){2}, (a{3,4}, b*, c+)

?

@nikel 要求提供 XSD 示例.不过,上面的示例已经是一个 XSD 示例,所以我想XSD 语法中的示例"是一个例子.是指.我的建议是像下面这样的语法应该有效.首先我们有基本类型,E:

@nikel asks for an XSD example. The example above is already an XSD example, though, so I suppose "an example in XSD syntax" is meant. I take the proposal to be that syntax like the following should work. First we have the base type, E:

<xs:complexType name="E">
  <xs:sequence>
    <xs:sequence minOccurs="2" maxOccurs="2">
      <xs:element ref="a" maxOccurs="unbounded"/>
      <xs:element ref="b" maxOccurs="unbounded"/>
      <xs:element ref="c" minOccurs="0" 
                          maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:sequence minOccurs="3" maxOccurs="3">
      <xs:element ref="a" maxOccurs="unbounded"/>
      <xs:element ref="b" minOccurs="0" 
                          maxOccurs="unbounded"/>
      <xs:element ref="c" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:sequence>
</xs:complexType>

现在让我们想象一下,我们希望类型 F 能够在不指定完整内容模型的情况下限制 E.所以我们写

Now let us imagine that we want type F to be able to restrict E without specifying a full content model. So we write

<xs:complexType name="F">
  <xs:complexContent>
    <xs:restriction base="tns:E">
      <xs:sequence>
        <xs:element ref="a" minOccurs="3" maxOccurs="4"/>          
      </xs:sequence>        
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

这里F的有效内容模型应该是什么?

What should the effective content model of F be here?

本质上,您会问,在那种情况下,限制有什么用?"

You ask, essentially, "in that case, what's the use of restriction?"

合理的问题.您建议的答案是一个很好的答案.更一般地,有时我们发现知道类型 B* 的每个实例都是类型 B 的实例很有用;XSD 中的限制推导旨在保证该不变性.有时,定义具有两个或多个具体限制的抽象类型似乎很有帮助;这有助于确保抽象基类型的各种具体实现彼此很好地相关联,即使没有一个是任何其他实现的子集或超集.

Reasonable question. The answer you suggest is a good one. More generally, sometimes we find it useful to know that every instance of type B* will be an instance of type B; derivation by restriction in XSD is intended to guarantee that invariant. Sometimes it seems helpful to define an abstract type with two or more concrete restrictions; that helps ensure that the various concrete realizations of the abstract base type are nicely related to each other, even if none is a subset or superset of any other.

在 XSD 中,可能有(不:很多)方法可以使限制派生变得更清晰、更简单和更方便;不必重复整个内容模型将是其中之一.但是,XSD 中的几乎所有内容都是如此.它唯一真正的优点是它得到了很多人似乎想要使用的许多工具的支持.

There could be (no: there are plenty of) ways that derivation by restriction could be made clearer, simpler, and more convenient in XSD; not having to repeat the entire content model would be one of them. But then, that's true for pretty much everything in XSD. Its only real virtue is that it is supported by a lot of tools a lot of people seem to want to use.

这篇关于复杂类型的 XML 模式限制:完全重新定义?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆