2

私が Oslo で見てきたことによると、宣言型 XML が重要な役割を果たします。実際のアプリケーションを作成するために、多くのデザイナーが生成した XML をいじることは期待できますか? 私がこれを研究していないことを知ってください。あなたが主題を調べたなら、私はあなたの視点に感謝します.

いくつかの背景...

XML を利用した宣言型テクノロジ (Silverlight や WPF、ASP.NET、MSBuild など) の真下を掘り下げると、生の XML テキストを大量に編集することになります。デザイナーが私のニーズを十分に表現してくれることはめったにありません。

一方で、人間と機械の可読性の間で妥協点が改善されているとは思えません。公平を期すために言えば、XML 編集のエクスペリエンスは、具現化するたびに改善されています。

一方で、XML がその用途のいくつかに理想的であるとは思いませんでした。特にロジックの表現、リファクタリングとテスト容易性に関しては。デザイナーが弱すぎるか、XML の表現力が強すぎるか、または私が不機嫌すぎてオブジェクトやメソッドに甘やかされている可能性があります。

4

2 に答える 2

3

私は、やや疑わしい XML の擁護者になりがちです。私は XML ベースの Web サービスを日常的に使用しており、XML ベースの Web サービスは私のキャリアの大部分を占めてきました (そして、私が書いた本の基礎となっています) にもかかわらず、広く使われすぎていると思います。私は、ツールボックスに多くのツールを用意し、仕事に最適なツールを使用する必要があると考える考え方に属しがちです。XML が優れたソリューションとなるものはたくさんあります。しかし、そうでないものもたくさんありますし、おそらくひどい選択になるものもあります。

XML を批判して回避することに熱心な人がいるのと同じように、XML を称賛して使用することに熱心な人もいます (またはそれ以上に熱心な人もいます)。上記でさりげなく言及しているケースでは、ほとんどの場合、Web ベースのテクノロジについて話していることになります。このような場合、通常、XML パーサーや DOM マニピュレーターは既に利用可能になっているので、それを利用しても害はありません。複雑さはすでに存在していたので、複雑さを増していません。Flash と AIR は機能のために XML を多用しますが、それらは XML 風のマークアップ (XML 自体ではない場合、HTML または XHTML) の解析がすべてのアプリケーションのコア部分である環境を対象としています。これらのテクノロジでは、別の種類のデータ表現言語を導入すると、複雑さが増します。XML を使用することは完全に理にかなっています。

ここに例があります...ここで問題となっている言語はPerlです。これは私が主に使用しているためですが、Perlの側面は要点とは関係ありません:私は深いデータをダンプする既存のモジュールの拡張に取り組んできました構造。シリアル化、プラットフォーム間での移植性など、多くのことに役立ちます。また、デバッグ用の一般的なツールでもあります。それを拡張したい理由は、本当に大規模で複雑な構造 (ORM や MOP フレームワークによって生成されたものなど) はかなり複雑になる可能性があるためです。そこで、私が最初に考えたのは、データを HTML に変換できる拡張機能を作成して、ある程度制御できるようにすることでした。そこで、いろいろな要素がどの要素につながっているのか、などを図で表せたらいいなと思いました。合理的で中立的な形式を選択すれば、それらの両方をかなり簡単に導き出すことができるはずだと思いました。

その形式？XML。この場合、ネイティブの Perl シリアライゼーション構造よりも、または別の中間表現 (YAML や JSON など) を使用するよりも優れているのはなぜでしょうか? 有効で整形式の XML があれば、XSLT を使用して簡単に (X)HTML または SVG に変換できるからです。必要に応じてプレーン テキストに変換することもできます (ユーザーの選択に応じて、HTML フラグメントまたはきれいにワードラップされたプレーン テキストを出力することを選択する XSLT スタイルシートが既にあります)。

この特定の問題を解決する方法はたくさんありますが、この場合にXML がもたらす利点により、(少なくとも、私の好みとニーズにとっては) XML を選択することをお勧めします。XSLT は、明確に定義され、十分に文書化されている (W3C のドキュメントに関しては意見が異なるかもしれませんが、このテーマに関する本は不足していません) XML をほとんど何でも変換するためのツールです。この特定の問題については、XML の表現力と、私の最終的なターゲット形式 (XHTML および SVG) 自体が XML であるという事実を組み合わせることで、XML を選択することが明確になりました。一方、(コンサルタントとして) クライアントに、または (会社の従業員/チーム メンバーとして) 上司/チームに、XML を使用すべきではないことを勧めたことが何度もありました。何らかのタスクに使用されます。理由が明らかな場合もあります。XML を使用してもデータの (再) 利用性が向上しない、彼らはまだプロジェクトで XML を使用しておらず、これはその依存関係を導入する必要があるものではなかった、などです。 . 理由がより微妙な場合もあります。アプリケーションの構成を保存/取得する方法を決定しようとしている場合、それは本当に XML である必要がありますか? 他のアプリケーションがこれを読み取り/解析する必要がある可能性はほとんどないため、データの移植性/再利用は問題になりません。データが本質的にかなりフラットな場合は、おそらくキーと値のペアのファイルで管理できます。データがより複雑または複雑な場合は、YAML で問題ない可能性があります。

一般に、XML は、最良の選択である場合を除いて、データ表現には最悪の選択です。JSON と YAML についても同じことが言えます。これらのアプローチを最大限に活用する最善の方法は、それらすべてに精通し、快適に使用できるようにし、目の前の仕事に最適なツールを知ることです。あなた。

于 2008-10-20T23:27:55.407 に答える
2

質問の魔法の言葉は「宣言的」だと思います。

柔軟性のある宣言型テクノロジには、宣言の形式が必要です。宣言が構文的に正しいことを検証する方法が必要です。基になるデータ構造をこの形式にシリアライズおよびデシリアライズできる必要があります。フォーマットが十分にオープンで、宣言を生成、変更、または処理するツールを簡単に作成できる場合は、非常に有益です。

これがどこに向かっているのかがわかります。

あなたが見ている問題は本当だと思いますが、それが本当に XML の問題だとは思いません。まあ、直接ではありません。本当の問題は、あなたが言ったもう 1 つの点にあると思います。これらの宣言型テクノロジの設計ツールは十分に強力ではありません。

そして、これが一種の XML の問題である理由は次のとおりです。JSON を製品のシリアル化形式として使用していた開発者は、「この機能を実装する必要はなく、ユーザーは JSON を編集するだけでよい」と考えることはできません。 "

そこが問題だと思います。宣言を表すのに XML が悪い形式であるというわけではありません。それは、XML のオープン性が非常に魅力的だということです。これにより、ツール開発者は、ツールから機能を除外することを回避する方法を得ることができます。

それは技術的な問題ではなく、社会的な問題だと思います。そして、それは難しい問題です。XAML の代わりに Microsoft がクローズド フォーマットを考え出していれば、おそらくはるかに優れた WPF ツールを使用できたでしょう。しかし、私たちはオープンフォーマットからあまりにも多くのものを得て、それを放棄することはできません.

于 2008-10-21T01:00:52.473 に答える