XML名前空間とは何ですか？
これは常に他の人に説明するのが少し難しいと思うものです。なぜXML名前空間が存在するのですか？いつ使用すべきか、いつ使用すべきか？ XMLで名前空間を操作するときによくある落とし穴は何ですか？
また、XMLスキーマとどのように関連していますか？ XSDスキーマは常に名前空間に関連付けられるべきですか？
これらは、要素名と属性名の競合を心配することなく、複数のマークアップ言語を組み合わせることができるようにするためのものです。
たとえば、XSLTコードの任意のビットを見て、名前空間を使用せず、出力に「テンプレート」、「for-each」などの要素を含める必要があるXSLTを書き込もうとした場合にどうなるかを考えます。 。構文エラーです。
アドバイスや落とし穴は、私よりも経験のある人に任せます。
なぜXML名前空間が存在するのですか？
それは、1997年に、W3Cの非常に影響力のある一部の人々がそれらを望んでおり、答えを受け入れなかったためです。それが実証されたときでさえ、彼らが持っていると思った「問題」を解決するより良い方法があったと私は決定的に言う、彼らは彼らの欲望をW3C勧告に書き出すように彼らの影響力をまだ使い続けた。
XML名前空間を取り巻く今までの大規模な神話の最大の大物は、それらに技術的なメリットがあるということです。 （これは、Recommendationが単に存在することによる下流への影響であり、したがって、マインドスペースを占有している-「おい、（良い）理由があるはずだ！」-どこかで忘れられる脚注とは対照的です。）
いつ使用すべきか、いつ使用すべきか？
あなたがそれを助けることができるなら、あなたはそれらを決して使うべきではありません。残念ながら、利害関係者によるこのBAD [*]デバイスの容赦ないプロモーションにより、今日、ある時点でXML名前空間と競合する必要がないようにすることが実質的に不可能である仕様のclusterf * ckが促進されました。したがって、XML名前空間を自分で避けたとしても、名前空間に覆われたクラッドがあらゆる方向からやって来ます。さらに悪いことに、そのようなクラッドを供給しない限り、単に動作を拒否するツールセットがあります。
XMLで名前空間を操作するときによくある落とし穴は何ですか？
非常によくある落とし穴の1つは、名前空間が「デフォルト」になっているドキュメントでXpath式を使用する場合です。名前空間は式で明示的にする必要があります。もう1つの問題は、ドキュメントを作成するときにそれらを「正しく」使用することです 薄い空気から問題が発生する 。
また、XMLスキーマとどのように関連していますか？ XSDスキーマは常に名前空間に関連付けられるべきですか？
XSDスキーマ仕様は、委員会のほぼすべての人がXML名前空間を使用しているときに開発されたことを除いて、必要な関係はありません。それで、彼らはそれをできる限り深く働きました。それでも、名前空間なしでXSDスキーマを使用することは可能ですが、XSDスキーマをサポートするほとんどすべてのツールセットが名前空間の使用を「望んでいる」ことを想定しているため、これは急な上り坂です。
[*]不良=設計どおりの破損
更新： この問題以外の非解決策に関する古いエッセイ 。
「Java/C＃のパッケージを使用する理由」を尋ねるのとほぼ同じです。
- 再利用可能性：さまざまなタイプのxml文書で定義したタグ/属性のセットを再利用できます。
- modularity：XMLに「アスペクト」を追加する必要がある場合。 xmlドキュメントに名前空間を追加する方が、xmlスキーマ定義全体を変更するよりも簡単です。
- 「メイン」名前空間の汚染を回避する：パーサーに巨大なスキーマ定義を強制的に動作させるのではなく、必要な名前空間を使用するだけです。
IMHOの最大の落とし穴は、人間との相互作用の解釈文書です。 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は、任意の文を任意の言語で書くことができるペンと考えてください。それはすべてライターに依存し、できれば言語はリーダーに知られている必要があります。
XML namespaceは基本的に言語の名前で、「英語」や「עברית」によく似ています。私は、XMLドキュメントの受信者がそれを解析し、その中の情報を抽出するのを支援します。
家具工場があり、家具店があるとします。ストレージアプリケーションと私の供給アプリケーションはまったく無関係ですが、XMLメッセージを介して通信する場合、メッセージは理解可能であり、両側で簡単に解析できます。
したがって、両方のシステムはSchemaを知る必要があります。これは、言語構文と合意された制限を定義します。スキーマは、辞書および文法の教科書と考えてください。スキーマは、両方のシステムが知っておくべきドキュメントであり、各システムで解析コードを書く人は誰でも知っている必要があり、名前空間の宣言が含まれています。
各名前空間はURIとして名前が付けられます。これは、ほとんどの場合、それを定義するスキーマドキュメントの場所です。
もちろん、すべてのXMLドキュメントが名前空間を必要とするわけではありません。リモートシステムへの情報伝達に使用されていない場合は特にそうです。たとえば、データベースに永続化するためにオブジェクトをXMLにシリアル化する場合などです。
名前空間を使用しているのは、xeepが同じ単語を使用して自分のプライベートidahoで異なることを意味することを望んでいるためです。通常、コンテキストから人の意味を判断できます。人事データベースでは、XMLは人事レコードです。車両登録データベースでは、XMLは車両登録レコードです。
どちらも「場所」という名前のタグを保持していますが、タグはそれぞれに異なる意味を持ち、異なるフィールドを含んでいます。
さて、それはすばらしいことです。しかし、両方のXMLを同じデータベースに格納する必要がある場合、または格納したい場合はどうでしょうか。または、さらに興味深いことに、両方のデータベースが他の一般的なデータベース（例：アカウントデータベース）からのXMLチャンクを格納したい場合はどうでしょうか。
XML名前空間は、各XMLタグにURIを関連付けます。つまり、タグ名自体の前にURLがあり、URLはタグ名の一部です（もちろん、実際のXMLドキュメントはこれを行うために省略形を使用します）。 URIを注意深く選択することにより、タグ名が衝突しないことが容易にわかります。2つのロケーションタグの名前がまったく異なるように見えるため、混乱はありません。おまけとして、2つのまったく異なる場所タグには、アカウントデータベースからのものを含めることができ、同じことについて話していることを明示的に述べることができます。
これをすべて便利にするのがXPATHです。
上記を使用すると、次のようなXPATH式の記述を開始できます。このxml内の任意のaccounts:account overdueセクションを見つけてください。または：この特定のXMLチャンクのどこかにaccounts:warning messageアイテムを見つけてください。警告メッセージはpersonnel:paymentノードまたはvehicle:statusノードの子ノード（ただし深い）です。
そのXPATH式は、表示のためにXMLをXHTMLまたはXPDFに変換することがXSLTドキュメントのどこかで使用される場合があります。
見返りは何ですか？なんで？ XMLログファイルを検索できるため、他のシステムによって生成された「メッセージ」タグと混同することなく、すべてのアカウントの期限切れメッセージをどこにでも引き出します、 'emをxhtmlに変換し、cssタグを介して太字の赤で表示します：all手続きコードのスクラップを作成せずに。
私の言葉では、外部の会社（たとえば）にXML形式を使用する必要があり、XMLドキュメントに同じ名前の情報を提供する必要がある場合は、名前空間が必要です。例：
<sampleDoc>
<header title="Hello world!">
<items>
<item name="Volvo" color="Blue"/>
</items>
</header>
</sampleDoc>
同じ名前であるが別の意味（つまりvalue to）のデータをこのドキュメントにマージする場合は、名前空間を使用する必要があります。
<sampleDoc>
<header title="Hello world!">
<items>
<item name="Volvo" color="White" my_unique_namespace:color="#FFFFFF"/>
</items>
</header>
</sampleDoc>
もちろん-属性の名前を変更できます。たとえば「my_unique_color」に。別のドキュメントの芽、同じ名前の属性が再び存在する可能性があります。したがって、一意の名前空間（たとえば、私たちのWebドメイン）がある場合は、問題なく、常に同じ名前の要素や属性を使用できます。
W3推奨 ...から.
XML名前空間は、拡張参照マークアップドキュメントで使用される要素と属性の名前を、URI参照で識別される名前空間に関連付けることにより、それらを修飾する簡単な方法を提供します。
名前空間は、ドキュメント内で使用する名前を明確にするために使用されます。また、リモート要素または属性を参照するために使用できる名前空間に短い名前をバインドする機能も提供します。名前空間自体は、ドキュメントで使用する要素と属性を定義する場所を指します。知っておくべきことは他にもたくさんありますが、それがその中心です。より多くの情報があります ここ 。