xmlベースのプログラミング言語


8

私はウィキペディア-Category:XMLベースのプログラミング言語を見ていました。

言語を設計するために誰かがこのアプローチを取るのはなぜですか
それの利点は何ですか?

私はデメリットしか考えられません。

  • 維持するのが難しい
  • 読みにくい
  • 書くのが難しい

2
通常、プログラマー以外の人が何かを行うために使用する他のプログラム(ビジュアルインターフェースなど)がいくつかあり、XMLとして格納され、XMLとして処理されます。

2
私はあなたの欠点に同意します。Coldfusionを使用すると、Coldfusionに対して行う議論は非常に明確です。
Rig

@リグ:Coldfusionは実際にはOPがリンクするリストに含まれていません。
FrustratedWithFormsDesigner 2013年

考えられる利点は、そのようなシステムがXQueryおよびXPathクエリと式を使用して自己変更コードを簡単に作成できることだと思います。XPath / XQueryを介して機能する自己変更コードが実際に良いものであるかどうかは議論の余地があります...
FrustratedWithFormsDesigner

1
@ Mhd.Tahawi:プログラムコードが有効なXMLとして記述されている場合、プログラムはXPath / XQueryを使用してそれ自体でリフレクションを実行できます。XSLTと共に使用すると、XSLTを使用して自分自身を変更できるプログラムを作成するXMLベースのプログラミング言語を設計できる場合があります。そのようなプログラムに対処しなければならないのかどうかはわかりませんが、目新しさの観点から見ると、すばらしいかもしれません。
FrustratedWithFormsDesigner

回答:


4

XMLベースの言語の最大の利点の1つは、実装が簡単に見えることです。

いいえ、実際には、構文関連のコンパイルエラーを診断し、無料でASTを提供する、利用可能な検証パーサーがたくさんあります。

実行は、上記のASTを単純に繰り返し、関数と変数のマップを保持する


3
「Seem」がここのキーワードです。真実は、これらの利点はかなり小さいか存在しないかのどちらかですが、言語実装を作成したことがない場合は確かにそのように見えます。解析は計算コストがかかりますが、実際には実装(パーサージェネレーターまたは手書き)および設計(構文は安価)するためのより単純な部分の1つです。また、ASTを取得すると、処理方法は解析方法の影響を受けません。つまり、実行が単純な場合は、別の構文を選択しても単純なままです(明らかに、セマンティクスを保持している場合のみ)。

@delnanその通りです。XMLが無料で提供しているように思えるのは、簡単な部分だけです。実際には何も提供していないので、「見かけ」と言います。単にそれをユーザーにプッシュするか、何らかの(おそらく複雑な)カスタムGUIをプッシュするだけです。
Evicatos 2013年

10

コードはデータです。

むしろ、プログラムはデータです。ソースファイルは、このプログラムの特定のシリアル化です。このアイデアは、例えばLispのような同型言語で一般的です。このような言語は、プログラムコードとそれが操作しているデータの間の障壁を取り除きます。これは非常に強力で表現力がありますが、Lispコードの外観を「美しい」または「読みやすい」とは言いません。

XMLは今日のエンタープライズプログラマにとって構造化データのシリアル化形式です。XML処理の周りに確立された大きなツールチェーンがあります。

  • XMLでXMLを操作することを意図した言語を定義することは、このホモニコ性のために興味深い場合があります。XSLTがその例です。理論的には、これはメタプログラミングを可能にしますが、正気な人はこれを行いませんよね?
  • テンプレート言語は、データとコードをほとんど分離しないことに関心があります。出力がXMLまたはHTMLである場合、XMLドキュメントをテンプレート/プログラムとして使用すると便利です。
  • 汎用言語のコードをXMLに格納することは、それでも興味深い場合があります。このコードは、のために、それはより多くの人が読める形式で提示されたIDE、を介して、例えば操作されたときに抽象構文木ではなく、ソースコードのXMLにシリアライズ保存することは実行可能であるビジュアルプログラミング。これは、「ソースコード」が実際のバイトコードイメージの単なる表現であるSmalltalk環境とは異なりません。

興味深いことに、XMLドキュメントは、コードのテンプレート化に使用される場合があります。* *シャダー*(依存性注入)。これは、一部のツールチェーンにおけるXMLの普遍性に起因すると考えられます。MindshareXMLは、構造化されたデータ形式としてすぐに使用できます。


1
コードとデータを一致させることは利点ではありません。言語レベルでのセキュリティホールです。典型的な例はSQLインジェクションです。あるサイトがハッキングされ、数百万ドル相当の損害が発生し、何万人ものユーザーがSQLインジェクションの悪用により新しいクレジットカードを注文しなければならないたびに、根本的な理由は、開発者が設定したためですコードからデータを適切に分離なかった何らかの方法でクエリをセットアップします 「ホモコニコニティー」のような派手な言葉を投げかけても、この基本的な事実は変わりません。
メイソンウィーラー

5
@MasonWheeler すべてのテンプレートシステムのセキュリティの観点から適切なエスケープが必要であることにまったく同意しませんが、これは質問、私の回答、またはデータコードの分離とは何の関係もありません。私がrwx持っているこれらのスクリプトについて心配する必要はありません。それらは私のエディター用のデータですが、私のシェル用の実行可能コードです。
2013年

1
最初にエスケープするという点でこれに対応しようとするという事実-これは、SQLインジェクションを防ぐための間違った方法であり、パラメーターを介したコードからのデータの分離という点ではなく-それを行う唯一の正しい方法-あなたが本当に問題を理解していないことを示しています。そして、それがSQLインジェクション攻撃が発生し続ける理由です。人々は、これらのことがなぜ重要であり、どのように正しく行うのかを理解していません。
メイソンウィーラー

7
@MasonWheeler:外部ソースからデータを取得し、そこからコードを作成する場合、「データとコードを組み合わせる」という批判は正しいです(ちなみに、これはXMLにとって特別なことではありません)。しかし、この答えは完全に異なる焦点を持っています。それはメタプログラミングの側面についてです。
Doc Brown、

6
@MasonWheeler、注入は実行すべきでないデータを実行しています。同型性とは、コードとデータが文字通り、プログラムによる操作において、非常に似ていることを意味します。ホモニコ言語は、ソースコードなどにハードコードされていても、信頼できるデータを安全に操作して実行(コードから生成)できます。たとえばCommon Lispでは、のように、実行せずに生成コードにデータを含めることができます(eval `(foo (quote ,data)))。パラメータとエスケープについてのあなたの主張は正しいかもしれませんが、あなたは要点を逃しました。
2013年

2

一般的には、XMLベースの言語ではなくXSLTに集中します。

もちろんここには歴史があります。XSLTは、SGMLのスタイル言語であるDSSSLの後継として考えられており、DSSSLの問題点を正しく理解しようとしました。DSSSLの主な問題の1つは、その(スキームに似た)構文であると認識されており、このソリューションはスタイルシートとデータに同じ構文を使用することにありました。結局のところ、スタイルシートはプログラムロジックではなく構造化データで主に構成されるべきであり、そのデータの多くは、パラメーター化された結果ツリーに追加するためのプロフォーマ(「テンプレート」)データで構成されるということです。

XSLTは、過度に冗長であるとしばしば認識されます。残念ながら多くの人がまだ使用しているXSLT 1.0の場合、それはおそらく本当ですが、問題は主にXSLT 2.0で解決されました。これは多くの場合、同じ問題を解決する他の方法よりもはるかに簡潔です。

確かに欠点があります。目的に合わせて設計されたエディターを使用する義務があります(ただし、ほとんどのプログラマーは、すべての言語に構文指向のエディターを使用しますね)。この言語は、構成可能ではありません(ただし、XSLT 2.0は主にそれを修正しています)。しかし、重要な利点もあります。

  1. XSLTは、非プログラマーによって広く使用されており、プログラマーにとっては、2つの構文ではなく1つの構文を習得するだけでよいという非常に大きな利点があります。文字のエンコードや特殊文字のエスケープ方法など、細かいことはすべて覚えておいてください。

  2. XSLTを使用してXSLTコードを処理する機能は、想像以上に便利です。ほぼすべての大規模なXSLTプロジェクトはこの機能を利用しており、非常に大きなメリットをもたらします。たとえば、UIに数百のフォームがあり、それぞれが独自のスタイルシートによって生成された1つのオンラインバンキングシステムを見ましたが、スタイルシートは、コードの共通ライブラリから生成され、ルックアンドフィールの優れた再利用と一貫性を提供します。

  3. XMLのような制約付きの構文フレームワークを使用すると、言語の設計者は言語が進化すると同時にレベルの字句の一貫性を維持する必要があり、同時に優れた拡張性を提供するという、私が期待していなかった利点があります。XQuery WGは、互換性を壊したり、癖を付けたりせずに言語を拡張する方法について常に議論しています。XSLTは基本的に新しい要素と属性を定義する問題なので、XSLTにはそのような問題はありません。


0

XMLの多い環境(XSLTを考えてください)では、このようなものが便利であることがわかりました。おそらくすでにきちんとしたXMLエディターがあり、同じツールセットを使用してコードを生成できると便利です。また、コードが特定の標準やルールに準拠していることを確認するために、正当性検証ツールやその他のツールを簡単に作成できる場合もあります(たとえば、スキーマはビジネスロジックの移動先を定義し、一貫性のある方法ですべての変数を初期化します。 )。


0

XSLTは、私が使用した唯一のXMLプログラミング言語です。他の人とやり取りする機会や機会がありませんでした。

1つのXMLファイルをデータベースに送信する1つのメインアプリケーションがあり、他のいくつかのアプリケーションは、そのファイルを取得してXSLTファイルを適用し、他のアプリケーションが必要とするデータを抽出できます。これにより、新しいセットのエクスポートの必要性が軽減されます。付属する新しいアプリケーションごとのデータ。それは大きなプラスだと思います。新しいアプリケーション用に1つのXSLTファイルをコーディングするだけで、新しいアプリケーションの新しい情報を生成する必要はなく、すでに生成されている情報をデコードできます。

リストに挙げた他の言語には触れていませんが、そのような言語を使用するのに適した場所を教えてくれました。私があなたの質問に完全に答えたのか、それとも部分的に答えたのかさえわかりません。うまくいけば、私はいくつかの洞察を与えました。


2
いいえ、質問では、XSLT自体をXMLにする必要がある理由を尋ねます。説明したツールチェーンは、出力XMLを解析し、そこから出力を生成するPerlまたはPythonスクリプトを使用して実装することもできます。XSLTについての興味深い設計上の決定は、それがXMLを変換することができますということではなく、むしろそれは巻き毛braces⸮を使用していないこと
アモン

またはセミコロン?あなたの言っていることがわかります。どのような言語でも、XMLドキュメントからその情報を実際に解析できるので、問題は「なぜXML変換言語が必要なのか」です。
マラキ2013年

いいえ、XML変換言語は理にかなっています(多くのXML変換を行う場合)。XSLTがXML処理をサポートするために行うことはたくさんあります(たとえば、DOMツリーを簡単にトラバースしてクエリを実行する機能など)。

私は最後のコメント@delnanで質問を明確にしようとしていましたが、XSLTは素晴らしいツールであることを理解し、同意します。
マラキ2013年

-3

XMLは、歴史的および政治的背景がないとほとんど意味がありません。SGMLは、書き込み、読み取り、保守がさらに困難でしたが、1986年にISOの承認スタンプが押されたため、おそらくこのような不細工を持つ最初のデータ宣言言語になりました。

1990年代初頭にTim Berners-LeeをHTMLの基礎として使用するように促すには、十分に有用であり、文書化されていました。覚えておいてください、彼はワールドワイドウェブを作成するつもりでした、そしてそれを現存するISO標準に基づいて置くことはさらにそれをかなり助けるでしょう。

その後、1990年代後半にWebがかなり定着し、World Wide Web Consortiumはデータ交換のための標準的な構造的マークアップのイニシアチブを開始しました。XMLを取り巻く誇大宣伝要素は、これまでにないレベルの「私たちはこれで何をすべきかはわかりませんが、本当にクールだと思います」のレベルに達しました。

現状では、XMLが最も適しているのは、異種システム間の構造化データ交換です。amonが述べたように、より広い有用性を持つ特定のドメインがいくつかあります。落書きを標準化されたマークアップにエンコードできるようになったことをうれしく思います。将来的に、子供たちは命や告訴の危険を冒す必要がなくなり、代わりにリモートコントロールされた無人のドローンを使ってタグ付けを行うことができます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.