html - XSLT はそれだけの価値がありますか?

Question

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

私はまだそれに取り組んでいます ( SO で遊ぶのではなく、実際に今取り組んでいるはずです)。XSLT を捨てるという決定はいいもの。

私は、XSLT が標準として認められているという点でその場所があること、そして誰もが独自のインタープリターを作成している場合、その 90% がTheDailyWTFを使用することになることを知っています。しかし、ほとんどのプログラマーが慣れ親しんでいる手続き型のスタイルではなく関数型のスタイルの言語であることを考えると、私のようなプロジェクトに着手する人には、私が行った道をたどることをお勧めしますか、それとも XSLT を使い続けることをお勧めしますか? ?

score 92 · Accepted Answer

あまりにも多くの否定性！

私はここ数年 XSLT を使用しており、本当に気に入っています。認識しなければならない重要なことは、これはプログラミング言語ではなく、テンプレート言語であるということです(この点で、asp.net /spit よりも優れていることがわかります)。

XML は、構成ファイル、生データ、メモリ内表現など、今日の Web 開発の事実上のデータ形式です。XSLT と XPath は、そのデータを任意の出力形式に変換する非常に強力で非常に効率的な方法を提供し、プレゼンテーションをデータから分離するという MVC の側面を即座に提供します。

次に、名前空間の洗い流し、異なるスキーマ定義の認識、ドキュメントのマージなどのユーティリティ機能があります。

独自のメソッドを独自に開発するよりも、XSLT を処理する方がよいに違いありません。少なくとも XSLT は標準であり、雇うことができるものです。それがチームにとって本当に問題になった場合、その性質上、ほとんどのチームは XML だけで作業し続けることができます。

実際のユースケース: システム全体でインメモリ XML ドキュメントを処理し、エンドユーザーの要求に応じて JSON、HTML、または XML に変換するアプリを作成しました。Excelデータとして提供するというかなりランダムなリクエストがありました。以前の同僚がプログラムで同様のことを行っていましたが、それにはいくつかのクラスファイルのモジュールが必要であり、サーバーに MS Office がインストールされている必要がありました。Excel には XSD があることが判明しました。ベースコードへの影響を 3 時間で最小限に抑える新機能です。

個人的には、これまでのキャリアで遭遇した中で最もクリーンな問題の 1 つだと思います。明らかな問題 (デバッグ、文字列操作、プログラミング構造) はすべて、ツールの理解の誤りに起因すると考えています。

もちろん、「それだけの価値がある」と強く信じています。

score 65 · Accepted Answer

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 より単純なもののパーサーを作成できないと言っているわけではありません。

score 27 · Accepted Answer

私は生計を立てるために XSLT を教えているので、ここで偏見を認めざるを得ません。しかし、私の学生が取り組んでいる領域をカバーすることは価値があるかもしれません. 彼らは一般的に、出版、銀行、ウェブの3つのグループに分かれています.

これまでの回答の多くは、「Web サイトを作成するのに適していない」または「言語 X とはまったく異なる」と要約できます。多くの技術者は、関数型言語や宣言型言語に触れずにキャリアを積んでいます。私が教えているとき、経験豊富な Java/VB/C/etc の人々は、言語に問題がある人です (変数は、たとえば、手続き型プログラミングではなく、代数の意味での変数です)。これは、ここで回答している多くの人々です。私は Java を使用したことがありませんが、Java を批判するつもりはありません。

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

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

私が見る最終的な学生のセットは、出版のバックグラウンドから来ています (私のように)。これらの人々は、膨大な量の文書を XML で作成する傾向があります (私が信じているように、業界としての出版は XML に大きく傾いています。テクニカルパブリッシングは何年も前から存在しており、業界向けのパブリッシングは現在、XML に移行しています)。これらのドキュメントは処理する必要があります (ここでは DocBook から ePub への変換が思い浮かびます)。

上記の誰かが、スクリプトは 60 行未満になる傾向がある、または扱いにくくなるとコメントしました。それが扱いにくくなるとしたら、コーダーがその考えを理解していない可能性が高いです。XSLT は、他の多くの言語とは非常に異なる考え方です。心構えができていないとうまくいきません。

