最初に、正式な質問について:form
属性は実際に XSD の表現力に追加されますか? 私はそう思います:form
属性を使用しないと、有効なインスタンスのセットが (私が見る限り) 一致しない型を書くことができform
ます。
a
例 ( typeという名前の最上位要素を定義するスキーマ内duration
):
<choice maxOccurs="unbounded">
<element form="qualified" name="a" type="integer"/>
<element form="unqualified" name="a" type="gYear"/>
</choice>
次に、あまり形式ばらない質問についてですが、なぜ誰かが気にするのでしょうか?
簡単に言えば、ローカル要素と属性の修飾名と非修飾名から選択できるそれぞれの方法について、それがローカル要素や属性を宣言する正しい方法だと考える人がいるからです。
長い回答には少し時間がかかります。座って、コーヒーを飲みましょう。
ローカル要素には 2 つの考え方があります。どちらも、XSD を設計したワーキング グループに参加していました。
ある考え方では、要素 P が名前空間 N にあり、要素 C が要素 N:P の型に対してローカルである場合、子要素に N:C という名前を付けるのは当然であると考えられています。結局のところ、これは P と同じ語彙の一部であり、語彙を識別することが名前空間のすべてです。最後の質問から、あなたはこのような見方に傾いていると思います。
もう 1 つの考え方は、ローカル要素がローカル属性に似ているという理由です。要素 N:P (の型) にローカルな属性は、N:A ではなく A という名前です。名前 N:A は、定義上、要素 N:P にローカルではなく、名前空間 N にグローバルな属性を示します。同様に、属性と子要素が同様に扱われるように、ローカルの子も非修飾名を使用する必要があります。
XSD 要素および属性宣言に属性が存在form
することは、修飾名と非修飾名の間の選択を、ローカル要素または属性ごとに個別に取られる設計上の選択として扱いたいという願望によって特徴付けられる、第 3 の考え方の存在の可能性を示唆している可能性があります。 、必ずしも単一の語彙全体の勅令ではありません。価値のあることですが、この 3 番目の学派は実際には存在しないようです。少なくとも、メンバーに会ったことはないと思います。修飾されたローカル名と修飾されていないローカル名が混在する、上に示したような複雑な型を書き込もうとする人は誰もいないようです。属性の本質的な機能は、form
さまざまなローカル要素を修飾または非修飾にできるようにすることではなく、elementFormDefault
およびによってデフォルトを設定することです。attributeFormDefault
これにより、スキーマの作成者がそれらの属性の間違った値で立ち往生している場合でも、希望する効果を得ることができます。
私はまた、(私が知っている限りでは)最初の 2 つの学派のいずれのメンバーにも、他の学派の推論にまったく同情を感じることができる人に会ったことはありません。他の学派のメンバーが考えるように誰もが考えることができるということは、ほとんどの場合、歓迎されない驚きとしてもたらされてきました. 少しの努力で、頭の良い善良な人々は、別の学派の存在を受け入れることが可能であり、(もう少し努力すれば) その学派のメンバーが誠実に議論していることを受け入れることさえできるでしょう。作品を台無しにしようとしているだけではありません。さまざまな見解は、せいぜい人類学的な関心にすぎません (人々が信じていると主張できる非常に奇妙なことを見てください。そうでなければ、彼らは多かれ少なかれ合理的な存在のように見えます! 面白い古い世界ですね?)。
その後、WG のほぼ全員が、考えられる 3 つの可能性について同じランキングを持っていることが明らかになりました。
- 私が正しいと思う方法で物事を定義してください。
- スキーマ作成者が選択しなければならないように定義します。
- 他の人が正しいと思う方法で物事を定義します。
誰もが最初の選択 (「私」の適切な値) を気に入りましたが、別の WG メンバーにとって、「私が正しいと思う方法」は異なるものを意味することが判明しました。
2 番目の選択は、スキーマ作成者の作業を困難にし、スキーマの世界の一貫性を低下させるため、あまり好まれませんでした。
しかし、誰もが 3 番目の選択 (他の人が望むように物事を行うことを強いられる) を非常に嫌っていたので、完全な敗北の危険を冒すよりも進んで妥協を受け入れました。