XMLの弱点は何ですか？ [閉まっている
https://stackoverflow.com/questions/3580819
-
01-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
Stackoverflowを読んで、Joel SpolskyとJeff Atwoodのポッドキャストを聞いて、私は多くの開発者がXMLまたは少なくとも使用を嫌うと信じ始めます データを保存または交換するために、XMLをできるだけ使用しないようにしてください.
一方、私はいくつかの理由でXMLをたくさん使うことを楽しんでいます：
- XMLシリアル化はほとんどの現代言語で実装されており、 非常に使いやすい,
- バイナリシリアル化よりも遅いため、XMLシリアル化は、 いくつかのプログラミング言語から同じデータを使用します または、人間によるデバッグのためであっても、読んで理解することを意図している場合（たとえば、JSONはより困難です）、
- XMLサポート Unicode, 、そして適切に使用すると、異なるエンコード、文字などに問題はありません。
- XMLデータを簡単に操作できるツールがたくさんあります。 XSLT 例であり、データを簡単に表示し、データを変換できます。 xpath 別のものです。データを簡単に検索できます。
- XMLは一部のSQLサーバーに保存できます。これにより、データが表示されるときのシナリオが可能になります。 複雑すぎて、SQLテーブルに簡単に保存できません 保存して操作する必要があります。たとえば、JSONまたはバイナリデータは、SQLを直接操作することはできません（ほとんどの状況でクレイジーな文字列を操作することを除きます）
- XMLは、アプリケーションをインストールする必要はありません。アプリにデータベースを使用したい場合は、最初にデータベースサーバーをインストールする必要があります。アプリにXMLを使用したい場合は、 何もインストールする必要はありません,
- XMLははるかに多くです 明示的で拡張可能 たとえば、WindowsレジストリまたはINIファイルよりも、
- ほとんどの場合、あります CR-LFの問題はありません, 、XMLが提供する抽象化のレベルに感謝します。
それで、XMLを使用することのすべての利点を考慮に入れて、なぜそんなに多くの開発者がそれを使用することを嫌うのでしょうか？私見、それの唯一の問題は次のとおりです。
- XMLはあまりにも冗長です 特にBase64エンコードに関しては、他のほとんどの形式のデータよりもはるかに多くの場所が必要です。
もちろん、XMLがまったく適合しない多くのシナリオがあります。 XMLファイルにSOの質問と回答を保存する サーバー側 絶対に間違っています。または、AVIビデオまたはJPG画像の束を保存するとき、XMLは使用するのが最悪のものです。
しかし、他のシナリオはどうですか？ XMLの弱点は何ですか？
この質問は本当の質問ではないと考えた人々にとって：
非閉鎖のような質問に反して 1980年以来のコンピューティングにおける重要な新しい発明, 、 私の質問 は 非常に明確な質問であり、明らかに、他の人がXMLを使用する際にどのような弱点を経験し、なぜそれを嫌うのかを説明することを明確に招待します。たとえば、議論することを招待しません XMLが良いか悪いか. 。また、拡張された議論も必要ありません。したがって、これまでに受け取った現在の回答は短く正確で、私が望んでいた十分な情報を提供します。
だが それはウィキです。 個性的 この質問に対する良い答え。
そうによれば、「本当の質問ではない」は質問です 「ここで何が尋ねられているのかを伝えることは困難です。この質問は曖昧で、あいまいで、不完全であるか、修辞的であり、現在の形で合理的に答えることはできません。」
- ここで何が尋ねられているのか: ：質問自体は非常に明確であり、上記のテキストのいくつかの段落により、さらに明確になります。
- この質問は曖昧で、あいまいで、不完全です: ：繰り返しますが、あいまいなものは何もありませんし、曖昧でも不完全でもありません。
- または修辞的: ：そうではありません：私の質問に対する答えは明らかではありません、
- 合理的に答えることはできません: ：数人の人々がすでに質問に素晴らしい答えを出し、質問が合理的に答えることができることを示しています。
また、回答を評価し、受け入れられている答えを決定する方法は非常に明白なようです。答えがXMLの何が問題なのかという正当な理由を与えた場合、この答えが投票され、受け入れられる可能性があります。
解決
いくつかの弱点：
- XMLファイルと外部リソースを関連付けることはやや困難です。そのため、新しいOffice Documentフォーマットは、スケルトンXMLファイルとリソースファイルを含むZIPエンベロープを使用しています。 base64エンコードを使用するもう1つのオプションは非常に冗長であり、ランダムアクセスが良好ではありません。これは次のポイントになります。
- ランダムアクセスは困難です。 XMLファイルを読み取る2つの従来のモードのいずれも、DOMまたはForwardのみのSAXスタイルの読み取りを作成することは、真にランダムなアクセスを可能にしません。
- ファイルのさまざまな部分への同時書き込みアクセスは困難です。そのため、Windows実行可能マニフェストでの使用はエラーが発生しやすい理由です。
- XMLファイルはどのようなエンコードを使用しますか？厳密に言えば、最初にエンコーディングを推測し、次にファイルを読んで、エンコードが正しいことを確認します。
- ファイルの一部をバージョンすることは困難です。したがって、粒状バージョンを提供する場合は、データを分割する必要があります。これは単なるファイル形式の問題ではなく、ツールが一般的にファイルごとのセマンティクスを提供するという事実によるものです。バージョン制御ツール、Dropboxなどの同期ツールなどです。
他のヒント
<xml>
<noise>
The
</noise>
<adjective>
main
</adjective>
<noun>
weakness
</noun>
<noise>
of
</noise>
<subject>
XML
</subject>
<noise>
,
</noise>
<whocares>
in my opinion
</whocares>
<noise>
,
</noise>
<wildgeneralisation>
is its verbosity
</wildgeneralisation>
<noise>
.
</noise>
</xml>
私はXMLの大ファンであるので、私は尋ねるのにふさわしい人ではありません。しかし、私が聞いた主な不満の1つをあなたに伝えることができます：
そうです 難しい 一緒に働く。ここでは、APIを知る必要があり、XMLを解析するために比較的多くのコードを記述する必要があることを意味します。それは本当にそれほど難しいとは言いませんが、オブジェクトを説明するために作られた言語は、動的に作成されたオブジェクトをサポートする言語を使用する場合、より簡単にアクセスできることにのみ同意することができます。
一般的に、反応はXMLが過剰に使用されているからだと思います。
ただし、XMLについて嫌いな言葉が1つある場合、情熱を持っているのは名前空間です。名前空間の問題に関する生産性の失われたものは恐ろしいです。
XMLは、マークアップ言語のgreat孫であるSGMLから降ります。 SGMLの目的とXMLの目的は テキストの注釈. 。 XMLはこれをうまく行い、さまざまなアプリケーションの施設を増やす幅広いツールを備えています。
問題は、私が見るように、XMLがテキストに注釈を付けずに頻繁に使用されることです。 構造化されたデータ, 、これは微妙だが重要な違いです。実際には、構造化されたデータはさまざまな理由で簡潔である必要があります。特に帯域幅が限られている場合、パフォーマンスは明らかです。これはおそらく、JSONがWebアプリケーションで非常に人気がある主な理由の1つです。ワイヤー上の簡潔なデータ構造表現は、より良いスケーラビリティを意味します。
残念ながら、JSONは余分な空白のパディングなしではあまり読みやすくありません。これはほとんど常に省略されています。一方、コマンドラインエディターを使用して大きなXMLファイルを編集しようとしたことがある場合は、非常に厄介なこともあります。
個人的には、私はそれを見つけます Yaml 両極端の間で素晴らしいバランスをとる。以下を比較します（からコピーします yaml.org わずかな変更があります）。
YAML：
invoice: 34843
date: 2001-01-23
billto: &id001
given: Chris
family: Dumars
address:
lines: |
458 Walkman Dr.
Suite #292
city: Royal Oak
state: MI
postal: 48046
shipto: *id001
product:
- sku: BL394D
quantity: 4
description: Basketball
price: 450.00
- sku: BL4438H
quantity: 1
description: Super Hoop
price: 2392.00
tax : 251.42
total: 4443.52
comments: >
Late afternoon is best.
Backup contact is Nancy
Billsmer @ 338-4338.
XML：
<invoice>
<number>34843</number>
<date>2001-01-03</date>
<billto id="id001">
<given>Chris</given>
<family>Dumars</family>
<address>
<lines>
458 Walkman Dr.
Suite #292
</lines>
<city>Royal Oak</city>
<state>MI</state>
<postal>48046</postal>
</address>
</billto>
<shipto xref="id001" />
<products>
<product>
<sku>BL394D</sku>
<quantity>4</quantity>
<description>Basketball</description>
<price>450.00</price>
</product>
<product>
<sku>BL4438</sku>
<quantity>1</quantity>
<description>Super Hoop</description>
<price>2392.00</price>
</product>
</products>
<tax>251.42</tax>
<total>4443.52</total>
<comments>
Late afternoon is best. Backup contact is Nancy Billsmer @ 338-4338
</comments>
</invoice>
どちらも同じデータを表していますが、YAMLは30％を超えており、間違いなく読みやすくなります。テキストエディターで変更する必要があるのはどれですか？ Yamlを解析して放出するために利用できる多くのライブラリがあります（つまり、Java開発者向けのSnakeyaml）。
すべてと同様に、適切なジョブに適したツールが従うのに最適なルールです。
私のお気に入りの厄介な問題は、XAMLなどの属性を使用するXMLシリアル化形式です。
これは機能します：
<ListBox ItemsSource="{Binding Items}" SelectedItem="{Binding CurrentSelection}"/>
これはそうではありません：
<ListBox SelectedItem="{Binding CurrentSelection}" ItemsSource="{Binding Items}"/>
XAML Deserializationは、XMLストリームから読み取られるときにプロパティ値を割り当てます。したがって、2番目の例では、 SelectedItem プロパティが割り当てられます、コントロール ItemsSource まだ設定されていません SelectedItem プロパティは、まだ存在するアイテムに割り当てられています。
Visual Studioが属性の順序を維持するため、Visual Studioを使用してXAMLファイルを作成する場合、すべてがクールになります。ただし、XMLツールでXAMLを変更します。XMLツールは、属性の順序が重要ではなく、少年はあなたが傷ついた世界にいると言っている場合にXMLの推奨を信じています。
