xmlベースのプログラミング言語
私は wikipedia-Category：XML-based programming languages を見ていました。
なぜ誰かが言語を設計するためにこのアプローチを取るのでしょうか？
それの利点は何ですか？
私はデメリットしか考えられません。
- 維持するのが難しい
- 読みにくい
- 書くのが難しい
xMLベースの言語の最大の利点の1つは、実装が簡単に見えることです。
いいえ、実際には、構文に関連するコンパイルエラーを診断し、無料で [〜＃〜] ast [〜＃〜] を提供する トンの検証パーサー が利用可能です
実行もまた、上記のASTを反復し、関数と変数のマップを保持することです。
コードはデータです。
むしろ、プログラムはデータです。ソースファイルは、このプログラムの特定のserializationにすぎません。このアイデアは、例えばLISPなどの同型言語で一般的です。このような言語は、プログラムコードとそれが操作しているデータの間の障壁を取り除きます。これは非常に強力で表現力がありますが、LISPコードの外観を「美しい」または「読みやすい」とは言いません。
XMLは、今日のエンタープライズプログラマにとってthe構造化データのシリアル化形式です。 XML処理に関して確立された大きなツールチェーンがあります。
- XMLでXMLを操作することを意図した言語を定義することは、このホモニコ性のために興味深い場合があります。例はXSLTです。理論的には、これはメタプログラミングを可能にしますが、正気な人がこれを行うことはないでしょう？
- テンプレート言語は、データとコードをほとんど分離しないことに関心があります。出力がXMLまたはHTMLである場合、XMLドキュメントをテンプレート/プログラムとして使用すると便利です。
- 汎用言語のコードをXMLに格納することは、それでも興味深い場合があります。ソースコードの代わりにXMLにシリアル化された抽象構文ツリーを格納することは、このコードがIDEを介して操作される場合に実行可能です。 ビジュアルプログラミングの場合。これは、「ソースコード」が実際のバイトコードイメージの単なる表現であるSmalltalk環境とは異なりません。
興味深いことに、XMLドキュメントはテンプレート化に使用されることもありますcode…* shudder *（依存性注入）。これは、一部のツールチェーンにおけるXMLの普遍性によるものであると考えています。マインドシェアXMLは、頼りになる構造化データ形式として持っています。
一般的には、XMLベースの言語ではなく、XSLTに集中します。
もちろんここには歴史があります。 XSLTは、SGMLのスタイル言語であるDSSSLの後継として考えられており、DSSSLの問題点を正しく理解しようとしました。 DSSSLの主な問題の1つは、その（スキームに似た）構文であると認識されており、スタイルシートとデータに同じ構文を使用することで解決策が広まったとの見方が広まりました。結局のところ、スタイルシートはプログラムロジックではなく構造化データで主に構成されるべきであり、そのデータのほとんどは、結果ツリーに追加するためのプロフォーマ（「テンプレート」）データで構成され、パラメータ化されています。
XSLTは、過度に冗長であるとしばしば認識されます。残念ながら多くの人がまだ使用しているXSLT 1.0の場合、それはおそらく本当ですが、問題は主にXSLT 2.0で解決されました。XSLT2.0は、同じ問題を解決する他の方法よりもはるかに簡潔です。
確かに欠点があります。目的に合わせて設計されたエディターを使用する義務があります（ただし、ほとんどのプログラマーは、すべての言語に構文指向のエディターを使用しますね）。この言語は、構成可能ではありません（ただし、XSLT 2.0で大幅に修正されています）。しかし、重要な利点もあります。
XSLTは非プログラマーによって広く使用されており、プログラマーにとっては、2つの構文ではなく1つの構文を習得するだけでよいという非常に大きな利点があります。文字のエンコードや特殊文字のエスケープ方法など、細かいことはすべて覚えておいてください。
XSLTを使用してXSLTコードを処理する機能は、想像以上に便利です。ほぼすべての大規模なXSLTプロジェクトはこの機能を利用しており、非常に大きなメリットをもたらします。たとえば、UIに数百のフォームがあり、それぞれが独自のスタイルシートによって生成された1つのオンラインバンキングシステムを見ましたが、スタイルシートは、コードの共通ライブラリから生成され、ルックアンドフィールの優れた再利用と一貫性を提供します。
XMLのような制約付き構文フレームワークを使用すると、言語の設計者は言語が進化すると同時にレベルの字句の一貫性を維持する必要があり、同時に優れた拡張性を提供するという、私が期待していなかった利点があります。 XQuery WGは、互換性を壊したり、癖を付けたりせずに言語を拡張する方法について常に議論しています。 XSLTは基本的に新しい要素と属性の定義に関する問題なので、XSLTにはそのような問題はありません。
XMLの多い環境（XSLTを考えてください）では、このようなものが便利であることがわかります。おそらく、すでにきちんとしたXMLエディターがあり、同じツールセットを使用してコードを生成できると便利です。また、コードが特定の標準やルールに準拠していることを確認するために、正当性検証ツールやその他のツールを簡単に作成できる場合もあります（たとえば、スキーマはビジネスロジックの移動先を定義し、一貫性のある方法ですべての変数を初期化します。 ）。
XSLTは、私が使用した唯一のXMLプログラミング言語です。他の人とやり取りする機会や機会がありませんでした。
1つのXMLファイルをデータベースに送信する1つのメインアプリケーションがあり、他のいくつかのアプリケーションはそのファイルを取得してXSLTファイルを適用し、他のアプリケーションが必要とするデータを抽出できます。これにより、新しいセットのエクスポートの必要性が軽減されます。付属する新しいアプリケーションごとのデータ。それは大きなプラスだと思います。新しいアプリケーション用に1つのXSLTファイルをコーディングするだけで、新しいアプリケーション用の新しい情報を生成する必要はなく、すでに生成されている情報をデコードできます。
私はあなたが挙げた他の言語には触れなかったと思いますが、そのような言語の使用に適した場所のアイデアをあなたに与えました。私があなたの質問に完全に答えたのか、それとも部分的に答えたのかさえわかりません。うまくいけば、私はいくつかの洞察を与えました。