XSLTは価値がありますか？
少し前に、著者がコンテンツ（教育コースの教材）をXSLTを介してHTMLに変換する簡略化された形式で記述できるように、html風のXMLスキーマを設計するプロジェクトに着手しました。私はしばらく遊んで（苦労して）非常に基本的なレベルに到達しましたが、遭遇した制限（私の知識の制限である可能性があります）と溝を示唆するブログを読んだときにあまりにもイライラしましたXSLTを使用し、選択した言語で独自のXMLパーサーを作成するだけで、私はそれに熱心に飛びつき、見事に機能しました。
私はまだ今日まで取り組んでいます（SOで演奏するのではなく、実際に今取り組んでいるはずです）、私はますます見ていますXSLTを捨てるという決定が良いものであると私に思わせること。
XSLTが受け入れられている標準であり、全員が独自のインタープリターを作成している場合、それらの90％が TheDailyWTF になります。しかし、それが 機能的なスタイル言語 であることを考えると、ほとんどのプログラマーが慣れ親しんでいる手続きスタイルではなく、私のようなプロジェクトに着手する人にとっては、彼らが私がした道を行くか、XSLTでそれを突き出すことをお勧めしますか？
XSLTの利点：
- XML固有のドメインです。たとえば、出力でリテラルXMLを引用する必要はありません。
- XPath/XQueryをサポートします。これは、正規表現が文字列を照会する良い方法であるのと同じ方法で、DOMを照会する良い方法である可能性があります。
- 関数型言語。
XSLTの欠点：
- わいせつに冗長になる可能性があります-リテラルXMLを引用する必要はありません。つまり、事実上、コードを引用する必要があります。そして、きれいな方法ではありません。しかし、ここでも、通常のSSIよりもそれほど悪くはありません。
- ほとんどのプログラマーが当たり前だと思う特定のことをしません。たとえば、文字列操作は面倒なことがあります。これは、初心者がコードを設計し、Webを必死に検索して、そこにあると思われる関数を実装する方法のヒントを必死に検索し、自分で書く時間を与えなかった場合につながります。
- 関数型言語。
ところで、手続き型の振る舞いを得るための1つの方法は、複数の変換を連結することです。各ステップの後、作業する真新しいDOMがあり、そのDOMはそのステップの変更を反映します。一部のXSLプロセッサには、これを1つの変換で効果的に行うための拡張機能がありますが、詳細は忘れています。
したがって、コードの大部分が出力であり、ロジックがそれほど多くない場合、XSLTはそれを表現する非常に適切な方法になります。多くのロジックがありますが、ほとんどがXSLTに組み込まれているフォーム（ブラーのように見えるすべての要素を選択し、出力ブラーごとに1つ）であれば、非常に使いやすい環境になります。 XMLのように常に考えたい場合は、XSLT 2を試してみてください。
それ以外の場合、お気に入りのプログラミング言語にXPathをサポートし、便利な方法でドキュメントを作成できる優れたDOM実装があれば、XSLTを使用するメリットはほとんどありません。 libxml2とgdome2へのバインディングはうまく機能するはずです。また、よく知っている汎用言語に固執することは恥ずべきことではありません。
自作のXMLパーサーは通常、不完全である（この場合はいつの日か行き詰まります）か、それとも棚から入手できるものよりも小さくありません（この場合、おそらく時間を浪費しています）。悪意のある入力に関する深刻なセキュリティ問題を引き起こす可能性があります。あなたがそれをすることによって何を得るかを正確に知っていない限り、1つを書かないでください。 XMLが提供するものすべてが必要でない場合、入力形式としてXMLよりも単純なもののパーサーを作成できないと言っているわけではありません。
ネガティブさ！
私はここ数年XSLTを使用してきましたが、XSLTは本当に気に入っています。あなたが理解しなければならない重要なことは、プログラミング言語ではなく、テンプレート言語です（そしてこの点で、私はそれがasp.net/spitよりも明らかに優れていると思います）です。
XMLは、今日のWeb開発の事実上のデータ形式です。構成ファイル、生データ、またはメモリ内の表現です。 XSLTとXPathを使用すると、そのデータを任意の出力形式に変換する強力で非常に効率的な方法が途方もなくになり、プレゼンテーションとデータを分離するMVCの側面が即座に得られます。
次に、ユーティリティの機能があります。名前空間を洗い流し、異なるスキーマ定義を認識し、ドキュメントをマージします。
必須独自の社内メソッドを開発するよりも、XSLTを扱う方が適切です。少なくともXSLTは標準であり、採用できるものであり、チームにとって実際に問題になる場合は、ほとんどのチームがXMLだけで作業を続けることができます。
実際の使用例：システム全体でインメモリXMLドキュメントを処理し、エンドユーザーの要求に応じてJSON、HTML、またはXMLに変換するアプリを作成しました。 Excelデータとして提供するというかなりランダムなリクエストがありました。元同僚はプログラムで同様のことをしていましたが、いくつかのクラスファイルのモジュールが必要で、サーバーにMS Officeがインストールされていた必要がありました。 ExcelにはXSDがあります：3時間でベースコードへの影響を最小限に抑える新機能。
個人的には、これは私のキャリアで出会った中で最もクリーンなものの1つだと思います。そして、その明らかな問題（デバッグ、文字列操作、プログラミング構造）はすべてツールの不完全な理解にあると思います。
明らかに、私はそれが「価値がある」と強く信じています。
私は生計を立てるためにXSLTを教えるため、ここでバイアスを認めなければなりません。しかし、私の生徒が働いていると思われる分野を隠す価値があるかもしれません。彼らは一般に、出版、銀行、ウェブの3つのグループに分かれています。
これまでの回答の多くは、「Webサイトを作成するのは良くありません」または「言語Xのようなものではない」と要約できます。多くの技術者は、関数型/宣言型言語にさらされることなくキャリアを経験しています。私が教えているとき、経験のあるJava/VB/C /などの人々は、言語に問題がある人です（変数は、例えば手続き型プログラミングではなく、代数という意味の変数です）。ここで答えている人々の多くです-私はJavaで行ったことはありませんが、そのために言語をわざわざ批判するつもりはありません。
多くの場合、それはウェブサイトを作成するための不適切なツールです-汎用プログラミング言語の方が良いかもしれません。多くの場合、非常に大きなXMLドキュメントを取得してWeb上に表示する必要があります。 XSLTはそれを簡単にします。このスペースで目にする学生は、データセットを処理し、Web上で提示する傾向があります。 XSLTがこの分野で唯一適用可能なツールではないことは確かです。ただし、それらの多くはDOMを使用してこれを行っており、XSLTは確かに痛みが少ないです。
私が見ている銀行の学生は、一般にDataPowerボックスを使用しています。これはXMLアプライアンスであり、異なるXMLダイアレクトを「話す」サービスの間に配置するために使用されます。 XSLTでは、あるXML言語から別のXML言語への変換はほとんど些細なことであり、これについて私のコースに参加する学生の数は増加しています。
私が見る最後の学生のセットは、出版の背景から来ています（私のような）。これらの人々はXMLで膨大なドキュメントを持っている傾向があります（業界としての出版はXMLに非常に近づいています。これらのドキュメントを処理する必要があります（ここでは、DocBook to ePubを思い浮かべます）。
上記の誰かは、スクリプトが60行未満になる傾向があるか、扱いにくいとコメントしました。扱いにくい場合は、コーダーが実際にアイデアを得ていない可能性があります。XSLTは他の多くの言語とはまったく異なる考え方です。考え方がわからなければ、うまくいきません。
それは確かに死にゆく言語ではありません（私が得る仕事の量はそれを教えてくれます）。現時点では、MicrosoftがXSLT 2の（非常に遅い）実装を完了するまでは少し「行き詰まって」います。
XSLTは、ドキュメントの作成などに広く使用され、複雑な構成設定をユーザーが保守できるようにします。
文書化には、XMLベースの形式であるDocBookを多数使用します。これにより、ファイルはプレーンテキストであるため、すべてのソースコードとともにドキュメントを保存および管理できます。 XSLTを使用すると、独自のドキュメント形式を簡単に構築できるため、一般的な方法でコンテンツを自動生成し、コンテンツを読みやすくすることができます。たとえば、リリースノートを公開するとき、次のようなXMLを作成できます。
<ReleaseNotes>
<FixedBugs>
<Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
<Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
<Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
</FixedBugs>
</ReleaseNotes>
そして、XSLT（上記をDocBookに変換します）を使用して、バグIDがバグトラッカーに自動的にリンクされ、バグがコンポーネントごとにグループ化され、すべての形式が完全に一貫しているニースリリースノート（通常PDFまたはHTML）になります。また、バージョン間で変更された内容をバグトラッカーに照会することにより、上記のXMLを自動的に生成できます。
XSLTが有用であるとわかったもう1つの場所は、実際にはコア製品にあります。サードパーティのシステムとやり取りする場合、複雑なHTMLページのデータを何らかの方法で処理する必要がある場合があります。 HTMLの解析はisいので、データを TagSoup （適切なSAX XMLイベントを生成し、本質的にHTMLが適切に記述されたXMLであるかのように処理できるようにする）を介してデータをフィードすると、 XSLTに対して、データを実際に使用できる「既知の安定した」形式に変換します。その変換をXSLTファイルに分離することにより、HTML形式が変更された場合、アプリケーション自体をアップグレードする必要はなく、代わりにエンドユーザーがXSLTファイルを編集するか、電子メールで送信することができますシステム全体をアップグレードする必要のない、更新されたXSLTファイル。
Webプロジェクトの場合、今日のXSLTよりもビュー側を処理する方法が優れていると思いますが、テクノロジとしては間違いなくXSLTの用途があります。使用するのが世界で最も簡単な言語ではありませんが、完全に死んでいるわけではなく、私の観点からはまだ多くの優れた用途があります。
XSLTは、 宣言型プログラミング 言語の例です。
宣言型プログラミング言語の他の例には、正規表現、Prolog、およびSQLが含まれます。これらはすべて非常に表現力豊かでコンパクトであり、通常は非常によく設計されており、設計されたタスクに対して強力です。
しかし、ソフトウェア開発者は一般にそのような言語が嫌いです。なぜなら、それらは他の主流のOOまたは手続き型言語とは大きく異なり、学習やデバッグが難しいからです。誤って多くの損傷。
そのため、XSLTはデータをプレゼンテーションにマージするための効率的なメカニズムですが、使いやすい部門では失敗します。私はそれが実際に流行していない理由だと信じています。
標準が新しくリリースされたとき、XSLTにまつわる誇大広告をすべて覚えています。 「シンプルな」変換を使用してHTML UI全体を構築できることに興奮しています。
それに直面しよう、それは使用するのが難しく、デバッグするのがほとんど不可能で、しばしば耐えられないほど遅い。最終結果は、ほとんど常に風変わりで理想的ではありません。
XSLTを使用するよりもすぐに自分の足をかじりますが、より良い方法があります。まだ場所があり、単純な変換タスクに適しています。
私はさまざまなことにXSLT（およびXQuery）を広範囲に使用しました-ビルドプロセスの一部としてC++コードを生成し、ドキュメントコメントからドキュメントを生成し、XML全般および特にXHTMLを特に処理する必要があったアプリケーション内で。特にコードジェネレーターは、10,000行を超えるXSLT 2.0コードで、約12個の個別のファイルに分散していました（クライアント用のヘッダー、リモートプロキシ/スタブ、COMラッパー、.NETラッパー、ORMなど、多くのことを行いました）少数）。私は言語をあまりよく理解していない別の男にそれを継承しました。その結果、古いビットはかなり混乱しました。しかし、私たちが書いた新しいものは、ほとんどが正気で読みやすいものに保たれていました。確かに、C++で行うよりも難しくありませんでした。
バージョンについて言えば、XSLT 2.0を扱うことは間違いなく正気を保つのに役立ちますが、単純な変換には1.0でも大丈夫です。そのニッチでは、それは非常に便利なツールであり、特定のドメイン固有の機能（最も重要なこととして、テンプレートマッチングによる動的ディスパッチ）から得られる生産性は一致させるのが困難です。 XSLTのXMLベースの構文は認識されているとはいえ、LINQ to XMLでも同じことが（VBでXMLリテラルを使用）でも）通常数倍長くなります。そもそもXMLを不必要に使用することがあるためです。
要約すると、ツールボックスに入れるのは信じられないほど便利なツールですが、非常に特殊なツールなので、適切に使用し、意図した目的で使用する限りは優れています。 XSLT 2.0の適切なネイティブ.NET実装があればいいのにと思います。
私はXSLTを使用します（より良い代替手段がないため）が、プレゼンテーションではなく、単に変換のために：
短いXSLT変換を作成して、maven pom.xmlファイルを一括編集します。
XMI（UML図）からXMLスキーマを生成する変換のパイプラインを作成しました。しばらくは機能しましたが、ようやく複雑になり、納屋の後ろでそれを取り出す必要がありました。
変換を使用してXMLスキーマをリファクタリングしました。
XSLTを使用してXSLTを生成し、実際の作業を行うことで、XSLTのいくつかの制限を回避しました。 （実行時までわからない名前空間を使用して出力を生成するXSLTを作成しようとしましたか？）
私が試した他のアプローチよりも、処理中のXMLを往復する方が良い仕事をするので、私はそれを繰り返し続けます。 XSLTは不快ですが、 Oxygen を使用すると耐えられます。
そうは言っても、XMLの変換を実行するために Clojure （LISP）を使用して調査していますが、そのアプローチが私に利益をもたらすかどうかを知るにはまだ十分ではありません。
個人的には、まったく異なるコンテキストでXSLTを使用しました。私が当時取り組んでいたコンピューターゲームは、XMLを使用して定義された多数のUIページを使用していました。リリース直後のメジャーリファクタリング中に、これらのXMLドキュメントの構造を変更したいと考えました。ゲームの入力形式を、より良くスキーマ対応の構造に準拠させました。
XSLTは、古い形式->新しい形式からのこの翻訳に最適な選択肢のようでした。 2週間以内に、数百ページの古いものから新しいものへの正常な変換が行われました。また、UIページのレイアウトに関する多くの情報を抽出するためにも使用できました。どのコンポーネントがどのリストに組み込まれているかのリストを比較的簡単に作成し、XSLTを使用してスキーマ定義に書き込みました。
また、C++のバックグラウンドから来て、習得するのはとても楽しくて興味深い言語でした。
XMLをある形式から別の形式に変換するツールとしては素晴らしいと思います。ただし、XMLを入力および出力として使用するアルゴリズムを定義する唯一の方法ではありませんSomething。アルゴリズムが十分に複雑な場合、入力がXMLであるという事実は、ツールの選択とは無関係になります。つまり、C++/Python /などで独自のロールを作成します。
あなたの例に特有の、最良のアイデアはあなたのビジネスロジックに従う独自のXML-> XML変換を作成することだと思います。次に、フォーマットについて知っているだけで、何も巧妙なことはしないXSLTトランスレーターを作成します。それはいい中間点かもしれませんが、それはあなたが何をしているのかによって完全に異なります。出力にXSLTトランスレーターを使用すると、印刷用、モバイル用など、代替の出力形式を簡単に作成できます。
はい、よく使用します。異なるxsltファイルを使用することにより、同じXMLソースを使用して、複数のポリグロット（X）HTMLファイル（異なる方法で同じデータを表示）、RSSフィード、Atomフィード、 RDF=記述子ファイルとサイトマップのフラグメント。
それは万能薬ではありません。それがうまくいくこととうまくいかないこと、そしてプログラミングの他のすべての側面と同様に、それはすべて、適切なツールを適切な仕事に使用することです。ツールボックスに入れる価値のあるツールですが、使用するのが適切な場合にのみ使用してください。
私は間違いなくそれを突き出すことをお勧めします。特に、XSLTの編集、表示、およびデバッグツールが組み込まれているVisual Studioを使用している場合。
はい、学習中の痛みですが、ほとんどの痛みは親しみに関係しています。言語を習得するにつれて痛みは軽減します。
W3schoolsには、特に価値がある2つの記事があります。 http://www.w3schools.com/xpath/xpath_functions.asphttp://www.w3schools.com/xsl/xsl_functions。 asp
XSLTを使用するのは困難ですが、XSLTを理解すると、DOMとスキーマを十分に理解できるようになります。 XPathを使用している場合は、関数型プログラミングを学習する途中です。これにより、問題を解決するための新しい手法と方法が公開されます。場合によっては、逐次変換は手続き型ソリューションよりも強力です。
XSLTは素晴らしいアイデアだと思っていました。つまり、isは素晴らしいアイデアです。
失敗するのは実行です。
私が時間の経過とともに発見した問題は、XMLのプログラミング言語は単なる悪い考えであるということでした。それはすべてを不可解にします。具体的には、XSLTの学習、コーディング、理解は非常に難しいと思います。機能的な側面に加えてXMLを使用すると、全体がわかりにくくなります。私は私のキャリアの中で約5回それを学ぼうとしましたが、それは固執しません。
わかりました、あなたはそれを「ツール」にすることができます-私はそれが部分的にそのデザインのポイントだったと思います-しかし、それは2番目の失敗です：市場にあるすべてのXSLTツールは、非常に単純に...くだらない！
2004年に、非常に異なるDBシステム間の統合プロジェクトでXML、XSD、およびXSLTを使用しました。XSDとXSLTをゼロから学ぶ必要がありましたが、難しくはありませんでした。これらのツールの優れた点は、XSDとXSLTに依存してXMLドキュメントを検証/検証し、変換することで、データに依存しないC++コードを作成できることでした。データ形式を変更し、Xercesライブラリを使用したC++コードではなく、XSDおよびXSLTドキュメントを変更します。
関心の対象：メインXSDは150KBで、XSLTの平均サイズは<5KB IIRCでした。
もう1つの大きな利点は、XSDがXSLTのベースとなる仕様ドキュメントであることです。 2つは調和して機能します。また、最近のソフトウェア開発では仕様がめったにありません。
宣言的な性質のXSDとXSLTを習得するのにそれほど苦労はしませんでしたが、他のC/C++プログラマーは宣言的な方法に適応するのに大きな問題を抱えていることがわかりました。彼らがそれを見たとき、私は理解したので、彼らは手順をつぶやいた。そして、彼らは手続き型のXSLTを書き始めました（しゃれ？）。問題は、XPathを学び、XMLの軸を理解する必要があるということです。昔のCプログラマーがC++を書くときにOOを採用することに慣れていることを思い出します。
これらのツールを使用して、最も基本的なデータ構造の変更以外のすべてから分離された小さなC++コードベースを記述できるようにしました。後者はDB構造の変更でした。私は他のどの言語よりもC++を好んでいますが、ソフトウェアプロジェクトの長期的な実行可能性を高めるために役立つと思われるものを使用します。
カスタムMVCスタイルのフロントエンドのために、XSLTを広く使用しています。モデルはxmlに「シリアル化」され（xml serializaiton経由ではなく）、xslt経由でhtmlに変換されます。 ASP.NETに対する利点は、XPathとの自然な統合と、より厳密な整形式要件（他のほとんどの言語よりもxsltのドキュメント構造について推論する方がはるかに簡単です）にあります。
残念ながら、この言語にはいくつかの制限（たとえば、別の変換の出力を変換する機能）が含まれているため、作業するのが時々イライラすることがあります。
それでも、簡単に達成でき、強く強制される懸念の分離は、現在別のテクノロジーが提供しているものとは思えません。したがって、ドキュメントの変換に関しては、まだお勧めです。
XSLTを扱うのは非常に難しいことがわかりました。
私は、あなたが説明したシステムにいくらか似たシステムで作業した経験があります。私の会社は、「中間層」から返されたデータはXMLであり、ページはXHTMLである可能性のあるHTMLでレンダリングされることに加え、XSLはXML間の変換の標準であると聞きましたフォーマット。したがって、「アーキテクト」（つまり、デザインの考え方は深いがコーディングはしないと思われる人々）は、データを表示用のXHTMLに変換するXSLTスクリプトを記述することで、フロントティアを実装することを決定しました。
選択は悲惨であることが判明しました。結局のところ、XSLTは書くのが苦痛です。そのため、すべてのページを作成し、維持することは困難でした。出力形式（HTML）と別の種類のマークアップ（<％...など）に1種類のマークアップ（山括弧）を使用したJSP（これはJavaにありました）またはいくつかの同様のアプローチを使用した方がはるかに良いでしょう％>）メタデータ用。 XSLTで最も紛らわしいのは、XMLで書かれており、XMLからXMLに変換されることです。3つの異なるXMLドキュメントをすべて頭の中にまっすぐに保つことは非常に困難です。
状況は少し異なります。XSLTで各ページをオーサリングする代わりに、XSLTで1ビットのコード（テンプレートから表示に変換するコード）を書くだけで済みます。しかし、あなたは私がやったのと同じ種類の困難にぶつかったようです。あなたがやっているように、単純なXMLベースのDSL（ドメイン固有言語）を解釈しようとすることは、XSLTの長所の1つではないと思います。 （ジョブを実行できますが...結局、ISチューリング完了！）
ただし、データが1つのXML形式であり、完全なページ記述DSLではなく、単純な簡単な変更を行うために、1つのXML形式のデータがある場合、XSLTはその目的に最適なツールです。それは宣言型（手続き型ではない）の性質であり、実際にはその目的のための利点です。
-マイケル・チャームサイド
それはあなたがそれを必要とするものに帰着します。その主な強みは、変換を簡単に維持できることであり、独自のパーサーを作成すると、一般的にそれが消去されます。そうは言っても、システムは小さくてシンプルで、「派手な」ソリューションを実際に必要としない場合があります。コードベースのビルダーが他のコードを変更することなく交換可能である限り、大したことはありません。
XSLのさについては、はいitいです。はい、慣れるまでに時間がかかります。しかし、いったん慣れると（IMOに長くはかからないはずです）、実際にはスムーズに航行できます。私の経験では、コンパイルされた変換は非常に高速に実行され、間違いなくそれらをデバッグできます。
XSLT仕様 は、XSLTを「XMLドキュメントを他のXMLドキュメントに変換するための言語」として定義しています。 XSLT内で最も基本的なデータ処理以外のことをしようとしている場合は、おそらくより良いソリューションがあります。
また、XSLTのデータ処理機能は、カスタム拡張機能を使用して.NETで拡張できることに注意してください。
XSLTは有用だとまだ信じていますが、XSLTはい言語であり、ひどく読めない、維持できない混乱を招く可能性があります。 XMLは「言語」を構成するほど人間が読めないためと、XSLTが宣言型と手続き型の間のどこかにあるためです。そうは言っても、正規表現を使用して比較を行うことができると思いますが、明確に定義された単純な問題に関しては、それを使用しています。
代替アプローチを使用して、コードでXMLを解析することも同様に厄介なことがあり、XMLをオブジェクトに直接変換する何らかの種類のXMLマーシャリング/バインドテクノロジー（JavaのJiBXなど）を実際に使用する必要があります。
会社のオンラインドキュメントシステムを管理しています。ライターはSGML（言語のようなxml）でドキュメントを作成します。次に、SGMLはXSLTと組み合わされ、HTMLに変換されます。
これにより、コーディングを行わずにドキュメントのレイアウトを簡単に変更できます。 XSLTを変更するだけです。
これは私たちにとってうまくいきます。この例では、読み取り専用ドキュメントです。ユーザーはドキュメントを操作していません。
また、XSLTを使用することで、問題のあるドメイン（HTML）に近づいています。私は常にそれが良いアイデアだと考えています。
最後に、現在のシステムが機能する場合は、そのままにしておきます。既存のコードを破棄することはお勧めしません。私がゼロから始める場合、XSLTを使用しますが、あなたの場合は、あなたが持っているものを使用します。
XSLTを宣言型スタイルで使用できる場合（宣言型言語であることに完全には同意しませんが）、有用で表現力があると思います。
OO言語（私の場合はC＃）を使用してデータ/処理層を処理するWebアプリを作成しましたが、HTMLではなくXMLを出力します。データAPI、またはXSLTによるHTMLとしてのレンダリングC＃はこの使用と構造的に互換性のあるXMLを出力していたため、すべて非常にスムーズであり、プレゼンテーションロジックは宣言的に保たれていました。 C＃。
ただし、XSLTレベルでより多くの処理ロジックが必要になると、機能的なスタイルを「取得」しても、複雑で冗長になります。
もちろん、最近はおそらくRESTfulインターフェースを使用してそれらのWebアプリを作成していました。JSONなどのデータ「言語」は、XMLがXSLTによって伝統的に変換されてきた分野で勢いを増していると思います。しかし今のところ、XSLTは依然として重要で有用な技術です。
前の会社では、XMLとXSLTで多くのことを行いました。 XMLとXSLTの両方が大きい。
はい、学習曲線がありますが、XMLを処理する強力なツールがあります。また、XSLTでXSLTを使用することもできます（便利な場合もあります）。
パフォーマンスも問題です（非常に大きなXMLの場合）が、スマートXSLTを使用して（生成された）XMLで前処理を行うことで、それに取り組むことができます。
XSLTの知識があれば、コンパイルされていないため、完成品の外観を変更できます。
以前にXSLTを使用したことがあります。 6つの.xsltファイル（1つの大きなファイルからリファクタリングされた）のグループは、C＃で書き直すまでに約2750行でした。 C＃コードは現在、多くのロジックを含む4000行です。 XSLTで書くのに何が必要かについても考えたくはありません。
私が2.0めたのは、XPATH 2.0がないことが私の進歩を著しく損なっていることに気付いたときです。
3つの質問に答えるには：
- 数年前にXSLTを使用したことがあります。
- 特定の状況では、XSLTが適切なソリューションになると考えています。 （絶対とは絶対言うな）
- 私はあなたの評価に同意する傾向がありますが、それは「単純な」変換に最も有用であるということです。ただし、XSLTを十分に理解している限り、XMLをHTMLに変換してWebサイトを公開するなど、より大きなタスクにXSLTを使用する場合があります。
多くの開発者がXSLTを嫌う理由は、XSLTが基づいている根本的に異なるパラダイムを理解していないためだと思います。しかし、関数型プログラミングへの最近の関心により、XSLTが復活するのを見るかもしれません...
私はXSLTに多くの時間を費やしましたが、それは状況によっては便利なツールではありますが、すべてを修正するものではないことは間違いありません。機械可読XML入力/出力のデータ変換に使用される場合、B2Bの目的に非常によく機能します。私はあなたがその制限の声明で間違った道を進んでいるとは思わない。私を最もイライラさせたものの1つは、XSLTの実装のニュアンスでした。
おそらく、利用可能な他のマークアップ言語のいくつかを見るべきです。ジェフは、スタックオーバーフローに関するこのまさにトピックに関する記事を書いたと思います。
彼が書いたことを見てみよう。おそらく、「箱から出して」欲しいものを実行するソフトウェアパッケージを見つけることができます。あるいは、最初から独自のものを書く代わりに、少なくとも非常に近いソフトウェアパッケージを見つけることができます。
Xsltが本当に優れているのは、レポートの生成です。最初のステップでレポートデータをxmlファイルとしてエクスポートし、2番目のステップでxsltを使用してxmlから視覚的なレポートを生成する2ステップのプロセスを見つけました。これにより、必要に応じて検証メカニズムとして生データを保持しながら、素敵なビジュアルレポートを作成できます。
私は個人的にXSLTが好きで、あなたは 簡略化された構文 を見てみたいかもしれません（明示的なテンプレートはなく、値を吐き出すためのいくつかのXSLTタグを持つ通常の古いHTMLファイルです）が、それはただですみんなのために。
作成者に単純なWikiまたはMarkdownインターフェイスを提供したいだけかもしれません。そのためのライブラリもあり、XSLTが機能しない場合は、XMLも機能していない可能性があります。
私は現在、公開サイトからデータをスクレイピングする仕事をしています（そうですね）。ありがたいことに、xhtmlに準拠しているため、xsltを使用して必要なデータを収集できます。結果のソリューションは、読みやすく、クリーンで、必要に応じて簡単に変更できます。パーフェクト！
あなたは正しいことをしたと思います。私の経験では、XSLT開発者は、Web開発者やカジュアルなプログラマーのいずれにも馴染みのない言語なので、採用するのが非常に困難です。
そのため、「メインストリーム以外の言語を知っている上級プログラマー」のプレミアムを支払う必要がありますが、おそらくそのプログラマーのお気に入りではない言語に対してです。
私はXSLTでかなり良い経験をしましたが、HTMLに変換していませんでした。 XSLT-HTMLコンボは、物事を成し遂げるために非常に難しいものかもしれません。
XSLT 1.0は、少なくともデスクトップコンピューターとサーバーコンピューターで最も移植性の高いコードの1つです。それらのシステムのほとんどに1つの（そして多くの場合）ランタイムがあるためです。
- Microsoft Windowsには、少なくともWindows 2000以降、ベースシステムにインストールされたMSXMLがあります。MSIE、 コマンドラインから （WSHを使用）、またはOfficeアプリケーションの両方から使用できます。
- Java Runtime Environment（JRE）にはXSLTランタイムがあり、JREはほとんどのデスクトップにインストールされています
- ほとんどすべての主要なWebブラウザには1つあります。 Operaは例外です。
- Major GNUベースのオペレーティングシステム（libxslt、xsltproc）にデフォルトでインストールされる無料の実装があります
- 私はMacOS Xをチェックしていませんが、少なくともSafariで実装されています
これにより、移植性と軽量/非インストールの両方を必要とする一部のアプリケーションを構築するのに適しています。
また、XSLTはランタイムのみを必要とし（コンパイラーは不要）、任意のテキストエディターでコードを作成できます。そのため、任意のデスクトップから簡単に（言語をマスターしたら）プログラムを作成できます。
私はXSLTを広範囲に使用しました...数時間。要素名を変更したり、入力ドキュメントをフィルタリングしたり（不要なものを削除する）などの場合に便利です。
他のものはすぐに複雑になります。これは、複雑さを継承し、他のプログラミング言語（変数など）から使用されるほとんどの要素の欠如と、XPath式を判読できず、本当に傷つける簡単な方法を継承します。
最終的に、XSLTは分裂に苦しむ：プログラマーは制限のためにそれを好まず、他の誰もがそれをまったく使用できない（たとえば、Webデザイナーまたは他のプログラマー以外のタイプ）。
XSLTがXMLのある種のSQLとして宣伝されていた場合、状況は少し異なります。第一に、人々はそれを見てさえ気にしなかったでしょう。そして、そうした人たちは痛みに驚かなかったでしょう。
コンセプトは健全だと思います。おそらく、実行は可能な限り「クリーン」ではありません。
しかし、ツールとして扱うべきだと思います。すべてのインスタンスで使用するのは賢明ではないかもしれませんが、ソリューションを解決するときにツールを無視するべきではありません。
私は非常に優れたXSLTを見てきましたし、XSLTの非常に悪い使い方も見てきました。開発者が複数のドメインを同時に考える必要があるのは、その1つだと思います。
それは未来ですか？たぶんそうじゃない、もっと良い解決策があるかもしれない。
どの新しいテクノロジーが登場するのかわかりませんが、少なくともそれを学ぶのが最善です。ツールセットを増やすことは確かに悪いことではありませんか？
XSLTを使用して、非常に複雑なxmlファイルのエラーを修正します。したがって、xmlのエラーを処理する代わりに、xsltを使用してエラーを修正します。
これは素晴らしい。言語は非常に強力であり、xmlユースケースに適合するためです。通常のプログラミング言語で同じことを行うには、新しいフレーバーが発生するたびにコードを適応させるのに本当に長い時間がかかりました。
また、Microsoftに変更を決定させることなく、Visual Studioソリューションを移行するのに役立ちます。したがって、1つのソリューションを変換します。変更点を確認してください。変更したくないものを元に戻し、すべてのファイルに対してジョブを実行するxsltスクリプトを実行します。
だから私は決してWebプレゼンテーションやこのようなことをするためにそれを使用したことはありませんが、それは私のXMLベースの問題に役立ちます。そして、これらの問題を解決するためには、非常に強力で、見てみる価値があります。
XSLTはXML変換のすべてではありません。ただし、与えられた情報に基づいてそれがあなたの問題に対する最善の解決策であったかどうか、または他のより効率的で保守可能なアプローチがあるかどうかを判断することは非常に困難です。著者は、コンテンツを簡略化された形式で入力できると言っていますが、どの形式ですか？テキストボックス？どのHTMLに変換しましたか？ XSLTがジョブに適したツールであるかどうかを判断するには、この変換の機能をより詳細に知ることが役立ちます。
私もXSLTの世界に進出しましたが、XSLTは場所によっては少し扱いにくいことがわかりました。私の主な問題は、「純粋なデータ」XMLを完全なHTMLページに変換することの難しさだったと思います。後から考えると、おそらくXSLTを使用して、サーバーサイドスクリプティング（SSIなど）を使用して他のフラグメントと一緒に構成できるページフラグメントを生成すると、私の問題の多くが解決するでしょう。
考えられる間違いの1つは、document（）関数を使用してXHTMLまたはその他のXMLデータをインポートすることにより、データを囲む共通のページレイアウトを作成しようとすることでした。
もう1つの間違いは、特定の値を持つ行に異なる背景行の色を使用し、フィルタリングする列を指定できるようにするロジックを使用して、XMLデータのテーブルを生成する一般的なテンプレートを作成するなどのプログラム的なことをしようとしたことです。
再帰的なテンプレート呼び出しを使用してのみ解決可能と思われるXMLデータから値の文字列リストを構築しようとすることは言うまでもありません。
私は何を得ましたか？さて、ページソースはXMLデータであり、視聴者が利用できます。データとプレゼンテーションはきちんと分離されています。
もう一度やりますか？ staticページでデータ/プレゼンテーションの分離が本当に必要でない限り、おそらくそうではありません。そうでなければ、おそらくRailsまたはJavaテンプレートを使用してXMLビューまたはHTMLビューを生成できるEEアプリ-すべての利点がありますが、はるかに自然な（私にとって）プログラミング言語が私の指先にあります。
XSLTは、XMLドキュメントのツリー構造を変更するためだけに使用します。 XSLTをXML文書に適用する前または後に実行するカスタムスクリプトにテキスト処理に関連する何かを行い、それを委任するのは面倒です。
XSLT 2.0にはもっと多くの文字列関数が含まれていましたが、それは言語に適していないと思います。また、XSLT 2.0の実装は多くありません。
純粋な生産性の観点から、jQueryスタイルのライブラリの1つ（pyQuery、phpQueryなど）を使用する方が良いでしょう。ほとんどのXMLライブラリは、XSLTは基本的な本格的な言語としてパッケージ化されたXMLライブラリです。 。 jQueryを使用すると、選択した言語でXMLスタイルデータをたどり、簡単に操作できます。
相互運用性について言えば、XMLは情報ストレージの標準です。多くのツールがXMLで出力を生成し、アプリにブラウザを埋め込み、XMLをフォーマットしてブラウザに挿入するよりも優れた（または簡単な）表示方法を提供します。
特定の問題を解決することは良いアイデアだと考える人がいたため、ここでXSLTを使用する必要があります。複数のXMLファイルからデータを抽出し、さらに処理を行うさまざまなツールのさまざまな出力形式に結合する必要があります。
Fisrt XSLTは信頼できる標準であるため、非常に良いアイデアだと思いました。これは、コード内のプログラミングロジックやアルゴリズムをあまり必要としない単純なフォーマットタスクに当てはまります。
しかし、それはnot手続き型であるため、非常に段階的な学習曲線です。手続き型プログラミング（C、Java、Perl、PHPなど）に慣れていると、多くの一般的な構造体を見逃してしまうか、または見苦しいだけでなく、訓練されていない目では実際に読めないことがあると思うでしょう。たとえば、「再利用可能な」コードの記述：手続き型プログラミングで、さまざまな場所で何度も繰り返し行う必要がある場合は、そのための関数を定義します。 XSLTでもそのようなことを実現できますが、より多くのコードを記述する必要があり、通常の関数ほど読みやすくも理解もできません。
私が抱える主な問題は、手続きの背景からやってくる多くの人々が今までにXSLTファイルに取り組んでおり、ほとんどすべての人が彼が必要とするものを「エミュレート」していることです。
結論として、私はXSLTを「究極の」ソリューションとは見ていません。実際、XSLTでいくつかの構造を読み書きするのは苦痛です。ほとんどの場合、アプリケーションについて考える必要があります。単純な変換のために、おそらく再びXSLTを使用します。しかし、より複雑なソフトウェアについては、二度と使用しません。