これは、私がいつも他の人に説明するのが少し難しいと思っていることです: なぜ XML 名前空間が存在するのですか? いつそれらを使用する必要があり、いつ使用しないのですか? XML で名前空間を操作する際によくある落とし穴は何ですか?
また、それらは XML スキーマとどのように関連していますか? XSD スキーマは常に名前空間に関連付ける必要がありますか?
これは、私がいつも他の人に説明するのが少し難しいと思っていることです: なぜ XML 名前空間が存在するのですか? いつそれらを使用する必要があり、いつ使用しないのですか? XML で名前空間を操作する際によくある落とし穴は何ですか?
また、それらは XML スキーマとどのように関連していますか? XSD スキーマは常に名前空間に関連付ける必要がありますか?
要素名と属性名の競合を心配することなく、複数のマークアップ言語を組み合わせることができるようにするためのものです。
たとえば、XSLT コードの一部を見て、名前空間を使用せず、出力に "template"、"for-each" などの要素を含める必要がある XSLT を記述しようとした場合にどうなるかを考えてみてください。 . 構文エラーです。
アドバイスと落とし穴は、私よりも経験豊富な他の人に任せます。
XML 名前空間が存在するのはなぜですか?
なぜなら、1997 年に、W3C で非常に影響力のある何人かがそれらを欲しがり、答えをノーとは思わなかったからです。彼らが抱えていると思っていた「問題」を解決するためのより良い方法があることが証明されたときでさえ、彼らは依然として影響力を行使して、W3C勧告に自分たちの欲求を書き留めさせました.
XML 名前空間をめぐる現在の広範な神話の最大の難点は、XML 名前空間には技術的なメリットがあるということです。(これは、どこかで忘れられがちな脚注とは対照的に、単純に存在し、したがってマインドスペースを占有する勧告の下流への効果です。
いつそれらを使用する必要があり、いつ使用しないのですか?
あなたがそれを助けることができるなら、あなたは決してそれらを使うべきではありません. 残念ながら、利害関係者によるこの BAD[*] デバイスの絶え間ない宣伝により、今日では仕様のクラスター化が促進されており、ある時点で XML 名前空間と競合する必要がなくなることは事実上不可能になっています。そのため、たとえ XML 名前空間を自分で避けたとしても、名前空間が散りばめられたゴミがあらゆる方向からやってくるか、さらに悪いことに、そのようなゴミを与えない限り機能しないツールセットに気付くでしょう。
XML で名前空間を操作する際によくある落とし穴は何ですか?
非常によくある落とし穴の 1 つは、名前空間が「デフォルト設定」されているドキュメントで Xpath 式を使用する場合です。名前空間は、式で明示的に指定する必要があります。もう 1 つの問題は、ドキュメントを作成するときにそれらを「正しく」使用することです。
また、それらは XML スキーマとどのように関連していますか? XSD スキーマは常に名前空間に関連付ける必要がありますか?
XSD Schema 仕様が開発されたのは、委員会のほぼ全員が XML Namespaces に慣れ親しんだ時期であることを除けば、必然的な関係はありません。それで、彼らはそれをできる限り深く取り組みました。それにもかかわらず、名前空間なしで XSD スキーマを使用することは可能ですが、XSD スキーマをサポートするほぼすべてのツールセットが名前空間を使用することを「望んでいる」と想定しているため、それは急な困難です。
[*] BAD = 設計どおりの破損
これは、「なぜ Java/C# のパッケージを使用するのですか?」と尋ねるのとほぼ同じです。
私見の最大の落とし穴は、XML ドキュメントを処理するためのコードを開発するなど、ドキュメントを解釈するヒューマン インタラクションです。ドキュメントを解析した結果の情報セットではなく、ドキュメントのリテラル表現に集中するのはあまりにも簡単です。
たとえば、次のノード
<a xmlns="uri:foo"/>
<foo:a xmlns:foo="uri:foo"/>
<bar:a xmlns:bar="uri:foo"/>
意味的にはすべて同じですが、素朴な目には非常に異なります。
最初の例は、XPath を開発する際に非常によくある間違いを引き起こします。つまり、"a" が名前空間にあるという事実を見落としています。つまり、//a は一致しません。(さらに悪いことに、別の名前空間のノードが一致することもあります!)
3 番目の例では、接頭辞のテキストが意味的に重要であるという理解に別の欠陥があります。XPATH を使用してドキュメントを解析する場合、URI がドキュメントのものと一致する限り、任意のプレフィックスを宣言して一致させることができます。
それらは要素タイプの姓と考えてください。ボブという名前の友達が 2 人いて、そのうちの 1 人のことを話している場合、どちらのボブのことを話しているのか尋ねられるかもしれません。「ボブ」と言うだけではあまり役に立たないので、「ボブ スミス」または「ボブ ジョーンズ」と言います。
要素の種類も同様です。さまざまな人が同じ名前を選ぶ可能性があるため、短い名前では不十分な場合があります。したがって、さまざまなボブを区別するために、URI を「姓」として含めます。
XML は超言語です。つまり、XML ベースの言語の基礎となっています (当然のことですよね?)。XML は、任意の言語で任意の文を書くことができるペンと考えてください。それはすべて作家次第であり、できれば言語は読者に知られているべきです。
XML名前空間は基本的に言語の名前であり、"English" や "עברית" によく似ています。XML ドキュメントの受信者が XML ドキュメントを解析し、その中の情報を抽出できるように支援します。
私には家具工場があり、あなたには家具店があるとしましょう。あなたのストレージ アプリケーションと私のサプライ アプリケーションはまったく無関係ですが、それらが XML メッセージを介して通信する場合、メッセージは理解しやすく、双方で簡単に解析できる必要があります。
したがって、両方のシステムが、言語の構文と合意された制限を定義するSchemaを認識する必要があります。スキーマを辞書と文法の教科書と考えてください。スキーマは、両方のシステムが知っておくべきドキュメントであり、各システムで解析コードを書く人は誰でも知っている必要があり、名前空間の宣言を含みます。
各名前空間は、ほとんどの場合、それを定義するスキーマ ドキュメントの場所である URI として名前が付けられます。
もちろん、すべての XML ドキュメントが名前空間を必要とするわけではありません。リモート システムに情報を伝達するために使用されない場合は特にそうです。たとえば、データベースに永続化するためにオブジェクトを XML にシリアライズする場合です。
名前空間を使用するのは、人々が自分のプライベートidahoで同じ単語を使用して異なることを意味することを望んでいるためです。通常、あなたは文脈から人が何を意味するかを決定することができます。人事データベースでは、XMLは人事レコードです。車両レジストリデータベースでは、XMLは車両レジストリレコードです。
どちらも「location」という名前のタグを保持していますが、タグはそれぞれに異なる意味を持ち、異なるフィールドが含まれています。
さて、それはすばらしいことです。しかし、両方のXMLを同じデータベースに保存する必要がある場合、または保存したい場合はどうでしょうか。または、さらに興味深いことに、両方のデータベースが他の一般的なデータベース(たとえば、Accountsデータベース)からのXMLチャンクを格納したい場合はどうでしょうか。
XML名前空間は各XMLタグにURIを関連付け、タグ名自体の前にURLがあり、それがタグ名の一部です(もちろん、実際のXMLドキュメントは省略形を使用してこれを行います)。URIを慎重に選択することで、タグ名が衝突しないことを簡単に確信できます。2つのロケーションタグの名前がまったく異なるように見えるため、混乱することはありません。ボーナスとして、2つのまったく異なるロケーションタグには、アカウントデータベースからのものを含めることができ、同じことについて話していることを明示的に示すことができます。
これをすべて便利にするのはXPATHです。
上記を使用すると、次のようなXPATH式の記述を開始できますaccounts:account overdue
。このxmlの任意のセクションを見つけてください。または:accounts:warning message
この特定のXMLチャンクのどこかにあるアイテムを見つけてください。ここで、警告メッセージはpersonnel:payment
ノードまたはノードのいずれかの子ノード(ただし深い)ですvehicle:status
。
そのXPATH式は、表示用にXMLをXHTMLまたはXPDFに変換することを目的とするXSLTドキュメントのどこかで使用される可能性があります。
見返りは何ですか?なぜそれをするのですか?XMLログファイルを検索できるため、他のシステムによって生成された「メッセージ」タグと混同することなく、表示されているすべてのアカウントの期限切れメッセージを引き出し、'emをxhtmlに変換し、cssタグを介して太字の赤で表示します。手続き型コードのスクラップを書かずに。
私の言葉では、外部の会社 (たとえば) に XML 形式を使用する必要があり、XML ドキュメントで同じ名前の情報を提供する必要がある場合は、名前空間が必要です。例:
<sampleDoc>
<header title="Hello world!">
<items>
<item name="Volvo" color="Blue"/>
</items>
</header>
</sampleDoc>
そして、同じ名前を持つこのドキュメントにいくつかのデータをマージしたいが、別の意味 ( so 値 to ) がある場合は、名前空間を使用する必要があります。
<sampleDoc>
<header title="Hello world!">
<items>
<item name="Volvo" color="White" my_unique_namespace:color="#FFFFFF"/>
</items>
</header>
</sampleDoc>
もちろん、属性の名前を変更できます。たとえば、「my_unique_color」に。Bud 別のドキュメントでは、同じ名前の属性が再び存在する可能性があります。そのため、一意の名前空間 (たとえば、当社の Web ドメイン) を持っている場合は、常に同じ名前の要素や属性を問題なく使用できます。
W3のおすすめから…
XML 名前空間は、URI 参照によって識別される名前空間に関連付けることによって、Extensible Markup Language ドキュメントで使用される要素名と属性名を修飾するための簡単な方法を提供します。
名前空間は、ドキュメント内で使用する名前のあいまいさを解消するために使用されます。また、短い名前を名前空間にバインドして、リモートの要素または属性を参照するために使用することもできます。名前空間自体は、ドキュメントで使用する要素と属性を定義する場所を指します。知っておくべきことはもっとたくさんありますが、それがその核心です。ここにはさらに多くの情報があります。