それは確かに死にかけている言語ではありません (私が得る仕事の量はそれを教えてくれます)。現時点では、Microsoft が XSLT 2 の (非常に遅い) 実装を完了するまで、少し「行き詰まっている」状態です。

score 24 · Accepted Answer

ドキュメントなどに 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 を使用する方法は間違いなくあります。世界で最も使いやすい言語というわけではありませんが、死んだわけではありません。私の見解では、まだ多くの有効な用途があります。

score 19 · Accepted Answer

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

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

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

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

score 12 · Accepted Answer

XSLT が新たにリリースされたとき、XSLT が大々的に宣伝されたのを覚えています。「単純な」変換を使用して HTML UI 全体を構築できることに興奮しています。

正直に言うと、使いにくく、デバッグがほぼ不可能で、多くの場合、耐えられないほど遅いです。最終結果は、ほとんどの場合、風変わりで理想的とは言えません。

物事を行うためのより良い方法があるにもかかわらず、XSLT を使用するよりも早く自分の足をかじります。それでも、単純な変換タスクに適しています。

score 10 · Accepted Answer

私は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での同じこと（XMLリテラルを使用するVBでも）は通常、数倍長くなりました。ただし、そもそもXMLを不必要に使用することで、不当な問題が発生することがよくあります。

要約すると、ツールボックスに入れると非常に便利なツールですが、非常に特殊なツールであるため、適切に使用し、本来の目的で使用する限り、これは優れています。XSLT2.0の適切なネイティブ.NET実装があったらいいのにと思います。

score 9 · Accepted Answer

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

maven pom.xml ファイルで一括編集を行うために、短い XSLT 変換を作成します。
XMI (UML ダイアグラム) から XML スキーマを生成する変換のパイプラインを作成しました。しばらくはうまくいきましたが、最終的には複雑になりすぎて、納屋の後ろに持ち出さなければなりませんでした.
変換を使用して XML スキーマをリファクタリングしました。
XSLT を使用して XSLT を生成し、実際の作業を行うことで、XSLT のいくつかの制限を回避しました。(実行時までわからない名前空間を使用して出力を生成する XSLT を作成しようとしたことがありますか?)

私が試した他のアプローチよりも、処理中の XML のラウンドトリップが優れているため、私は何度もこの方法に戻ってきます。XSLT は不快ですが、Oxygenを使用すると耐えられるようになります。

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

score 7 · Accepted Answer

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

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

また、C++ のバックグラウンドを持っているため、マスターするのは非常に楽しく興味深い言語でした。

XML をあるフォーマットから別のフォーマットに変換するツールとしては素晴らしいと思います。ただし、XML を入力として取り、Somethingを出力するアルゴリズムを定義する方法はこれだけではありません。アルゴリズムが十分に複雑な場合、入力が XML であるという事実は、ツールの選択とは無関係になります。つまり、C++ / Python / 何でも自分で作成します。

あなたの例に固有のものですが、ビジネスロジックに従う独自の XML->XML 変換を作成することが最善のアイデアだと思います。次に、書式設定だけを知っていて、巧妙なことは何もしない XSLT トランスレータを作成します。それは良い妥協点かもしれませんが、それはあなたが何をしているかに完全に依存します. 出力に XSLT トランスレータを使用すると、代替の出力形式 (印刷可能、モバイル用など) を簡単に作成できます。

score 6 · Accepted Answer

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

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

score 4 · Accepted Answer

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

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

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

score 3 · Accepted Answer

2004年のある時点で、非常に異なるDBシステム間の統合プロジェクトでXML、XSD、およびXSLTを使用しました。XSDとXSLTを最初から学ぶ必要がありましたが、難しくはありませんでした。これらのツールの優れた点は、データに依存しないC ++コードを記述できることであり、XSDとXSLTを使用してXMLドキュメントを検証/検証してから変換します。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++を好みますが、ソフトウェアプロジェクトの長期的な実行可能性に役立つと思うものを使用します。

score 3 · Accepted Answer

XSLTは素晴らしいアイデアだと思っていました。それは素晴らしいアイデアだということです。

それが失敗するのは実行です。

私が時間をかけて発見した問題は、XMLでのプログラミング言語は悪い考えだということでした。それはすべてを不可侵にします。具体的には、XSLTは学習、コーディング、理解が非常に難しいと思います。機能面に加えてXMLを使用すると、全体が混乱しすぎます。私は自分のキャリアの中でそれを約5回学ぼうとしましたが、それは固執しません。

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

score 3 · Accepted Answer

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

score 3 · Accepted Answer

XSLT を扱うのは非常に難しいことがわかりました。

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

選択は悲惨であることが判明しました。XSLT は、書くのが面倒であることがわかりました。そのため、すべてのページを作成して維持するのが困難でした。JSP (これは Java にありました) を使用するか、出力形式 (HTML) に 1 種類のマークアップ (山かっこ) を使用し、別の種類のマークアップ (<%... %>) をメタデータに使用します。XSLT で最も紛らわしいのは、XSLT が XML で記述されており、XML から XML に変換されることです... 3 つの異なる XML ドキュメントすべてを頭の中で整理するのは非常に困難です。

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

ただし、より単純な場合、つまり 1 つの XML 形式のデータがあり、それに簡単な変更を加えたい場合 (完全なページ記述 DSL ではなく、いくつかの簡単で単純な変更を加えたい場合)、XSLT はその目的のための優れたツールです。その宣言型 (手続き型ではない) の性質は、実際にはその目的にとって有利です。

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

score 3 · Accepted Answer

カスタム MVC スタイルのフロントエンドとして、XSLT を広く使用しています。モデルは xml に「シリアライズ」され (xml シリアライズ経由ではなく)、xslt 経由で html に変換されます。ASP.NET に対する利点は、XPath との自然な統合と、より厳密な整形式要件にあります (xslt のドキュメント構造については、他のほとんどの言語よりもはるかに簡単に推論できます)。

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

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

score 2 · Accepted Answer

XSLT を宣言型スタイルで使用できる場合 (ただし、それが宣言型言語であることに完全に同意するわけではありません)、それは有用で表現力豊かだと思います。

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

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

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

score 2 · Accepted Answer

会社のオンラインドキュメントシステムを管理しています。ライターは、SGML (xml に似た言語) でドキュメントを作成します。その後、SGML は XSLT と結合され、HTML に変換されます。

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

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

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

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

score 2 · Accepted Answer

The XSLT specification defines XSLT as "a language for transforming XML documents into other XML documents". If you are trying to do any thing but the most basic data processing within XSLT there are probably better solutions.

Also worth noting that the data processing capabilities of XSLT can be extended in .NET using custom extension functions:

score 2 · Accepted Answer

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

別のアプローチを使用してコード内で XML を解析することも同様に厄介な場合があり、XML をオブジェクトに直接変換する何らかの XML マーシャリング/バインディングテクノロジ (Java の JiBX など) を実際に使用する必要があります。

score 2 · Accepted Answer

それはあなたがそれを必要とするものに帰着します。その主な強みは、変換の容易な保守性であり、独自のパーサーを作成すると、一般的にそれがなくなります。そうは言っても、システムが小さくて単純で、「派手な」ソリューションを本当に必要としない場合があります。コードベースのビルダーが他のコードを変更せずに置き換え可能である限り、大したことはありません。

XSL の醜さについては、はい、醜いです。はい、慣れが必要です。しかし、コツをつかめば (IMO にそれほど時間はかからないはずです)、実際には順風満帆です。私の経験では、コンパイルされた変換は非常に高速に実行され、確実にデバッグできます。

score 1 · Accepted Answer

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

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

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

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

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

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

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

score 1 · Accepted Answer

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

私があきらめたポイントは、XPATH 2.0 を持っていないことが私の進歩を著しく損なっていることに気付いたときです。

score 1 · Accepted Answer

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

おそらく、利用可能な他のマークアップ言語のいくつかを調べる必要があります。Jeff は Stack Overflow に関するまさにこのトピックについて記事を書いたと思います。

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

私は彼が書いたものを見てみます。おそらく、「すぐに使える」、またはゼロから独自のものを作成するのではなく、少なくとも非常に近いソフトウェアパッケージを見つけることができます。

score 1 · Accepted Answer

私は現在、公開サイトからデータをスクレイピングする任務を負っています (ええ、私は知っています)。ありがたいことに、xhtml に準拠しているため、xslt を使用して必要なデータを収集できます。結果として得られるソリューションは、読みやすく、クリーンで、必要に応じて簡単に変更できます。完全！

score 1 · Accepted Answer

私は個人的に XSLT が好きで、簡略化された構文(明示的なテンプレートはなく、値を吐き出すためのいくつかの XSLT タグを含む通常の古い HTML ファイル) を見てみたいと思うかもしれませんが、万人向けではありません。

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

score 0 · Accepted Answer

純粋な生産性という点では、jQuery スタイルのライブラリーの 1 つ (pyQuery、phpQuery など) を使用したほうがよいでしょう。ほとんどの XML ライブラリーは最悪であり、XSLT は本質的に、本格的な言語としてパッケージ化された XML ライブラリーの 1 つにすぎませんが、適切なツールセットはありません。 . jQuery を使用すると、選択した言語で XML スタイルのデータを非常に簡単に走査および操作できます。

score 0 · Accepted Answer

私の意見では、はい。

XSLT の非常に優れた使用例については、blizzard の World of Warcraft Armory をご覧ください。

http://www.wowarory.com

score 0 · Accepted Answer

私は XSLT でかなり良い経験をしましたが、HTML に変換していませんでした。XSLT と HTML の組み合わせは、物事を成し遂げるためには非常に難しいものかもしれません。

score 0 · Accepted Answer

私も XSLT の世界に足を踏み入れたことがありますが、XSLT が少しぎこちないところもあることがわかりました。私の主な問題は、「純粋なデータ」XML を完全な HTML ページに変換するのが難しいことにあったと思います。後から考えると、XSLT を使用して、サーバーサイドスクリプト (SSI など) を使用して他のフラグメントと一緒に構成できるページフラグメントを生成することで、私の問題の多くを解決できたはずです。

考えられる間違いの 1 つは、document() 関数を使用して XHTML またはその他の XML データをインポートすることにより、データを囲む共通のページレイアウトを構築しようとしたことです。

もう 1 つの間違いは、特定の値を持つ行に異なる背景行色を使用したり、一部の列を除外するように指定したりできるロジックを使用して XML データのテーブルを生成する一般的なテンプレートを作成するなど、プログラム的なことをしようとしたことです。

言うまでもなく、XML データから値の文字列リストを作成しようとしましたが、これは再帰的なテンプレート呼び出しを使用してのみ解決できるように思われました。

私は何を得ましたか？ページソースはすぐそこにある XML データであり、閲覧者が利用できます。データとプレゼンテーションはきちんと分離されています。

もう一度やりますか？静的ページでデータとプレゼンテーションの分離が本当に必要でない限り、おそらくそうではありません。それ以外の場合は、テンプレートを使用して XML ビューまたは HTML ビューを生成できる Rails または Java EE アプリを作成することになるでしょう。すべての利点が得られますが、(私にとっては) はるかに自然なプログラミング言語をすぐに使用できます。

score 0 · Accepted Answer

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

score 0 · Accepted Answer

私は、XML ドキュメントのツリー構造を変更するためだけに XSLT を使用しています。テキスト処理に関連するすべてのことを実行し、XSLT を XML ドキュメントに適用する前または後に実行するカスタムスクリプトに任せるのは面倒です。

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

score 0 · Accepted Answer

あなたは正しいことをしたと思います。私の経験では、XSLT 開発者は雇うのが非常に難しい部類に属します。なぜなら、XSLT は Web 開発者にも一般のプログラマーにも受け入れられなかった言語だからです。

そのため、「メインストリーム以外の言語を知っている上級プログラマー」に割増料金を支払う必要がありますが、おそらくそのプログラマーの好みではない言語に対してです。

score 0 · Accepted Answer

ここで XSLT を使用する必要があるのは、特定の問題を解決するのは良い考えだと考える人がいたためです。複数の XML ファイルからデータを抽出し、それを結合して、さらに処理を行うさまざまなツールのさまざまな出力形式にする必要があります。

まず、XSLT は信頼できる標準であるため、非常に優れたアイデアだと思いました。これは、コード内に多くのプログラミングロジックやアルゴリズムを必要としない単純なフォーマットタスクに当てはまります。

ただし、手続き型ではないため、学習曲線はかなりの段階です。手続き型プログラミング (C、Java、Perl、PHP など) に慣れていると、多くの一般的な構造体を見落としたり、単純に面倒で、訓練されていない目では実際には読めないことがあることについて不思議に思うでしょう。たとえば、「再利用可能な」コードの作成: 手続き型プログラミングで、さまざまな場所で何度も何かを行う必要がある場合は、そのための関数を定義します。XSLT でそのようなことを達成することもできますが、より多くのコードを記述する必要があり、通常の関数ほど読みやすく/理解しにくいものです。

私が抱えている主な問題は、手続き型のバックグラウンドから来た多くの人々が今では XSLT ファイルに取り組んでおり、ほとんどの人が必要なものを「エミュレート」しただけだということです。

結論として、私は XSLT を「究極の」ソリューションとは考えていません。実際、XSLT でいくつかの構造を読み書きするのは面倒です。ほとんどの場合、アプリケーションについて考える必要があります。単純な変換には、おそらく XSLT を再度使用します。しかし、より複雑なソフトウェアについては、二度と使用しません。

score 0 · Accepted Answer

相互運用性について言えば、XML は情報ストレージの標準です。非常に多くのツールが XML で出力を生成します。アプリにブラウザーを埋め込み、XML をフォーマットしてブラウザーに配置するよりも優れた (または簡単な) 方法はありません。

score 0 · Accepted Answer

I did use XSLT extensively ... for a couple of hours. It's cool for things like changing element names or filtering an input document (stripping stuff away that you don't need).

Anything else gets complex very quickly. This inherit complexity plus the lack of most things you're used from any other programming languages (like variables) and the easy ways to make XPath expressions unreadable, really hurt.

In the end, XSLT suffers from a schisma: Programmers don't like it because of the limitations and everyone else can't use it at all (say, web designers or any other non-programmer type).

If XSLT had been promoted as some kind of SQL for XML, things would be a bit different. First, people wouldn't have even bothered to look at it. And those who did wouldn't have been surprised by the pain.

score 0 · Accepted Answer

I think the concept is sound, perhaps the execution is not as 'clean' as it could be.

However I think it should be treated as a tool, it may not be wise to use it in every instance, however one should never ignore a tool when solving solutions.

I have seen very good XSLT, and also very bad use of XSLT, and I conclude some of it may be down to the skill of the developer. I think its one that requires for the developer to think in multiple domains at the same time.

Is it the future? maybe not, maybe there are better solutions..

I don't know what new technology is going to come along, but at least its best to learn it, increasing ones own tool set can't be a bad thing surely?

score 0 · Accepted Answer

XSLT 1.0 は、少なくともデスクトップおよびサーバーコンピューター上で最も移植性の高いコードの 1 つです。これらのシステムのほとんどに 1 つ (多くの場合、多数) のランタイムがあるためです。

Microsoft Windows には、少なくとも Windows 2000 以降のベースシステムにインストールされている MSXML があります。これは、MSIE、コマンドライン(WSH を使用)、または Office アプリケーションから使用できます。
Java ランタイム環境 (JRE) には XSLT ランタイムがあり、JRE はほとんどのデスクトップにインストールされています。
ほぼすべての主要な Web ブラウザに 1 つ搭載されています。オペラは例外です。
主要な GNU ベースのオペレーティングシステム (libxslt、xsltproc) にデフォルトでインストールされる無料の実装があります。
MacOS X はチェックしていませんが、少なくとも Safari には実装されています。

これにより、移植性と軽量/インストール不要の両方を必要とするアプリケーションを構築するのに適しています。

また、XSLT はランタイムのみを必要とし (コンパイラは不要)、任意のテキストエディターでコードを作成できます。そのため、どのデスクトップからでも簡単にプログラムを作成できます (言語をマスターすれば)。

html - XSLT はそれだけの価値がありますか?

41 に答える 41

Related

Reference