🕝 🥘 🔌 XML、RDF、およびI。 👨🏿‍🌾 👩🏾‍🚒 🌸

私の謙虚なブログで、私はXMLベースの言語とDOMに対する私の態度を大まかに概説しました。要するに、ウェブ上で彼らとほぼ一年働いた後、私はいくつかの結論に達しました。特に、DOMは複雑なWebページのコンテンツを表示するのに理想的ですが、このモデルを構築するXML自体は複雑すぎて冗長です。このようなメモに基づいて、私だけでなく、他の開発者も、 素晴らしいW3C自体も同様だと思います。

RDFについては、後で書くかもしれません。ここで、データ表現の問題におけるXMLに似た言語の非効率性の考え方にもっと焦点を当てたいと思います。このトピックは、RDFの利点と密接に重複しています。したがって、私が考えるように、このメモはその使用の実例と考えることができます。

簡単な例から始めましょう。アドレスでマップします。複雑なことは何もありません。

標準実装は、XMLツリー、JSONハッシュ、またはマップ上の座標、名前、住所、およびその他の情報を持つ一般的なJavaScriptです。ライブ例は、 http：//mirtesen.ru/ （ここではJSONを使用）またはhttp://adresa.yandex.ru/ （およびここではJavaScript）で見ることができます。

いくつかのレコードがありますが、これはすべてうまくいきます。ただし、レコード数が多くなると、まずファイルをダウンロードしてから解釈することに時間を費やします。 JSONとXMLの両方の問題は、ブラウザーがそれらを正しく解析し、意図した目的で使用するために、検証する前に完全にロードする必要があることです。読み込まれたJavaScriptでは、後続の各関数呼び出しは前のものに依存せず、理論的には、ファイルの完了を待たずにファイルの転送時に実行できるため、状況はややバラ色です。しかし、あなたは認めなければなりません、この方法は完全に無尽蔵であり、多くの余分な体の動きが必要です。 注目に値しますが、現在ではこのような問題を解決するために使用できる唯一のものです。 少なくとも私の情報によると、これはそうです。

DOMレベルでは、着信データストリームを簡単に処理し、転送中に表示を生成できます。わずらわしいのは、サーバーの応答を1行ずつ読み取ることができないことだけです（ただし、これにより、連続するリクエストの数が増加します。このタスクへの対処はそれほど悪くはありません：最初の20レコードをすべて取得し、それらをすべて引き出し、2番目の20を取り出し、それらを引き込みます。悪くなるなぜですか？例で説明してください。

プレーンXMLツリー

次のようになります。

 <ルート>
	 <要素>
		 <パラメーター>
			 <name> ID </ name>
			 <値> 1 </値>
		 </ parameter>
		 <パラメーター>
			 <name>タイトル</ name>
			 <value>最初の要素</ value>
		 </ parameter>
		 <パラメーター>
			 <name> Xcoord </ name>
			 <値> 100 </値>
		 </ parameter>
		 <パラメーター>
			 <name> Ycoord </ name>
			 <値> 100 </値>
		 </ parameter>
		 <パラメーター>
			 <name>説明</ name>
			 <値> <！[CDATA [...]]> </値>
		 </ parameter>
		 ...
	 </ element>
	 <要素>
		 <パラメーター>
			 <name> ID </ name>
			 <値> 2 </値>
		 </ parameter>
		 <パラメーター>
			 <name>タイトル</ name>
			 <value> 2番目の要素</ value>
		 </ parameter>
		 ...
	 </ element>
	 <要素>
		 ...
	 </ element>
 ...
 </ root>

多分私はそれを過度に複雑にしましたが、それは私の考えをより良く伝えるように思えます。（可能性のある間違いや間違いを事前に許してください。RDFは実際にはまだ使用していません。代わりに、簡潔さのために3番目の表記の構文と比較できないが、同様のアイデアを使用する悲惨な自己記述関数があります。） RDF表記法：

 @prefix：<＃>。

 ：element_1 a：要素。
	 ：element_1：ID 1。 
	 ：element_1：タイトル「最初の要素」。
	 ：element_1：Xcoord 100。
	 ：element_1：Ycoord 100。
	 ：element_1：説明「...」。
 ：element_2 a：要素
	 ：element_2：ID 2。
	 ：element_2：タイトル「2番目の要素」。
	 ...
 ：element_3 a：要素
 ...

