xsd：complexTypeが属性でないのはなぜですか？

Question

なぜ代わりに

<xs:element name="elementName"> 
    <xs:complexType> 
    <xs:sequence> 
     <xs:element name="subElementName" type="xs:string"/> 
    </xs:sequence> 
    </xs:complexType> 
</xs:element> 

を記述することで、私はそれがxs:complexTypeであることを要素の属性として指定することはできません？私は疑問に思いますかまたはxs:elementとxs:complexTypeを組み合わせたxs:superSecretThingIdontKnowAboutがありますか？私たちはそこにいる間にも何かを組み合わせているものもありますxs:sequence。上記のコードは次のように書くことができます。

<xs:superSecretThingIdontKnowAbout name="elementName" sequence="true"> 
    <xs:element name="subElementName" type="xs:string"/> 
<xs:superSecretThingIdontKnowAbout> 

コンテキスト

XSDがXMLであるとの願いで拡張することができますので、私は、MySQLデータベース内のフィールドのスキーマを書いていることを追加します。これがどうにかして可能性を制限するかどうかは分かりません。それに対してうまくいかない回答も歓迎です。これは、私がこの事実に悩まされている唯一の人ではないことを確認するためです。

Answer 1

あなたが欠けている唯一のsuperSecretThingIdontKnowAboutは、単純な、構造のない値を表すのに属性が優れていることです。構造を表現する要素がより優れています。 XML Elements vs XML Attributesを参照してください。

複合型は構造を持っています。スカラーではありません。要素から属性への移動は、構造の表現を失望させます。たとえば、代替デザインでは、シーケンス上のオカレンスインジケータをどのように表現しますか？より多くの属性？ああ。サブシーケンス間で混在した選択肢からなるシーケンスはどうですか？等々。

ほとんどの人は、XSDの直交性の欠如を嘆いています。あなたの提案は事態を悪化させるでしょう。

は、複雑なタイプを定義し、属性を経由してそれらを参照することができていること、しかし、注意を行います

<xs:element name="a" type="aType"/> 

これは、複合型定義を共有することができることに非常に有用です。