プロジェクトで Microsoft SQL Server 2005 の XML データ型を利用しています。チームの一部のメンバーと私は、XSD も使用する必要があると感じていますが、他の陣営のメンバーは、XML をアドホックに保ち、「型」として扱わないようにする必要があると感じています。
XML は、メンテナンスの悪夢である多くのテキスト構成ファイルに構造と中心性をもたらす努力です。
.NET 3.5/C# を使用しており、テーブルは適切なデータ型で設計されています。私の主張は、XML であるという理由でそのアプローチを打ち破る理由を考えることにおいて、私たちはすでに「型指向」であるということです。元の問題が発生したのは、テキスト ファイルに型がないためです。「タイプ」アプローチを使用しないと、同じ問題が発生する可能性があります。
XML スキーマの利点に関する私の理解が間違っている可能性があります。では、XML スキーマを使用する利点と欠点は何でしょうか?
XSD なしで XML のリポジトリを保持することは、(私の意見では) すべての型が VARCHAR(n) として宣言されているデータベースを持つことに似ています。どんな種類の入力が得られるかは気にしません。入力が必要なだけです。
XSD は、XML が期待するタイプの入力であることを保証します。それらは、まさに探しているものであるモデルに構造を与えます。
残念ながら、XSD の作成団体 (W3C) でさえ、XSD が非常に悪い技術であることを理解しています。とはいえ、その意図は必ずしも悪いものではありません。C# の主な利点の 1 つは、静的に型付けされることです。XML 文書を静的に入力すると、同じ利点が得られます。ここでおそらく最善の方法は、クラスをリバース エンジニアリングして、XML シリアライゼーション属性を使用してスキーマを生成することです。これを行うと、C# によって XML ファイル用のカスタム データ リーダーが作成され、パフォーマンスが大幅に向上します。
XML の最大のコストの 1 つは、文字列を解析する必要があることです。XML ファイル (構造など) についてより多くの仮定を立てるほど、パフォーマンスが向上する可能性があります。
最終的には、多くのことと同様に、開発者の時間のコストを正当化するのに十分なパフォーマンス上の利点が必要です。それとも、XSD を作成するコストを正当化するために、静的に型付けされたシステムを使用したいという強い欲求がありますか。
最終的には、プロジェクトのニーズによって何をすべきかが決まりますが、静的型付けとパフォーマンスは考慮すべき大きな利点です。
他の投稿や質問で述べたように、XSD は XML の適切な場所で適切な型を使用していることを保証し、その構造を変更する前によく考える必要があります。
しかし、私がそう言うことができるなら、XSDは本当に冗長です。そして、条件付きコンテンツを含む複雑な構造を記述するのは、時には本当に混乱することがあります。
願わくば、XSD が XML を検証する唯一の方法ではありません。はるかに簡単なアプローチはRelaxNGを使用することです。特に、XSD で想像できるよりもはるかに読みやすいコンパクトな構文を使用します。
利用可能な XML スキーマは XSD だけではありません。代わりに http://relaxng.org/ を使用してください。RelaxNG を使用すると、XSD のようにさらに別のデータ「言語」を学習する必要がなく、スキーマを XML で表現できます。
スキーマを使用する大きな利点の 1 つは、XML ドキュメントをどのようにレイアウトするかについて、プロジェクトの全員が同意できるようになることです。また、スキーマを使用することで、XML パーサーで検証を有効にすることができます。これにより、不適切な XML が指定されたためにコードの一部が失敗した場合に、簡単に判断できます。
欠点として、スキーマを維持するのは面倒な場合があり、プロジェクトによっては努力する価値がない場合があります。
スキーマがない場合は、すべての検証を自分で再実装することになります (または、まったく検証せず、無効な入力でクラッシュします)。XSD パーサー/バリデーターがそのすべての作業を行い、その分野の専門家によって最適化およびデバッグされます。なぜその作業をすべて自分でやり直すのでしょうか。
XML が開発された重要な理由は、XML が任意の数のコンピューター システム間でデータを交換するための広く受け入れられた標準になったため、より多くのソースからのデータをより多くの方法で使用できるようになったことです。