XMLが非常に悪い場合は、なぜ多くの人がXMLを使用するのでしょうか。
私はXMLの目的を理解していますが、XMLがいかに悪いかについて人々が不満を言うのをよく耳にしますか？何がそんなに悪いのか本当に分かりませんか？私は通常、「膨らんだ」と「遅い」という言葉を投げかけられます。
でもプログラマーとしては、主に何に使うのでしょうか？そして、あなたは本当にそれを「悪い」と考えていますか？...もしそうなら、非常に多くの人々がデータの転送にそれを使用するので...
Xmlは、それが設計されたもの-プラットフォームに中立で人間が読めるデータ転送プロトコル-に低レベルでデータ検証を実施するいくつかの機能を備えたものに最適です。この方法でXmlを使用する人は誰もが本当に不満を抱いているとは思いません。それは最も簡潔なワイヤーフォーマットですか？いいえ。しかし、もっと悪い選択肢があります。カスタムバイナリ形式を読み取るのと同じくらい高速ですか？いいえ。ただし、ビジネスパートナーは、使用しているスタックでそれを読み取ることができます。
ただし、問題は人間、特にエンタープライズアーキテクトとして知られる品種は悪であり、良いものを取り、悪いものにすることです。 Xmlの場合、今世紀の初めには、XmlがあらゆるIT問題の普遍的なハンマーであると見なされていました。委員会による小さなデザインを散りばめると、SOAP and oXML のような恐ろしい怪物ができてしまいます。どちらも敵に望まれるべきではなく、友人や同僚に気にしないでください。
XMLは、多くのフレーバーと用途で提供されるツールにすぎません。 XMLは、いくつかの点で優れており、他の点で劣っています。問題の1つは、名前空間が必要以上に複雑で「SOAPだれか」が散らばっている「エンタープライズ」XMLを見たことがあるということです。人間向けのXML形式を設計するコツは、データに本当の意味を追加する一方で、データを読みにくくすることではありません。
人々が問題とすることの1つは、XMLが時々、ある文字または欠落している括弧で窒息することです。しかし、それでも良い面と悪い面があります。利点は、セミインバリッド構文の異なるケースが異なる方法で解釈される可能性があるHTMLのような曖昧さがないことです。
欠点は、作成するのが少し難しく、学ぶのが難しいことです。 HTMLがXMLと同じくらい厳格だったとしても、Webがそれほど速くはならなかったであろうという議論があることに同意しますが、今日それができれば嬉しいとも主張します。 :)
また、できる限りというわけではありませんので、適切に適用する感覚と判断力をもってください。あなたが持っているすべてがXMLである場合、あなたはいつもあなたが望むものから離れたXSLT変換になる傾向があります。 :)
このフォーマットは、人間が操作する必要がある場合にのみ重要であると私は主張します。何かをシリアル化し、別のプログラムが使用する場所に送信するプログラムを書いている場合、できるだけ効率的になるように、誰がどのように見えるかを気にしますか？私が気にするすべてのものには、バイナリ形式またはバニーとユニコーンを使用してください。
XMLの長所
- YAMLとJSONが対応しない多くのEdgeケースをカバーします
- さまざまなプラットフォームや言語でXMLを解析および検証するための優れたツールがあります
- XMLは（XSLTなどを介して）別の形式に簡単かつ強力に変換できます。
- 合理的なXML文書は、人間が簡単に読んで編集できるものです。 JSONの方が簡単だと言わないでください。
- XMLはある程度自己記述的です。つまり、XMLはその構造と意味に関する情報を直接含んでいます（ほとんどのバイナリ形式とは対照的です）。
- エンコーディングを処理します
- 空白にとらわれず、クロスプラットフォームでの使用を容易にする
- 整形式でない場合は中断します（データが構造的に正しいことを確認します）
- SGMLではない
短所
- 冗長
- バイナリのように解析するのは速くありません
- 整形式でない場合は壊れます（アプリケーションがクラッシュします）
良い使い方
- 設定ファイル
- データ交換フォーマット
- バージョン復元力のあるファイル形式
- データベースへのドキュメントの保存
あまり良くない使い方
- データ転送フォーマット
- オブジェクトのシリアル化
- リレーショナルデータをデータベースに保存する
- 高性能I/Oシナリオのファイル形式
Jeff Atwoodは XML：The Angle Bracket Tax にかなり良いブログ記事を投稿しています。
私の最も一般的な用途は次のとおりです。
互いに話し合うサービス。たとえば、コンテンツ管理システムを使用するWebサイトは、データを顧客関係管理システムに送信する必要があり、これはXMLで行われます。
構成ストレージ。 Web.configとapp.configは一般的な例ですが、nAntスクリプトもいくつかのXMLを使用できます。
私はそれが最適だとは思いませんが、それだけで私の心に悪いことはありません。
2つの理由：
- 世の中にはひどい悪いプログラマーがたくさんいます。 XMLは悪いかもしれませんが、それはまた（少なくとも表面的には）単純であり、悪いソフトウェアを非常に簡単に書くことができます。 VBのようなソルタ。
- これらの決定を行う多くの人々はプログラマーではありませんが、「誰もがXMLを使用している」と聞いただけのビジネスタイプであるため、彼らの製品にもXMLを使用したいと考えています。
私は通常、「膨らんだ」と「遅い」という言葉を投げかけられます。
これは最もコンパクトな構文ではありませんが、明らかに最も表現力のある構文です。人間が読める？言語の設計方法によって異なります。ほとんどの人はXML用の言語を設計せず、オブジェクトをXMLとしてシリアル化するだけです。
…なぜ多くの人がそれを使うのですか？
それは至る所にあります。 XQueryを使用してXMLデータベースにクエリを実行し、XSLTを使用して結果をXHTMLまたはAtomとして変換し、Atomまたは他のWebサービスから他のXML形式を取得し、XFormsを使用してユーザーからXMLを取得し、XMLSchemaを使用して検証します。 、リラックスNGまたはSchematron、XProcで処理し、XQuery Updateでデータベースに保存します。これらのツールはすべてXMLを理解しているため、異なる表現間でマッピングする必要はありません。
XMLはシリアル化テクノロジではなく、汎用の情報セットです。
ここでは、異なる内部表現を持つ異なるベンダーによって作成された異なるシステム間のデータ交換に使用します。 XML変換/交換システムを構築して、データを往復させます。それはうまくいきます。
XMLは本質的に悪いわけではありませんが、XMLを使用して「良い」ソリューションを設計することは簡単ではないことを認めます。
「XMLの本質はこれです。XMLが解決する問題は難しくなく、問題をうまく解決しません。」 -Phil Wadler、POPL 2003
私の個人的な意見では、検証、スキーマ、XSLT、その他の醜いものについて気にせず、ファイルのサイズを小さく保つ（そうしないと解析が遅くなる）限り、XMLのいくつかの良い使用法を見つけることができます（例INI files）を使用する代わりにアプリケーションを構成するためのものです。
私の経験では、人々は主にテクノロジー自体ではなく、それが使用される方法について不満を述べています。
人々が不満を言う肥大化した遅いビットは、通常、そこから情報を取得するために使用されるライブラリ/メソッドです。
私は、ディスクに保存したい（データベースやバイナリシリアル化なしで）少量の構造化情報を保存したり、別のアプリケーションに渡したりするために使用します（基本的にSOAPについても記述しています）。
良い理由：
その標準"Interface"は、複数の異種システムが通信に使用できます。そして、「人間」は読み取り可能です（一種、5 MB XMLで開始してみてください）
悪いのは：
肥大化した大きなサイズ=より多くの帯域幅=より多くの$$
他の理由もあります、誰もが異なる不満を持っています...
他のテクノロジーと同様に、多くの利用可能なツールとライブラリがあります。
私はXMLが好きではありません。特にファンキーなので、人が読めると言ったとき、冗談だと思うか、属性にxmlを埋め込もうとしたときに実際にxmlを読んだことがない... XMLエンティティが本当に読めない。さらに、冗長な終了タグとフリーテキストとデータを混在させる機能により、どれだけのスペースが無駄になるかは驚くべきことです...
しかし：
- Xmlを指定でき（xsd）、Xmlデータの適合性をチェックするツールを利用できます
- 多くのツール（テキストエディターなど）がXmlをサポート
- 多くのライブラリ（ほぼすべてのプログラミング言語）がXmlをサポートしています
また、ほとんどの場合、優先順位の利点もあります。すでにWebサービスをXmlで提供していて、新しいサービスを要求する場合...それはあなたが知っていることなので、おそらくXmlで行われます。