または、もっと簡潔に書くには：

 @prefix：<＃>。

 ：element_1 a：要素;  ：ID 1;  ：タイトル「最初の要素」;  ：Xcoord 100;  ：Ycoord 100;  ：Ycoord 100;  ：説明「...」。
 ：element_2 a：要素;  ：ID 2;  ：タイトル「最初の要素」;  ：Xcoord 200;  ：Ycoord 200;  ：Ycoord 100;  ：説明「...」。
 ：element_3 a：要素;  ：ID 3;  ：タイトル「最初の要素」;  ：Xcoord 300;  ：Ycoord 300;  ：Ycoord 100;  ：説明「...」。

また、私があなたを欺いたり、自分のために何かを描いたりしないようにするために、3番目の記法の構文の他の例を見ることができます。

レコードにはルート要素が記載されていないことに注意してください。ルート要素がないとXMLファイルを作成できません。より簡潔な構文はおそらく無視できます。必要に応じて、XMLをタンピングすることもできます。違いの1つは、要素の一意の名前です。一見基本的な違いがないにもかかわらず、これは重要です。まあ、多分それはもう少し読みやすく、異なった配置になったかもしれません。それだけです。しかし、違います。一意の要素名を使用すると、1つの焦点を絞ることができます。式全体を必要な順序で並べ替えることができます。例：

 @prefix：<＃>。

 ：element_1 a：要素;  ：ID 1;  ：Xcoord 100;  ：Ycoord 100。
 ：element_2 a：要素;  ：ID 2;  ：Xcoord 200;  ：Ycoord 200。
 ：element_3 a：要素;  ：ID 3;  ：Xcoord 300;  ：Ycoord 300。
 ...
 ：element_1：タイトル「最初の要素」。
 ：element_2：タイトル「2番目の要素」。
 ：element_3：タイトル「3番目の要素」。
 ...
 ：element_1：説明「...」。
 ：element_2：説明「...」。
 ：element_3：説明「...」。
 ...

耳に似たフェイントを与えるものは何ですか？少量のデータで使用する場合、ほとんど何もありません。しかし、大量のデータがある場合、Webアプリケーション（タグと同じマップを例として使用）は異なる動作を開始します。 JSONまたはXMLを使用してデータをロードする場合のように、ラベルごとにラベルを表示する代わりに？最初にすべてのラベルを描画し、それらにイベントをバインドし、他のデータにメモリスペースを割り当ててから、徐々にラベルをデータに追加する機会を得ます。タイトルを表示し、説明を表示してから写真をアップロードします...リストは延々と続きます。同時に、IDが最初にロードされるため、ユーザーが2番目のストリームの特定の要素のデータを要求することで関心を示している場合、Webアプリケーションに任意のオブジェクトのデータの取得を強制することはありません。このような例を、アクティブな大規模なアプリケーションで補間すると、ほぼすべてのタスクで一貫した詳細を取得する機会が得られます。ユーザーは、最終データのダウンロードを待たずにWebアプリケーションとの対話を開始できます。また、くしゃみごとにデータを要求することなく、対話を続けます。悪くないですか？

そのようなチップのすべての魅力に納得していない人には、さらにいくつかの理由をあげよう。まず、このようなシステムはRDFを導入せずに実装できるという事実にもかかわらず、サーバーの応答でスクリプトを使用して同様の何かをエミュレートするか、いくつかの連続したリクエストを行う必要があります。第二に、RDF構文はデータベースからのデータ出力に非常に似ており、コンテキストにアタッチされないようにします。実際には、これにより、最初のクエリの結果がブラウザで既に処理され、データベースへの最後のクエリがまだ実行を完了していない状況が発生する可能性があります。きれいじゃないですか？

PS私は何かについて間違っている場合-私を修正し、私は感謝します。

ZYY とオリジナルはここにあります

XML、RDF、およびI。

More articles: