XSLTは価値がありますか？[閉まっている]

少し前に、私はhtml風のXMLスキーマを設計するプロジェクトに着手しました。これにより、作成者は簡単な形式でコンテンツ（教育コースの資料）を記述でき、XSLTを介してHTMLに変換されます。私はしばらくそれを試してみました（苦労しました）、それを非常に基本的なレベルに到達させましたが、遭遇した制限（私の知識の制限であった可能性があります）や、ブログを読むことを勧めるブログを読んだときにイライラしましたXSLTを使用して、選択した言語で独自のXML-to-whateverパーサーを記述するだけで、私は熱心にそれに飛びついて、見事に機能しました。

私はまだそれを今日まで取り組んでいます（実際にSOでプレイするのではなく、現在取り組んでいることになっています）。XSLTを捨てる決断はいいもの。

私はXSLTがその位置にあり、それが受け入れられた標準であること、そして誰もが独自のインタープリターを作成している場合、その90％がTheDailyWTFで終わることを知っています。しかし、それがほとんどのプログラマーがよく知っている手続き型のスタイルではなく関数型のスタイル言語であることを考えると、私のようなプロジェクトに着手している人にとって、私が行った道を進むか、XSLTでそれを突き出すことをお勧めします？

XSLTの利点：

• XMLにドメイン固有なので、たとえば、出力でリテラルXMLを引用符で囲む必要はありません。
• XPath / XQueryをサポートします。これは、正規表現が文字列を照会するための優れた方法と同じように、DOMを照会するための優れた方法です。
• 関数型言語。

XSLTの欠点：

• わいせつな冗長になる可能性があります-リテラルXMLを引用する必要はありません。つまり、コードを引用する必要があります。そして、かなりの方法ではありません。しかし、再び、それはあなたの典型的なSSIよりもそれほど悪くはありません。
• ほとんどのプログラマーが当たり前だと思っていることはしません。たとえば、文字列の操作は面倒です。これは、初心者がコードを設計するときに「不幸な瞬間」につながる可能性があり、必然的にWebを検索して、そこにあり、書く時間がないと想定した関数を実装する方法のヒントを探します。
• 関数型言語。

ちなみに、手続き型の動作を実現する1つの方法は、複数の変換をチェーン化することです。各ステップの後に、そのステップでの変更を反映する、作業する真新しいDOMがあります。一部のXSLプロセッサーには、これを1つの変換で効果的に行うための拡張機能がありますが、詳細を忘れています。

したがって、コードがほとんど出力され、ロジックがあまりない場合、XSLTはそれを表現する非常にきちんとした方法になる可能性があります。ロジックはたくさんありますが、ほとんどがXSLTに組み込まれているフォームの場合（何とか見えるようにすべての要素を選択し、それぞれについて何とか出力する場合）、それは非常にフレンドリーな環境である可能性があります。いつもXMLっぽく考えたいと思うなら、XSLT 2を試してみてください。

それ以外の場合、お気に入りのプログラミング言語にXPathをサポートする適切なDOM実装があり、ドキュメントを便利な方法で構築できる場合、XSLTを使用するメリットはほとんどないと言えます。libxml2とgdome2へのバインディングはうまく機能するはずであり、あなたがよく知っている汎用言語にこだわることは恥ではありません。

通常、自社開発のXMLパーサーは不完全である（この場合、いつか行き詰まる）か、棚から降りることができるもの（この場合は、おそらく時間を浪費している）よりもはるかに小さく、悪意のある入力に関する重大なセキュリティ問題を引き起こす機会がいくつもあります。あなたがそれを行うことで何が得られるかを正確に知らない限り、それを書かないでください。つまり、XMLが提供するすべてのものが必要ない場合は、XMLよりも単純なもののパーサーを入力フォーマットとして作成できないということではありません。

とても否定的です！

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つのグループに分かれます：出版、銀行業、そしてウェブ。

これまでの答えの多くは、「ウェブサイトを作成するのは良くない」または「言語Xに似ている」と要約できます。多くの技術者は、関数型/宣言型言語に触れることなくキャリアを積んでいます。私が教えているとき、経験豊富なJava / VB / C / etcなどの人々が言語に問題を抱えています（変数は、たとえば手続き型プログラミングではなく代数という意味での変数です）。それはここで答える人々の多くです-私はJavaに乗ったことがありませんが、そのために言語を批評する気になりません。

