10

XMLスキーマのcomplexTypesに制限を追加する場合、complexTypeの定義で使用されるすべての要素を書き直す必要がありますか？もしそうなら、なぜそれは既存の要素定義を再利用して新しい制限されたものを上書きできないのですか？

たとえば、以下では; フィールドの国を制限したいだけの場合、3つのフィールドすべてを書き直す必要がありますか？

<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>

したがって、タイプ全体を書き直さなければならない理由については、以下の回答からかなり明らかです。

フォローアップの質問

では、この制限機能の用途は何ですか？

一つの状況、私は考えることができます; xmlスキーマの基本型の代わりに制限された型を含むインスタンスドキュメントを検証する必要がある場合です。

たとえば、「B」が基本タイプであり、「B*」に制限されている場合。タイプ「B」の要素がスキーマドキュメントによって予期される場所に「B*」を含むインスタンスドキュメントはすべて機能します。制限されたタイプごとに個別のルールを記述する必要はありません。（属性「xsi：type」のインスタンスドキュメントは正しいタイプで検証します。）そうですか？

この機能の他の用途はありますか？

4

1 に答える 1

11

最初の質問は、「XMLスキーマのcomplexTypesに制限を追加する場合、complexTypeの定義で使用されるすべての要素を書き直す必要がありますか？」です。いいえ、制限付きタイプの定義の一部にしたいものだけです。しかし、はい、制限の一部である必要があるものすべて。制限内のコンテンツモデルは、そのタイプのコンテンツモデルの完全な定義として独立している必要があります。（一方、すべての属性を指定する必要はありません。特に指定しない限り、変更なしで継承されます。）

2番目の質問は、「既存の要素定義を再利用して、新しい制限された定義を上書きできないのはなぜですか？」です。それは合理的な質問です。答えは少し注意が必要です。2つの任意のコンテンツモデルEとFを考えてみましょう。ここで、Fを、変更するEの要素とモデルグループのみに言及し、要素の言及を省略したEの制限として解釈します。一人で欲しいモデルグループ。一般的な場合、これは解決可能な問題ですか？独自のソリューションがあることが保証されていますか？どちらの場合も答えが「はい」であることがあなたには明白に思えるかもしれませんが、当時のXSDの設計者には明白ではなかったようであり、今日私には明白ではないようです。

たとえば、Eを

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

そしてFを

a{3,4}

FのすべてがEの何かの制限であり、Eの他のすべてをそのままにしておく必要があると仮定すると、FはEをに制限したいという意味ですか？

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

またはに

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

？

補遺

@nikelはXSDの例を求めています。ただし、上記の例はすでにXSDの例であるため、「XSD構文の例」を意味していると思います。私は、次のような構文が機能するはずだという提案を受け入れます。まず、基本タイプ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を制限できるようにしたいとします。だから私たちは書く

<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の効果的なコンテンツモデルはここにあるべきですか？

フォローアップの質問

基本的に、「その場合、制限の使用は何ですか？」と尋ねます。

合理的な質問。あなたが提案する答えは良いものです。より一般的には、タイプB*のすべてのインスタンスがタイプBのインスタンスになることを知っておくと便利な場合があります。XSDでの制限による導出は、その不変を保証することを目的としています。2つ以上の具体的な制限がある抽象型を定義すると役立つ場合があります。これは、抽象ベースタイプのさまざまな具体的な実現が、他のサブセットまたはスーパーセットでなくても、互いに適切に関連していることを確認するのに役立ちます。

XSDで制限による導出をより明確に、より単純に、より便利にする方法があります（いいえ：たくさんあります）。コンテンツモデル全体を繰り返す必要がないこともその1つです。しかし、それはXSDのほとんどすべてに当てはまります。その唯一の本当の長所は、多くの人が使いたいと思われる多くのツールによってサポートされていることです。

于 2013-02-10T18:53:20.467 に答える