xml - なぜ XSLT は、インターネットブームの間に出現した他の多くの言語の人気を見たことがないのでしょうか?

Question

XSLT (XML Stylesheet Language Transform) の使用は、インターネットブームの間に登場した他の多くの言語ほど人気がありませんでした。それが使用されており、場合によっては大成功を収めている企業 (例: Blizzard Entertainment) によって使用されていますが、主流に達することはないようです。これはなぜだと思いますか？

score 26 · Accepted Answer

1 つの問題は、XSLTが複雑に見えることです。他のほとんどの言語には類似物があるため、どの開発者も言語構造を理解できるはずです。問題は、構造体とデータがすべてまったく同じに見えるため、この 2 つを区別するのが難しく、XSLT が他の言語よりも読みにくいことです。

2 つ目の問題は、その用途が他の言語よりも限られていることです。XSLT は優れた機能を備えています。XML で複雑または抜本的な変換を行う。しかし、他の言語ほど広範囲の問題には適用されないため、あまり使用されていません。

第 3 に、多くのプログラミング言語には、XML を変換するための独自のライブラリがあります。XML を扱う場合、多くの場合、必要なのは小さな変更またはルックアップだけです。XML は、開発者が既に別の言語で作成しているプログラムによって生成または使用されている可能性もあります。これらの要因は、言語の組み込みユーティリティを使用する方が便利であることを意味します。

これらすべての問題が関係するもう 1 つの問題は慣性です。つまり、人々はそれを知らず、その必要性をあまり認識していないため、別の選択肢がある場合の解決策としてそれを避けています。

最終的に得られるのは、ソリューションを作成する際に多くの開発者が最終的に選択する言語です。結果として、XSLT が仕事に最適なツールである場合でも、XSLT は避けられる可能性があります。

score 8 · Accepted Answer

XSLTは関数型プログラミングを使用します-ほとんどのプログラマーが慣れていないものです（したがって、一部の人々はそれを直感的ではないと考える理由です）。

score 7 · Accepted Answer

私の意見では、標準 XSLT (XSLT 1.0 について話しているのは、私が使用した唯一のバージョンであるため) で最も厄介なことの 1 つは、文字列変換といくつかの基本的な日時関数操作のサポートが欠けていることです。

私が理解できなかったことの 1 つは、 translate() などの関数が設計されて xpath に実装されたのに対し、 replace、to_lower、to_upper などの他のより便利な関数、または-クレイジーにしましょう-正規表現はそうではなかった理由です。

これらの問題のいくつかは、Microsoft の MSXML 以外のパーサー用のeXSLT (拡張 xslt ?) で解決されたと思います。MSXMLと互換性がないと宣言されていたので、実際には使用したことがないためだと思います。

ファイルを変換するときはいつでも文字列変換の問題を回避できないことが明らかな場合に、「テキスト」操作は言語の範囲に含まれないという原則で XSLT 1.0 が設計された理由がわかりません (例:フランス語形式で指定された日付がアメリカ形式に不規則にパディングされた、2008 年 1 月 31 日から 2008 年 1 月 31 日まで）ハァッ...

これらのテキスト操作の問題は一般に非常に基本的なものであり、XSL を JScript 関数で拡張できるようにすることで、MSXML で簡単に対処できます。XSL テンプレートを呼び出すのと同じように、JScript 関数を呼び出して何らかの処理を実行できますが、その解決策は洗練されておらず、独自の XSL テンプレートライブラリを作成することになりました。まず、JScript の方法が XSL の移植性を壊したためです。次に、プログラミングロジックを混在させる必要があったためです。純粋な XPath/XSLT 式のビットと DOM/オブジェクト表記の他のビットを JScript と混合する必要がありました。

更新可能な変数がないことは、初心者にとって非常に混乱を招くもう 1 つの制限です。これを克服できず、苦労し続ける人もいます。いくつかの単純なケースでは、パラメーター化されたテンプレートと再帰呼び出し (たとえば、増加または減少するカウンターを実装するため) を組み合わせて回避策を講じることができますが、再帰はそれほど自然ではありません。

これらの制限はすべて XSLT 2.0 仕様で対処されたと聞いたと思いますが、残念ながら MS はそれを実装せず、代わりに XQuery を推進することにしました。悲しいことに、両方を実装してみませんか? XSLT は、CSS が HTML で普及したのと同じくらい普及する可能性が十分にあると思います。考えてみると、XSLT を学ぶ上で最も難しいのは XPath であり、残りは CSS のカスケード動作を理解するほど難しくなく、CSS は非常に普及しています...

したがって、私の意見では、ここで言及されているすべてのささいなことの欠如と、XSLT 2.0 でそれらに対処するのに時間がかかった (とにかく MS でさえそれをサポートしていない) ことが、この不人気の状況につながっています。結局、MSがそれを実装することを決めたらいいのに...

score 5 · Accepted Answer

ほとんどの XSLT 実装はメモリフットプリントが大きいため (これは言語の設計が原因だと思います)、人々は XSLT が特に適していないあらゆる種類のことや XSL の純粋に宣言的な性質のために、XSLT を悪用する傾向があったためです。これにより、特定の種類の変換が非常に困難になります。

score 4 · Accepted Answer

これはxmlには最適ですが、通常のコーディングには適していません。それは典型的な基本概念（すなわち可変変数）を欠いており、単純であるべきものを非常に複雑（または不可能）にします。その問題のほとんどは、xmlが優れたデータ表現言語であるが、優れたプログラミング言語ではないという事実に起因しています。そうは言っても、私は毎日それを使用し、それが理にかなっているところでそれをお勧めします。外部の名前空間と組み合わせて、より便利にすることができます（Javaの呼び出しなど）。結局、それは学ぶべき別の言語であり、多くのコーダーは、彼らが慣れているもの、または彼らが慣れているものに似ているものに固執することを好むでしょう。

score 4 · Accepted Answer

Java、C#、JavaScript などを使用して XML ストリームを逆シリアル化し、変換し、目的の出力をエクスポートするコードを作成して維持する方が簡単であり、XSLT は実質的なパフォーマンス上の利点を提供しないためです。

XSLT は何かを簡単にしますが、他のことを非常に困難にします。

score 3 · Accepted Answer

XSL は主流であり、広く採用されています。他にどの言語を参照していますか? XSL はプログラミング言語ではなく、単なる変換言語であるため、範囲がかなり限定されています。

score 3 · Accepted Answer

うーん...おそらく、xsltsを書くのは面倒だから...数ヶ月前にいくつかのxsltsを書かなければならず、先のとがった括弧を夢見ていた...

<Really> 
    <No>
        <fun/>
    </No>
</Really>

（これはxsltではないことは知っています）

score 3 · Accepted Answer

一般に、XML データを別の形式の XML データに変換する必要があり、それに対して他の処理を行わない場合は非常に限られています。通常、XML は 2 つの別個のシステム間の仲介として使用されます。一方は通常、他方の出力を処理するためにカスタム作成されます。そのため、システムの 1 つを作成して、他のシステムの XML 出力を処理する方が簡単です。何らかの変換を実行する必要はありません。

score 3 · Accepted Answer

前述のように、XSLT (JavaScript の「優れた部分」と同様) は関数型プログラミング言語です。ほとんどの伝統的なプログラマーは、このステートレス性を嫌います。また、あまりにも多くの伝統的なプログラマーが山括弧を嫌っています。

しかし、最も重要なことは、XSLT を正しく使用することで、プラットフォームにとらわれない方法で、Web サーバーの宣言型 GUI 生成とデータバインディングの問題の両方を解決できることです。Microsoft のようなベンダーは、この「不便な」パワーを称賛する気はありません。

ただし、Microsoft は世界で最も優れた IDE (Visual Studio) の XSLT サポートを提供していると主張します。

score 2 · Accepted Answer

要約すると、XML構文はデータの記述には間違いなく適していると思いますが、本質的にプログラミング言語（XSLT）の構文としては優れていません。

score 1 · Accepted Answer

xslt は、既にエスケープされたデータと入力と出力の明確な定義がある場合に、xml から xml に最適です。それを xml2html のようなものに使用することは、私には頭痛の種のように思えます。ほとんどすべての動的言語と css を使用すると、出力をスタイルで実装するのがはるかに簡単になります。

score 1 · Accepted Answer

「複合 Web サービスアーキテクチャ」には最適であることがわかりました。いくつかの Web サービスが連携して最終的な出力が得られることがあります。これらの Web サービスが XML を介して相互に通信する必要がある場合、XSLT は xml メッセージをある形式から別の形式に変換できます。

score 1 · Accepted Answer

あまりにも多くのユースケースをカバーしようとしたため、チューリング完全な (または私が聞いた) 言語になったと思います。自明でない変換を行おうとすると、複雑なループや条件を書くことになります...醜く冗長な言語で書くことになりますが、これは GPL で行うのが最適です。

私の見解では、この複雑さにより、XSLT の正しい実装を作成することが難しくなり、利用可能な選択肢が制限されます。そのため、エンタープライズコードではなく、小さくて効率的なコードをいじることを好む声のハッカーの間で広く使用されています。

score 1 · Accepted Answer

XSLT は非常に強力ですが、この問題については別の考え方が必要です。また、初期バージョンでは有用なデータ機能が提供されなかったため、それ自体が困難でした。ToUpper() スタイルのメソッドを例にとると、通常は次のように実装します。

<xsl:variable name="lcletters">abcdefghijklmnopqrstuvwxyz</xsl:variable>
<xsl:variable name="ucletters">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable>  

<xsl:value-of select="translate($toconvert,$lcletters,$ucletters)"/>

最も簡単なコーディング方法ではありません。

xml - なぜ XSLT は、インターネット ブームの間に出現した他の多くの言語の人気を見たことがないのでしょうか?

15 に答える 15

Related

Reference

xml - なぜ XSLT は、インターネットブームの間に出現した他の多くの言語の人気を見たことがないのでしょうか?