XML 名前空間は何のためにあるのでしょうか?

https://stackoverflow.com/questions/128389

02-07-2019
|

質問

これは私がいつも思うことですが、他の人に説明するのは少し難しいです。XML 名前空間はなぜ存在するのでしょうか?いつ使用すべきで、いつ使用すべきでしょうか?XML で名前空間を扱うときによくある落とし穴は何ですか?

また、XML スキーマとどのように関係するのでしょうか?XSD スキーマは常に名前空間に関連付けられるべきですか?

解決

これらは、要素名と属性名の競合を心配することなく、複数のマークアップ言語を組み合わせることができるようにするためのものです。

たとえば、XSLT コードの一部を見て、名前空間を使用せず、出力に「template」、「for-each」などの要素を含める必要がある XSLT を記述しようとした場合に何が起こるかを考えてください。。構文エラー、それは何ですか。

アドバイスや落とし穴については、私より経験豊富な他の人に任せます。

他のヒント

XML 名前空間はなぜ存在するのでしょうか?

なぜなら、1997 年当時、W3C の一部の非常に影響力のある人々がそれらを望んでおり、ノーという答えを受け入れなかったからです。彼らが抱えていると考えていた「問題」を解決するより良い方法があることが証明されたときでさえ、彼らは依然として自分たちの願望をW3C勧告に書き起こすために影響力を行使していた。

XML 名前空間をめぐる今では広まっている神話の最大の驚きは、XML 名前空間には技術的なメリットがあるということです。(これは、どこかに忘れられやすい脚注とは対照的に、推奨事項が単純に存在し、マインドスペースを占有することによる下流効果です。「おい、きっと (良い) 理由があるはずだ!」。)

多くの痛みを伴うが、何も得るものはない.

いつ使用すべきで、いつ使用すべきでしょうか?

できる限りそれらを使用しないでください。残念なことに、利害関係者によるこの悪い[*]デバイスの執拗な宣伝により、今日では仕様のクラスターファックが促進され、ある時点で XML 名前空間と競合しないようにすることが事実上不可能になっています。そのため、たとえ XML 名前空間を自分で避けていたとしても、名前空間にまみれたゴミがあらゆる方向から襲いかかってくることになるでしょう。さらに悪いことに、そのようなゴミを与えないと動作を拒否するツールセットが現れることになります。

XML で名前空間を扱うときによくある落とし穴は何ですか?

非常によくある落とし穴の 1 つは、名前空間が「デフォルト」になっているドキュメントで Xpath 式を使用することです。名前空間は式で明示的に指定する必要があります。もう 1 つの問題は、ドキュメントを作成するときにそれらを「正しく」使用することです。彼らは何もないところから問題を引き起こす.

また、XML スキーマとどのように関係するのでしょうか?XSD スキーマは常に名前空間に関連付けられるべきですか?

XSD スキーマ仕様が、委員会のほぼ全員が XML 名前空間に興味を持っていた時期に開発されたことを除けば、必要な関係はありません。そこで彼らは可能な限り深くそれを練り込みました。それでも、名前空間なしで XSD スキーマを使用することは可能ですが、XSD スキーマをサポートするほぼすべてのツールセットは、名前空間を使用することを「望んでいる」ことを前提としているため、これは険しい坂道です。

[*] BAD = 設計どおりに壊れています

アップデート：非問題に対する非解決策についての古いエッセイ.

これは、「なぜ Java/C# にパッケージを使用するのですか?」と尋ねることとほぼ同じです。

再利用性:定義した一連のタグ/属性を、さまざまな種類の XML ドキュメント間で再利用できます。
モジュール性:XML に何らかの「側面」を追加する必要がある場合。XML ドキュメントに名前空間を追加することは、XML スキーマ定義全体を変更するよりも簡単です。
「メイン」名前空間を汚染しないようにする:パーサーに巨大なスキーマ定義を強制的に処理させる必要はなく、必要な名前空間を使用するだけです。

私見による最大の落とし穴は、文書を解釈する人間のやりとりです。XML ドキュメントを処理するコードを開発します。文書を解析した情報セットの結果ではなく、文書のリテラル表現に注目するのは簡単です。

例えば次のノード

<a xmlns="uri:foo"/>
<foo:a xmlns:foo="uri:foo"/>
<bar:a xmlns:bar="uri:foo"/>

意味的にはすべて同じですが、素朴な目には大きく異なります。

最初の例では、XPath の開発時に非常によくある間違いが発生します。つまり、「a」が名前空間にあるという事実が欠落しており、そのため //a では一致が得られません。(さらに悪いことに、別の名前空間内のノードが一致することもあります!)

3 番目の例では、プレフィックステキストが意味的に重要であるという理解に別の欠陥が生じます。XPATH を使用してドキュメントを解析するとき、URI がドキュメントの URI と一致する限り、一致する任意のプレフィックスを宣言できます。

それらは要素タイプの名前であると考えてください。あなたにボブという名前の友人が 2 人いて、そのうちの 1 人のことを話している場合、誰かがどのボブのことを話しているのかと尋ねるかもしれません。「ボブ」と言うだけではあまり役に立たないので、「ボブ・スミス」または「ボブ・ジョーンズ」と言います。

要素の型も同様です。異なる人が同じ名前を付ける可能性があるため、短い名前では不十分な場合があります。したがって、世の中のさまざまなボブを区別するために、「姓」として URI を含めます。

XML はスーパー言語であり、XML ベースの言語の基礎であることを意味します (当然ですよね?)。XML は、あらゆる言語であらゆる文章を書くことができるペンのようなものだと考えてください。それはすべて書き手次第であり、できればその言語は読者に知られている必要があります。

XML 名前空間 基本的には、「英語」や「עברית」と同じように、言語の名前です。XML ドキュメントの受信者が XML ドキュメントを解析して、そこに含まれる情報を抽出できるように支援します。

私が家具工場を経営し、あなたが家具店を経営しているとします。あなたのストレージアプリケーションと私の供給アプリケーションはまったく無関係ですが、XML メッセージを通じて通信する場合、メッセージは双方で理解でき、簡単に解析できる必要があります。

したがって、両方のシステムが次のことを知る必要があります。 スキーマ, 、言語の構文と合意された制限を定義します。スキーマを辞書や文法の教科書と考えてください。スキーマは、両方のシステムが知っておく必要があり、各システムで解析コードを作成する人が知っておく必要があるドキュメントであり、名前空間の宣言が含まれます。

各名前空間は URI として名前が付けられ、ほとんどの場合、それを定義するスキーマドキュメントの場所になります。

もちろん、特に情報をリモートシステムに伝達するために使用されない場合、すべての XML ドキュメントに名前空間が必要なわけではありません。たとえば、データベースに保存するためにオブジェクトを XML にシリアル化する場合です。

私たちが名前空間を使用するのは、人々が自分たちのプライベートなアイダホ州で同じ言葉を異なる意味に使いたがるからです。通常、その人が何を意味するのかは文脈から判断できます。人事データベースでは、XML は人事レコードです。車両登録データベースでは、XML は車両登録レコードです。

どちらも「location」という名前のタグを保持しますが、タグの意味はそれぞれ異なり、含まれるフィールドも異なります。

それは素晴らしいことです:しかし、両方の XML を同じデータベースに保存する必要がある場合、または保存したい場合はどうすればよいでしょうか?または、さらに興味深いことに、両方のデータベースが他の共通データベースからの 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 ログファイルを検索できるため、表示されているすべてのアカウントの期限切れメッセージを抽出できます。 他のシステムによって生成された「メッセージ」タグと混同することはありません, それらを xhtml に変換し、CSS タグを介して太字の赤色で表示します。 手続きコードを一切書かずにすべて完了.

例えば： XML 名前空間の例

私の言葉で言えば、外部の会社 (たとえば、) に何らかの XML 形式を使用する必要があり、同じ名前の情報を XML ドキュメントに提供する必要がある場合は、ネームスペースが必要です。例：

<sampleDoc>
   <header title="Hello world!">
      <items>
         <item name="Volvo" color="Blue"/>
      </items>
   </header>
</sampleDoc>

同じ名前を持つこのドキュメントにデータをマージしたい場合は、名前空間を使用する必要があります:

<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 参照によって識別される名前空間に関連付けることによって修飾する簡単な方法を提供します。

ネームスペースは、ドキュメント内で使用する名前の曖昧さを解消するために使用されます。また、短縮名を名前空間にバインドして、リモートの要素または属性を参照するために使用できるようにすることもできます。ネームスペース自体は、ドキュメント内で使用する要素と属性を定義する場所を指します。知るべきことはまだたくさんありますが、それが中心です。さらに多くの情報がありますここ.

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow