XML はほぼ常に悪用されます

XML 言語は 1996 年に発明されました。それが登場するやいなや、その応用の可能性はすでに誤解され始めており、彼らがそれを適応させようとしていた目的にとって、それは最良の選択ではありませんでした。

私がこれまで見てきた XML スキーマの大部分は、XML の不適切または不正確な使用法であったと言っても過言ではありません。さらに、この XML の使用は、XML の本質についての根本的な誤解を示しました。

XML はマークアップ言語です。 これはデータ形式ではありません。ほとんどの XML スキームはこの区別を明確に無視しており、XML とデータ形式を混同しており、実際に必要とされるデータ形式である XML が最終的に XML の選択を誤ることになります。

あまり詳しく説明しませんが、XML はテキストのブロックに構造とメタデータで注釈を付けるのに最適です。主な目的がテキストのブロックを操作することではない場合、XML を選択することは正当化される可能性は低いです。

この観点から、XML スキーマがどの程度適切に作成されているかを確認する簡単な方法があります。例として、目的のスキーマ内のドキュメントを取り上げ、そこからすべてのタグと属性を削除してみましょう。残っている内容が意味をなさない場合 (または空白行が残っている場合)、スキーマが正しく構築されていないか、単純に XML を使用すべきではなかったかのどちらかです。

以下に、誤って構築された回路の最も一般的な例をいくつか示します。

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

ここでは、単純なキーと値の辞書を XML で表現しようとする、根拠のない奇妙な (ただし、非常に一般的な) 試みの例を示します。すべてのタグと属性を削除すると、空の行が残ります。本質的に、この文書は、どんなに不条理に聞こえるとしても、空行の意味論的な注釈です。

<root name="John" city="London" />

さらに悪いことに、ここでは辞書を表現する贅沢な方法として空の文字列のセマンティック アノテーションを使用しているだけではありません。今回は「辞書」がルート要素の属性として直接エンコードされています。これにより、要素上の指定された属性名のセットが未定義で動的になります。さらに、作成者が実際に表現したかったのは単純なキーと値の構文だけだったのに、その代わりに XML を適用するというまったく奇妙な決定を下し、属性構文を使用するためのプレフィックスとして 1 つの空の要素の使用を強制したことも示しています。そして、私はそのような計画に頻繁に遭遇します。

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

これはより良いものですが、何らかの理由でキーはメタデータになり、値はメタデータではなくなりました。辞書を見てみるととても不思議です。すべてのタグと属性を削除すると、情報の半分が失われます。

XML の正しい辞書式は次のようになります。

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

しかし、人々が XML をデータ形式として使用し、それを語彙の整理に使用するという奇妙な決定を下した場合、彼らは自分たちが行っていることが不適切で不便であることを理解する必要があります。設計者がアプリケーションを作成するために誤って XML を選択することもよくあります。しかし、さらに多くの場合、XML が単純にこれには適していないという事実を無視して、上記の形式のいずれかで XML を無意味に使用することで問題を悪化させます。

最悪の XML スキーマ? ちなみに賞品は、 私が今まで見た中で最悪の XML スキーマ Polycom IP テレフォニー電話の自動プロビジョニング設定ファイル形式を取得します。このようなファイルには、TFTP 経由で XML 要求ファイルをダウンロードする必要があります。一般的に、以下はそのようなファイルの 1 つからの抜粋です。

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

これは誰かの悪い冗談ではありません。そして、これは私の発明ではありません。

• 要素は単に属性を付加するためのプレフィックスとして使用され、それ自体が階層名を持ちます。
• 特定の種類のレコードの複数のインスタンスに値を割り当てる場合は、属性名を使用する必要があります。 インデックスがあるもの.
• また、で始まる属性は、 softkey.、要素上に配置する必要があります <softkey/>、で始まる属性 feature.、要素上に配置する必要があります <feature/> など、それは完全に不必要で一見無意味に見えるという事実にもかかわらず。
• 最後に、属性名の最初のコンポーネントが常に要素名と同じであることを期待しているとしたら、そのようなことはありません。たとえば、属性 up. に添付する必要があります <userpreferences/>。要素に属性名を付ける順序は、ほぼ完全に任意です。

書類とかデータとか。時々、誰かが XML と JSON を比較しようとして、まったく奇妙なことを行い、どちらも理解していないことを示します。 XML はドキュメント マークアップ言語です。 JSON は構造化データ形式であるため、それらを比較することは、ウォームとソフトを比較しようとするようなものです。

の違いの概念 書類とデータ。 XML の類似物として、条件付きで機械可読ドキュメントを取得できます。これは機械可読であることを目的としていますが、比喩的にドキュメントを指し、この観点からは実際には、ほとんどの場合機械可読ではない PDF ドキュメントに相当します。

たとえば、XML では要素の順序が重要です。しかし、JSON では、オブジェクト内のキーと値のペアの順序は無意味であり、定義されていません。キーと値のペアの順序なしの辞書を取得したい場合、そのファイル内に要素が現れる実際の順序は関係ありません。ただし、このデータからさまざまな種類のデータを作成できます。 ドキュメント文書には特定の順序があるためです。比喩的に言えば、これは紙上の文書に似ていますが、印刷出力や PDF ファイルとは異なり、物理的な寸法はありません。

適切な XML 辞書表現の例は、JSON 表現とは対照的に、辞書内の要素の順序を示しています。この順序を無視することはできません。この直線性はドキュメント モデルと XML 形式に固有のものです。この XML ドキュメントを解釈するときに順序を無視することを選択する人もいるかもしれませんが、この問題は形式自体の議論の範囲を超えているため、これについて議論するのは意味がありません。さらに、カスケード スタイル シートを添付してドキュメントをブラウザで表示できるようにすると、辞書要素が特定の順序で表示され、他の順序では表示されないことがわかります。

つまり、辞書（構造化データ）は次のように変換できます。 n さまざまなドキュメント (XML、PDF、紙など) が考えられます。 n - 辞書内の要素の可能な組み合わせの数。他の可能な変数はまだ考慮されていません。

ただし、データのみを転送したい場合は、機械可読ドキュメントを使用しても効果的ではないということになります。モデルを使用しますが、この場合は不必要であり、邪魔になるだけです。また、ソースデータを抽出するにはプログラムを記述する必要があります。ある時点でドキュメントとしてフォーマットされないもの (たとえば、CSS または XSLT、またはその両方を使用する) に XML を使用することは、それがそうする主な (唯一ではないにしても) 理由であるため、ほとんど意味がありません。ドキュメントモデルに。

さらに、XML には数値 (またはブール式、またはその他のデータ型) の概念がないため、この形式で表されるすべての数値は単なる追加テキストとみなされます。データを抽出するには、スキーマと、表現されている対応するデータとの関係を知っておく必要があります。また、コンテキストに基づいて、特定のテキスト要素が数値を表し、数値に変換する必要がある場合などを知る必要もあります。

したがって、XML 文書からデータを抽出するプロセスは、たとえば、多数のページの数値データを構成する表を含むスキャンされた文書を認識するプロセスとそれほど変わりません。はい、原則としてこれを実行することは可能ですが、他に選択肢がまったくない場合の最後の手段を除いて、これは最適な方法ではありません。合理的な解決策は、データとその特定のテキスト表現を組み合わせたドキュメント モデルに埋め込まれていない元のデータのデジタル コピーを単純に見つけることです。

とはいえ、XML がビジネスで人気があることにはまったく驚きません。その理由は、まさに（紙の）文書形式がビジネスにとって理解しやすく馴染みがあり、使い慣れていてわかりやすいモデルを使い続けたいと考えているからです。同じ理由で、企業は、より機械可読な形式ではなく、PDF ドキュメントを使用することが多すぎます。これは、特定の物理サイズを持つ印刷ページの概念に依然として結びついているためです。これは、印刷される可能性が低い文書 (たとえば、レジ​​ストリ文書の 8000 ページの PDF) にも当てはまります。この観点から見ると、ビジネスにおける XML の使用は本質的にスキューモーフィズムの現れで​​す。人々は、限られたサイズの印刷ページという比喩的な概念を理解し、印刷されたドキュメントに基づいてビジネス プロセスを作成する方法を理解しています。それがあなたのガイドであるなら、機械可読で物理的なサイズの制限がないドキュメント (XML ドキュメント) は、使い慣れた快適なドキュメントであると同時に、革新性を表します。これは、データを表示する不正確で過度にスキューモーフィックな方法のままであることを防ぐものではありません。

現在のところ、私が知っている、この形式の有効な使用法と言える XML スキーマは、XHTML と DocBook だけです。

出所： habr.com