XSLTを使用、学習、または推奨する正当な理由はありますか？[閉まっている]

私は過去8年間、開発者です。主にXMLをHTMLに変換するためにXSLTを使用しました。また、XMLからXMLへの変換にも使用しました。

しかし、今ではすべての代替品があります。HTMLは、ASP.Netなどのプログラミング言語を使用して快適に作成できます。XMLは、標準の高水準言語で読み取って操作できます。XSLTでのプログラミングは少し複雑なので、誰もが最新のプログラミング言語で作業することを好みます。

さて、私の質問：すでに開発されたXSLTを維持するという事実を考慮せずに、XSLTは将来的に重要な選択肢になりますか？新しいプログラマーにXSLTの学習を勧めることはできますか？

XSLTが適切な選択になる重要なケースがいくつかあります。

• ETL（抽出、変換、ロード）ソフトウェアは、XSLTを使用できる場合があります。たとえば、抽出されたデータとロードするデータの両方がXML形式であり、アプリケーションを再コンパイルせずに変換を変更できる場合に適しています。

• データをXMLで保存する一部のアプリケーションは、XSLTを使用してこのデータを人間が読める形式で表示します¹。たとえば、Windows Live MessengerはメッセージのトレースをXMLとして保存しますが、WLM自体で履歴を開くと、実際にはXSLTで構築されたHTMLである美しいテーブルが表示されます。

• 一部の開発者向けまたはデータ指向のWebサイトでは、Webサイトのページをプログラムで使用することが目的である場合、XMLへのアクセスを許可する場合があります²。特にHTMLコードはいつでも変更できるので、HTMLパーサーを使用するよりもいくらか優れています。

• XSLTをWebサイトで使用すると、HTMLと分離コードを厳密に分離できるため、分離コードの開発者とHTML / CSSの開発者を雇うことができます。別の質問に対する私の回答のポイント1を参照してください。

XSLTは将来的に重要な選択肢になりますか？さて、これは今日の重要な選択ではありません。XSLTの使用が時間とともに増加するのではないかと思います。その理由は無視しますが、多くの開発者はXMLが好きではなく、XSLTが嫌いです。

新しいプログラマーにXSLTの学習を勧めることはできますか？もちろん！XSLTは、他のアプローチがより困難な状況で使用できるだけでなく、XSLTには他の言語にはない非常に特殊なアプローチがあります。

^{¹これは、XMLが実際には人間が読めるものではないことを意味します。ITで働いていない人にXMLを読むよう頼むと、彼は恐ろしくなります。
²Webサービスがあることは知っています。しかし、動的なオブジェクトを構築し、それをXMLにシリアル化し、XSLTを介してHTMLに変換するか、ボットがXMLに直接アクセスできるようにすることは、ページごとに簡単で簡単な場合があります。}

XSLTを使用しているのは少数の愛好家だけであるため、XSLTはほとんど死んでいます。しかし、それに代わる本当の選択肢はありません。たとえば、セマンティックドキュメントからHTMLページをレンダリングするなど、単一のユースケースのみに焦点を当てると、より優れたツールが見つかります。コード生成テンプレートエンジンを探す場合も、より優れたツールがあります。ドキュメント変換についても同じです。

しかし、これらすべてのユースケースをすべてのプラットフォームで十分にサポートするツールを探している場合、選択肢は非常に限られています。すでにXMLドキュメントがあり、それをツールを使用できるように変換する必要がある場合は、XSLT（またはXQuery）でデータを処理するだけの方がよいでしょう。

いずれにせよ、数日から数週間でXSLTを学ぶことができます。それはあなたが直接体験することを傷つけません。ちょっと試してみてください。この種のパターン（ルールベースの変換）を後で使用するために頭部に保存することは、少なくとも努力する価値があります。これだけでも、XSLTの学習を正当化できます。

うーん、コードからHTMLを作成する高レベルAPIが「内部」でXSLTを使用しているのでしょうか...

XSLTは、XMLを1つのソース形式から他のさまざまな形式に変換する作業で広く使用されています。XMLを非XML出力に変換するためにも使用できます。私はこれの多くをしていませんが、とりわけPDFとPostScriptをターゲットにするために行われたと聞いています。

はい。

良い例を見てみましょう：継続的インテグレーションの単体テストレポート。ほとんどの単体テストおよびコードカバレッジプログラムは、大量の読み取り不能なXMLを出力するだけです。ただし、いくつかの単純なXSLTを使用すると、同じデータから多数の有用なレポートを作成できます。そして、他の人はそれらのレポートを再利用できます。

これで、CIツールがプラグインに使用する任意の言語でこれらを作成できますが、その言語がわからない場合（たとえば、Jenkinsを使用して.NET開発者である場合）、それを学習する必要はありません。既にXSLTをXMLファイルに適用しているプラ​​グインを使用して、いくつかの便利なXSLTを作成します。

プログラミング言語には常に選択肢と多様性があり、ある言語が別の言語よりも優先される理由は、機能性、生産性、パフォーマンスなどの客観的な基準と同様に、親しみやすさとファッションに関係しています。誰もファッションを予測できないため、プログラミング言語の将来の傾向を予測することはできません。しかし、XSLTの最初の学習の障壁を乗り越えて、非常に幅広いタスク（おそらく取り組むために設計されたものよりも幅広いもの）にとって非常に生産的なツールであることに気付く人はたくさんいます。

XSLTが使用されていると思われる多くのタスク（および私がXSLTを自分で使用しているタスク）については、JavaまたはASPコードを作成してジョブを実行することは、雇用主の予算の恐ろしい無駄です。ただし、Javaの作成が得意で、XSLTの作成が得意でない場合は、おそらくそうではありません。

XSLTは人間が読める形式ではありません。メタ情報（タグ）は、実際の情報（テキスト、xpath要求）よりも多くの場所を占めます。良いコードはドキュメントのように見えるはずです。これは、XSLTの場合とはかなり異なります。これは、マッピングツールに適した永続化形式です。

優れた変換言語では、変換結果をプレビューし、同時に変換フロー（IF、ELSE、FOR、WHILE）を表示できます。これは保守性にとって重要です。この点に関して、VelocityまたはGenearateXYはXSLTよりも優れています。GenerateXYは、プレビューとフローを分離するので、Velocityでは、残念ながらプレビューのインデントを解除して読みやすいフローを提供する必要があるため、少しでも優れています。

XSLTの唯一の良い点は、「xsl：template」要素を使用し、さらに悪用することでモジュール性を重視することです。これの問題は、データ処理言語（Java、Cなど）には適していますが、プレゼンテーション言語には非常に副次的なことです。

確かに

学習して使用するのは少し面倒なので、いつか何かがXSLTに取って代わるでしょう。ただし、現在のところ、実装に柔軟性があり「純粋」なテンプレート/変換言語​​はありません。

XSL-Tは、いくつかの異なる目的に使用できます。

• テンプレートを使用して、データからHTML形式のコンテンツを「作成」できます
• あるxml形式から別のxml形式に変換できます
• xmlを別の形式に操作して、おそらくサブセットを表示できます

基本的にこれらはすべて同じですが、あるXMLデータファイルから別のXMLデータファイルへの変換です。ここで、XSLTの代わりに使用できるさまざまなツールを見てみましょう。

XHTMLページなどのコンテンツを操作したい場合、regexpを使用できますが、regexpは構造的なものでは面倒です。文字列の操作には適していますが、何かの目次を作成したり、別のレイアウトで表示したりするのには使いません。

次はASP.Netです。aspページにレイアウトを配置し、動的部分のコードビハインドを挿入します。別の方法は、レイアウトパーツを予測し、データベースなどからすべてを生成し、C＃を使用して目的の出力を作成することです。

最初のアプローチの問題は、説明的なデータから実際のコンテンツに移行するのが面倒だということです。各文字のヘッダーで表示したい電話番号を含むデータファイルがある場合、合計nrのエントリを表示するなど、レイアウトファイルと生成するコードにいくつかのレイアウトが必要です。 。別のオプションは、何らかの形のウェブグリッドを使用することです

完全に動的にすることは確かにオプションですが、それはかなり不器用です。LINQのようなものを使用している最良の場合でも、プログラミングコードと出力を混在させる必要があります。また、通常はhtmlである非構造化された再帰的なドキュメントスタイルのコンテンツを適切に処理する良い方法はありません。

XSLTを使用すると、特定のタグのテンプレートをそのまま作成するか、親のコンテキストで作成することができます。したがって、たとえば他の要素によって親である場合は、レンダリングが異なります。

かなり長いあいまいな答えですが、はい、わかりやすいテンプレート言語には大きな価値があると思います。XSLTは、これまでに得た最も標準化された最高のものです。

XSLTの最大の欠点は、（実際の実装で）効率的な処理のために一度にメモリに保持する必要があるドキュメントの量を最小化できないことです。代わりに、ドキュメント全体が何らかの形式のDOM表現に読み込まれ、それに対して処理が行われます。ドキュメントが非常に大きい場合、メモリ要件も大きくなります。しかし、多くのスタイルシートは、現在のタグと、タグの祖先など、他のいくつかのタグのみを必要とするため、最小限のメモリと効率的なストリーミングで処理できます。

はい、言語の観点からは奇妙ですが、それは参入の障壁にすぎません。XSLTを知っている場合、他の方法よりも簡単なことがよくありますが、大きなドキュメント（または一度に処理される大量のドキュメント）がある場合、XSLTのメモリへの影響は、多くの場合、他のより時間のかかる代替手段を強制します。

実際のところ、データを表示するために他の言語よりもXSLを使用する方が効率的だと思います。たとえば、XSL-FOを使用してXMLをPDFとして提示し、あらゆるインチを制御できますが、たとえばRDLC（.NET）を使用している場合、必要なものを正確に提示することは非常に困難です。

XSLでは各要素に独自のテンプレートがあるため、進化/修正も非常に簡単です。XSLの拡張は、XSLTやXSL-FOのように重要だと思います。そのため、この言語は今後も引き続き使用されます（ただし、この言語がより安定し、複雑さが軽減されることを本当に願っています）。

私はデータ統合会社で働いており、XMLからHTML / XML / Asciiを含む優れたソリューションとしてXSLTと独自のツールを使用しています。