多くの状況で、それはウェブサイトを作成するための不適切なツールです-汎用プログラミング言語の方が良いかもしれません。多くの場合、非常に大きなXMLドキュメントを取得してWebに表示する必要があります。XSLTはそれを簡単にします。私がこの分野で目にする学生は、データセットを処理してWeb上で提示する傾向があります。XSLTは、この分野で適用可能な唯一のツールではありません。ただし、それらの多くはこれを行うためにDOMを使用しており、XSLTは確かにそれほど苦痛ではありません。

私が見る銀行の学生は、一般的にDataPowerボックスを使用しています。これはXMLアプライアンスであり、さまざまなXML方言を「話す」サービスの間に位置するために使用されます。XSLTでは、あるXML言語から別のXML言語への変換はほとんど取るに足らないことであり、これに関する私のコースに参加する学生の数は増加しています。

私が目にする最後の生徒は、私と同じように出版の経歴を持っています。これらの人々は、膨大な量のドキュメントをXMLで作成する傾向があります（私が信じるように、業界としての出版はXMLに非常に取り入れられています。これらのドキュメントは処理中である必要があります（DocBookから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の解析は醜いので、TagSoupなどの方法でデータをフィードします（これにより、適切なSAX XMLイベントが生成され、基本的に、適切にXMLが記述されているかのようにHTMLを処理できるようになります）次に、XSLTを実行して、実際に使用できる「既知の安定した」フォーマットにデータを変換できます。 。その変換をXSLTファイルに分離することで、HTML形式が変更された場合、アプリケーション自体をアップグレードする必要がなくなり、代わりにエンドユーザーがXSLTファイルを編集するか、電子メールで送信できます。システム全体をアップグレードする必要のない、更新されたXSLTファイル。

Webプロジェクトの場合、今日のXSLTよりもビュー側を処理するためのより良い方法があると思いますが、テクノロジーとして、XSLTの使用は間違いなくあります。それは世界で最も使いやすい言語ではありませんが、完全に死んでいるわけではなく、私の観点からはまだ多くの優れた用途があります。

XSLTは宣言型プログラミング言語の例です。

宣言型プログラミング言語の他の例には、正規表現、Prolog、SQLなどがあります。これらはすべて、非常に表現力豊かでコンパクトであり、通常、非常によく設計されており、設計対象のタスクに対して強力です。

ただし、ソフトウェア開発者は一般的にそのような言語を嫌います。なぜなら、それらはより主流のオブジェクト指向言語や手続き型言語とは異なり、学習やデバッグが難しいためです。それらのコンパクトな性質は、一般に、不注意で多くの損傷を与えることを非常に簡単にします。

したがって、XSLTはデータをプレゼンテーションにマージするための効率的なメカニズムですが、使いやすさの面では失敗します。それが本当にうまくいっていない理由だと思います。

XSLTが新しくリリースされたときのXSLTに関する誇大宣伝を覚えています。「シンプルな」変換を使用してHTML UI全体を構築できることに対するすべての興奮は、

それに直面しよう、それは使いにくい、デバッグするのがほとんど不可能、耐え難いほど遅い。最終結果はほとんど常に風変わりで理想的とは言えません。

XSLTを使用するよりもすぐに自分の足をかじるようになりますが、より良い方法があります。それでもその場所はあり、単純な変換タスクに適しています。

ビルドプロセスの一部としてC ++コードを生成したり、ドキュメントコメントからドキュメントを作成したり、一般的にXMLや特にXHTMLを扱う必要のあるアプリケーション内で、さまざまな目的でXSLT（およびXQuery）を幅広く使用しました。特にコードジェネレーターは、10,000行を超えるXSLT 2.0コードが約12の個別のファイルに分散していました（クライアントのヘッダー、リモートプロキシ/スタブ、COMラッパー、.NETラッパー、ORMなど）。いくつか）。私はそれを本当に言語をよく理解していない別の男に受け継いだので、古いビットはその結果かなり混乱していました。しかし、私たちが書いた新しいものは、ほとんどが正常で読みやすいものであり、それを達成するための特定の問題を思い出しません。C ++の場合よりも難しくありませんでした。

バージョンと言えば、XSLT 2.0を扱うことは間違いなく正気を保つのに役立ちますが、1.0は、より単純な変換でも問題ありません。そのニッチでは、それは非常に便利なツールであり、特定のドメイン固有の機能（最も重要なのは、テンプレートマッチングによる動的ディスパッチ）から得られる生産性は、一致させるのが困難です。XSLTのXMLベースの構文のわかりやすさにもかかわらず、LINQ to XML（XMLリテラルを使用したVBでも）で同じことは通常、数倍長くなりました。ただし、そもそもXMLが不必要に使用されているために、最初から不必要なばらばらになっていることがよくあります。

要約すると、ツールボックスには非常に便利なツールですが、それは非常に特殊なツールであるため、適切に使用し、意図した目的に使用する限り、優れています。XSLT 2.0の適切なネイティブ.NET実装があったら本当に望みます。

私はXSLTを使用します（より良い代替手段がないため）が、プレゼンテーションのためではなく、変換のためだけに使用します。

1. Maven pom.xmlファイルを一括編集する短いXSLT変換を作成します。

2. XMI（UML図）からXMLスキーマを生成するための変換のパイプラインを作成しました。しばらくは機能しましたが、やっと複雑になり、納屋の後ろに出さなければなりませんでした。

3. 変換を使用してXMLスキーマをリファクタリングしました。

4. XSLTを使用して実際の作業を行うXSLTを生成することにより、XSLTのいくつかの制限を回避しました。（実行時までわからない名前空間を使用して出力を生成するXSLTを作成しようとしたことはありますか？）

処理しているXMLのラウンドトリップが、私が試した他のアプローチよりもうまく機能するので、何度も戻ってきます。XMLを不必要に損失したり、XMLを単に誤解したりしているようです。XSLTは不快ですが、Oxygenを使用すると耐えられます。

そうは言っても、私はClojure（lisp）を使用してXMLの変換を実行することを検討していますが、そのアプローチが私に利益をもたらすかどうかを知るにはまだ十分ではありません。

個人的には、XSLTをまったく異なるコンテキストで使用しました。私が当時取り組んでいたコンピューターゲームは、XMLを使用して定義された大量のUIページを使用していました。リリース直後の大規模なリファクタリング中に、これらのXMLドキュメントの構造を変更したいと考えました。ゲームの入力フォーマットを、スキーマを意識したより優れた構造にした。

XSLTは、古い形式から新しい形式へのこの変換に最適な選択肢のように思われました。2週間以内に、何百ページもの古いものから新しいものへの変換が機能しました。また、これを使用して、UIページのレイアウトに関する多くの情報を抽出することもできました。XSLTを使用してスキーマ定義に書き込んだコンポーネントが比較的簡単に組み込まれているリストを作成しました。

また、C ++の経歴を持っているため、習得するのは非常に楽しく興味深い言語でした。

XMLをある形式から別の形式に変換するツールとしては素晴らしいと思います。ただし、XMLを入力として取り、Somethingを出力するアルゴリズムを定義する唯一の方法ではありません。アルゴリズムが十分に複雑である場合、入力がXMLであるという事実は、選択したツールには関係ありません。

あなたの例に固有の、私は最良のアイデアはあなたのビジネスロジックに続くあなた自身のXML-> XML変換を作成することだと想像するでしょう。次に、書式設定のみを認識し、賢いことは何もしないXSLTトランスレータを記述します。それは良い中間点かもしれませんが、それはあなたがやっていることに完全に依存します。出力にXSLTトランスレーターがあると、代替の出力フォーマット（印刷可能、モバイル用など）を簡単に作成できます。

はい、よく使います。異なるxsltファイルを使用することで、同じXMLソースを使用して複数のポリグロット（X）HTMLファイル（同じデータを異なる方法で表示）、RSSフィード、Atomフィード、RDF記述子ファイル、サイトマップのフラグメントを作成できます。

万能薬ではありません。うまくいくものとうまくいかないものがあります。プログラミングの他のすべての側面と同様に、それはすべて、適切な仕事に適切なツールを使用することです。ツールボックスに入れておく価値のあるツールですが、適切な場合にのみ使用してください。

私はそれを突き出すことを絶対にお勧めします。特に、XSLT用の編集、表示、デバッグツールが組み込まれているVisual Studioを使用している場合。

はい、それはあなたが学んでいる間苦痛ですが、苦痛のほとんどは親しみやすさと関係しています。言語を学ぶにつれて、痛みは軽減されます。

W3schoolsには、特に価値のある2つの記事があります 。http： //www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

XSLTを操作するのは非常に難しいことがわかりました。

私は、あなたが説明するシステムと多少似たシステムでの作業経験があります。私の会社では、「中間層」から返されたデータはXMLであり、ページはHTMLでレンダリングされ、XHTMLである可能性があることに加えて、XSLはXML間の変換の標準であると聞いていましたフォーマット。そのため、「アーキテクト」（つまり、設計の深い考えを考えているが、コードを作成することはないと思われる人々）は、データを表示用のXHTMLに変換するXSLTスクリプトを記述することによって、フロントティアを実装することを決定しました。

選択は悲惨であることが判明しました。結局のところ、XSLTを書くのは面倒です。そして、私たちのすべてのページを書くことと維持することは困難でした。JSP（これはJavaでした）または出力形式（HTML）にある種類のマークアップ（山かっこ）と別の種類のマークアップ（<％... ％>）メタデータ用。XSLTで最も混乱する点は、XSLTがXMLで記述されており、XMLからXMLに変換されることです。3つの異なるすべてのXMLドキュメントをまっすぐに保つことは非常に困難です。

状況は少し異なります。私が行ったようにXSLTで各ページを作成する代わりに、XSLTで1ビットのコード（テンプレートから表示に変換するコード）を書くだけで済みます。しかし、あなたは私と同じような困難にぶつかったように思えます。あなたがしているように単純なXMLベースのDSL（ドメイン固有言語）を解釈することは、XSLTの強みの1つではないと私は言います。（それは仕事をすることができます...結局のところ、それは完全なチューリングです！）

ただし、単純な場合は、1つのXML形式のデータがあり、ページ全体を説明するDSLではなく、単純な変更を加えたいだけの場合、XSLTはその目的に最適なツールです。宣言型（手続き型ではない）の性質は、実際にはその目的のための利点です。

-マイケルチャームサイド

XSLTは扱いが難しいですが、XSLTを征服すると、DOMとスキーマを完全に理解できるようになります。XPathも使用している場合は、関数型プログラミングを学習する途中であり、これにより問題の解決に関する新しい手法と方法が明らかになります。場合によっては、逐次変換は手続き型ソリューションよりも強力です。

カスタムMVCスタイルのフロントエンドのために、XSLTを幅広く使用しています。モデルは（シリアライズされたXMLではなく）XMLに「シリアル化」され、xsltを介してHTMLに変換されます。ASP.NETに対する利点は、XPathとの自然な統合、およびより厳密な整形式の要件にあります（他のほとんどの言語よりもxsltのドキュメント構造について考える方がはるかに簡単です）。

残念ながら、この言語にはいくつかの制限（たとえば、別の変換の出力を変換する機能）が含まれているため、作業に不満を感じることがあります。

それにもかかわらず、簡単に達成できる、強制的に適用される懸念の分離は、現在提供している別のテクノロジーではないので、ドキュメントの変換については、まだお勧めです。

2004年のある時期に、非常に異なるDBシステム間の統合プロジェクトでXML、XSD、XSLTを使用しました。XSDとXSLTを最初から学習する必要がありましたが、難しくありませんでした。これらのツールの優れた点は、データに依存しないC ++コードを記述できることで、XSDとXSLTを使用してXMLドキュメントを検証/検証してから変換できました。データ形式を変更し、Xercesライブラリを採用したC ++コードではなく、XSDおよびXSLTドキュメントを変更します。

興味深いことに、メインのXSDは150KBで、XSLTの平均サイズは5KB未満のIIRCでした。

その他の大きな利点は、XSDがXSLTのベースとなっている仕様ドキュメントであることです。2つは調和して動作します。そして、最近のソフトウェア開発ではスペックはまれです。

宣言的な性質のXSDとXSLTを習得するのにそれほど問題はありませんでしたが、他のC / C ++プログラマーが宣言的な方法に適応するのに大きな問題があることがわかりました。彼らがそれを見たとき、私が理解した今、彼らはつぶやきました。そして、彼らは手続き的なXSLTを書き始めました（しゃれましたか？）問題は、XPathを学び、XMLの軸を理解する必要があることです。C ++を書くときにOOを採用することに慣れている昔のCプログラマを思い出します。

これらのツールを使用したのは、データ構造の変更の最も基本的なものを除くすべてから分離された小さなC ++コードベースを記述できるようになり、後者はDB構造の変更でした。私は他の言語よりもC ++を好んでいますが、ソフトウェアプロジェクトの長期的な実行可能性に利益をもたらすために有用だと思うものを使用します。

XSLTは素晴らしいアイデアだと思っていました。いいアイデアだと思います。

失敗するのは実行です。

時が経つにつれ発見された問題は、XMLでのプログラミング言語が単に悪い考えであることでした。それは全体を突き通せないものにします。具体的には、XSLTの学習、コーディング、理解は非常に難しいと思います。機能面に加えてXMLを使用すると、全体がわかりにくくなります。私はそれを私のキャリアの中で約5回学ぼうとしましたが、それは固執しません。

さて、あなたはそれを「ツール」することができます-それはそれのデザインのポイントの一部だったと思います-しかしそれは2番目の失敗です：市場に出ているすべてのXSLTツールは、非常に単純に...がらくたです！

XSLT仕様は、「他のXML文書にXML文書を変換するための言語」としてXSLTを定義します。XSLT内で最も基本的なデータ処理以外のことを実行しようとしている場合は、おそらくより良い解決策があります。

XSLTのデータ処理機能は、カスタム拡張関数を使用して.NETで拡張できることにも注意してください。

• MSDNドキュメント
• CSharpFriends：チュートリアル

私は自分の会社のオンラインドキュメントシステムを管理しています。ライターはSGML（言語のようなxml）でドキュメントを作成します。次に、SGMLはXSLTと結合され、HTMLに変換されます。

これにより、コーディングを行うことなく、ドキュメントのレイアウトを簡単に変更できます。XSLTを変更するだけです。

これは私たちにとってうまくいきます。私たちの場合、それは読み取り専用のドキュメントです。ユーザーはドキュメントを操作していません。

また、XSLTを使用することで、問題のあるドメイン（HTML）により近づくことができます。私はいつもそれを良い考えだと思っています。

最後に、現在のシステムが機能する場合は、そのままにしておきます。既存のコードを破棄することはお勧めしません。私がゼロから始めた場合は、XSLTを使用しますが、あなたの場合は、あなたが持っているものを使用します。

それはあなたがそれを必要とするものに帰着します。その主な長所は、変換の保守が容易なことであり、独自のパーサーを作成すると、通常はそれがなくなります。そうは言っても、時々システムは小さくてシンプルで、本当に「豪華な」ソリューションを必要としません。他のコードを変更せずにコードベースのビルダーを置き換えることができる限り、大したことはありません。

XSLの醜さについては、はい、醜いです。はい、慣れるまでに時間がかかります。しかし、慣れると（IMOに時間がかからないはずです）、実際にはスムーズな航行です。私の経験では、コンパイルされた変換は非常に高速に実行され、確実にデバッグできます。

XSLTは有用である可能性があると私はまだ信じていますが、XSLTは醜い言語であり、ひどく読みにくく、保守できない混乱を招く可能性があります。XMLが「言語」を構成するのに十分なほど人間が読めるわけではないことと、XSLTが宣言的で手続き的なもののどこかに行き詰まっていることが原因の1つです。そうは言っても、比較は正規表現で描くことができると思いますが、単純な明確に定義された問題に関してはそれを使用します。

代替アプローチを使用してコードでXMLを解析することも同様に厄介であり、XMLをオブジェクトに直接変換する何らかの種類のXMLマーシャリング/バインディングテクノロジー（JavaのJiBXなど）を採用したい場合があります。

XSLTを宣言型スタイルで使用できる場合（宣言型言語であることに全面的に同意するわけではありませんが）、XSLTは有用で表現力があると思います。

OO言語（私の場合はC＃）を使用してデータ/処理レイヤーを処理し、HTMLではなくXMLを出力するWebアプリを作成しました。これは、データAPIとしてクライアントによって直接消費されるか、XSLTによってHTMLとしてレンダリングされます。C＃は、この使用と構造的に互換性のあるXMLを出力していたため、すべて非常にスムーズで、プレゼンテーションロジックは宣言型のままでした。C＃からタグを送信するよりも、追跡および変更が簡単でした。

ただし、XSLTレベルでさらに多くの処理ロジックが必要になると、関数型スタイルを「取得」しても、複雑で冗長になります。

もちろん、最近私はおそらくRESTfulインターフェースを使用してそれらのWebアプリを作成したでしょう-そして、JSONなどのデータ「言語」は、XMLがXSLTによって伝統的に変換された領域で勢いを増していると思います。しかし今のところ、XSLTは依然として重要で有用なテクノロジーです。

私はXSLTに多くの時間を費やしてきましたが、XSLTは状況によっては便利なツールですが、すべてを解決できるわけではないことに気づきました。機械可読なXML入出力のデータ変換に使用される場合、B2Bの目的に非常によく機能します。制限についてのあなたの声明で、あなたが間違った方向に進んでいるとは思いません。私を最も苛立たせたのは、XSLTの実装におけるニュアンスでした。

おそらく、利用可能な他のマークアップ言語のいくつかを見る必要があります。私はジェフがスタックオーバーフローに関するこのトピックについての記事を書いたと思います。

HTMLは人道的なマークアップ言語ですか？

彼の書いたものを見てみよう。「箱から出して」必要なことを実行するソフトウェアパッケージを見つけることができます。または、独自のものをゼロから作成する代わりに、少なくとも非常に近いものを見つけることができます。

私は現在、公開サイトからデータをこすることを任されています（そうです、私は知っています）。ありがたいことに、これはxhtmlに準拠しているため、xsltを使用して必要なデータを収集できます。結果として得られるソリューションは、読みやすく、クリーンで、必要に応じて簡単に変更できます。パーフェクト！

以前にXSLTを使用したことがあります。6つの.xsltファイルのグループ（1つの大きなファイルからリファクタリングされた）は、C＃で書き直す前に約2750行でした。C＃コードは現在、多くのロジックを含む4000行です。XSLTで記述するために何が必要になるかについては考えたくありません。

私が諦めたのは、XPATH 2.0がないことが私の進歩を著しく損なうことに気付いたときです。

3つの質問に答えるには：

1. 数年前にXSLTを使用しました。
2. XSLTは特定の状況で適切なソリューションになると思います。（絶対とは絶対言うな）
3. 「単純な」変換に主に役立つというあなたの評価に同意する傾向があります。しかし、XSLTをよく理解している限り、XMLをHTMLに変換してWebサイトを公開するなど、より大きなタスクにXSLTを使用する場合があると思います。

多くの開発者がXSLTを嫌う理由は、XSLTが基づいている根本的に異なるパラダイムを理解していないためだと思います。しかし、関数型プログラミングへの最近の関心により、XSLTが復活するのを見るかもしれません...

xsltが本当に優れている1つの場所は、レポートの生成です。2ステップのプロセスで、最初のステップでレポートデータをxmlファイルとしてエクスポートし、2番目のステップでxsltを使用してxmlからビジュアルレポートを生成することがわかりました。これにより、必要に応じて検証メカニズムとして生データを保持しながら、優れたビジュアルレポートを作成できます。

以前の会社では、XMLとXSLTで多くのことを行いました。XMLとXSLTの両方が大きい。

はい、学習曲線がありますが、XMLを処理する強力なツールがあります。また、XSLTでXSLTを使用することもできます（これは便利な場合があります）。

パフォーマンスも問題です（非常に大きなXMLの場合）が、スマートXSLTを使用して（生成された）XMLでいくつかの前処理を行うことでこれに対処できます。

XSLTの知識がある人は、コンパイルされていないため、完成品の外観を変更できます。

私は個人的にはXSLTが好きで、単純化された構文を与えることをお勧めしますに外観あります（明示的なテンプレートではなく、値を吐き出すいくつかのXSLTタグが付いた通常の古いHTMLファイルのみ）。

たぶん、あなたはあなたの作者にシンプルなWikiやMarkdownインターフェースを提供したいだけかもしれません。そのためのライブラリもあります。XSLTが機能しない場合は、XMLも機能しない可能性があります。

XSLTは、XML変換のすべてではありません。ただし、それが問題の最良の解決策であったかどうか、または他のより効率的で保守可能なアプローチがあるかどうか、与えられた情報に基づいて判断することは非常に困難です。著者はコンテンツを簡略化された形式で入力できるとおっしゃっていますが、どの形式ですか？テキストボックス？どのようなHTMLに変換しましたか？XSLTがその仕事に適したツールであるかどうかを判断するには、この変換の機能をさらに詳しく知ることが役立ちます。

XML文書のツリー構造を変更するためだけにXSLTを使用するのを楽しんでいます。XSLTをXMLドキュメントに適用する前または後に実行する可能性のあるカスタムスクリプトにテキスト処理に関連することを行うのは面倒です。

XSLT 2.0にはより多くの文字列関数が含まれていましたが、XSLT 2.0は言語に適していないと思います。XSLT2.0の実装は多くありません。