एक्सएमएल, आरडीएफ, और आई।

अपने विनम्र ब्लॉग में, मैंने मोटे तौर पर XML- आधारित भाषाओं और DOM के प्रति अपने दृष्टिकोण को रेखांकित किया। संक्षेप में, वेब पर उनके साथ काम करने के लगभग एक साल बाद, मैं कुछ निष्कर्षों पर आया। विशेष रूप से, डोम जटिल वेब पेज सामग्री को प्रदर्शित करने के लिए आदर्श है, लेकिन जिस XML से यह मॉडल बनाया गया है वह स्वयं बहुत जटिल और निरर्थक है। इस तरह के नोटों के आधार पर, मुझे लगता है कि न केवल मैं, बल्कि अन्य डेवलपर्स, साथ ही महान और भयानक डब्ल्यू 3 सी भी ।





RDF के बारे में, मैं बाद में लिख सकता हूं। अब मैं डेटा प्रतिनिधित्व के मुद्दे में XML जैसी भाषाओं की अक्षमता के विचार पर अधिक ध्यान केंद्रित करना चाहता हूं। यह विषय RDF के लाभों के साथ निकटता से है। इसलिए, जैसा कि मुझे लगता है, इस नोट को इसके उपयोग का एक चित्रण माना जा सकता है।





एक सरल उदाहरण से शुरू करते हैं। पते के साथ नक्शा। इसके बारे में कुछ भी जटिल नहीं है।

मानक कार्यान्वयन या तो XML ट्री, एक JSON हैश, या मैप, नाम, पते और अन्य जानकारी के निर्देशांक के साथ सामान्य जावास्क्रिप्ट जावास्क्रिप्ट है। लाइव उदाहरण http://mirtesen.ru/ (यहां JSON का उपयोग किया जाता है) या http://adresa.yandex.ru/ (और यहां जावास्क्रिप्ट) पर देखा जा सकता है





यह सब महान काम करता है जबकि हमारे पास कुछ रिकॉर्ड हैं। लेकिन अगर रिकॉर्ड की संख्या बड़ी हो जाती है, तो हम पहले फ़ाइल डाउनलोड करने में समय बिताते हैं, और फिर उसकी व्याख्या करते हैं। JSON और XML दोनों के साथ समस्या यह है कि वे पूरी तरह से लोड होने से पहले उन्हें मान्य किया जाना चाहिए ताकि ब्राउज़र उन्हें सही ढंग से पार्स करे और उनका उपयोग उनके इच्छित उद्देश्य के लिए करे। भरी हुई जावास्क्रिप्ट के साथ, स्थिति कुछ हद तक रसीली है, क्योंकि प्रत्येक बाद के फ़ंक्शन कॉल पिछले वाले पर निर्भर नहीं करते हैं और, सिद्धांत रूप में, निष्पादित किया जा सकता है, जबकि फ़ाइल को स्थानांतरित किया जा रहा है, इसके पूरा होने की प्रतीक्षा किए बिना। लेकिन, आपको स्वीकार करना चाहिए, यह विधि पूरी तरह से अक्षम है, और शरीर की अतिरिक्त गतिविधियों की बहुत आवश्यकता है। हालांकि, यह ध्यान देने योग्य है, अब यह एकमात्र है जिसका उपयोग ऐसी समस्याओं को हल करने के लिए किया जा सकता है। कम से कम मेरी जानकारी के अनुसार, ऐसा है।





DOM स्तर पर, हम आने वाले डेटा स्ट्रीम को आसानी से संसाधित कर सकते हैं, स्थानांतरण के दौरान उनके प्रदर्शन को सही बना सकते हैं। केवल एक चीज जो हमें परेशान करती है वह है लाइन द्वारा सर्वर रिस्पांस लाइन को पढ़ने में असमर्थता :(। लेकिन इससे लगातार अनुरोधों की संख्या में वृद्धि होती है। (पहले हमें 20 रिकॉर्ड मिलते हैं, फिर हमें 21 वें से 40 वें स्थान तक का रिकॉर्ड मिलता है।) इस कार्य के साथ मुकाबला करना इतना बुरा नहीं है: हमें पहले बीस रिकॉर्ड मिलते हैं, उन सभी को बाहर निकालना है, दूसरा बीस प्राप्त करना है, उन्हें ड्रा करना है। और इसलिए जब तक हम सभी रिकॉर्ड नहीं दिखाते हैं। बुरा नहीं है। वास्तव में नहीं। अधिक जानकारी के लिए हमें प्रदर्शित करने की आवश्यकता है। इससे भी बदतर है क्यों? उदाहरण के साथ समझाने की कोशिश करें।





सादा XML पेड़

इस तरह दिखता है:

 <रूट>
	 <तत्व>
		 <पैरामीटर>
			 <नाम> ID </ name>
			 <value> 1 </ value>
		 </ पैरामीटर>
		 <पैरामीटर>
			 <नाम> शीर्षक </ name>
			 <value> पहला तत्व </ value>
		 </ पैरामीटर>
		 <पैरामीटर>
			 <नाम> Xcoord </ name>
			 <value> 100 </ value>
		 </ पैरामीटर>
		 <पैरामीटर>
			 <नाम> योकोर्ड </ name>
			 <value> 100 </ value>
		 </ पैरामीटर>
		 <पैरामीटर>
			 <नाम> विवरण </ name>
			 <value> <! [CDATA [...]> </ value>
		 </ पैरामीटर>
		 ...
	 </ तत्व>
	 <तत्व>
		 <पैरामीटर>
			 <नाम> ID </ name>
			 <value> 2 </ value>
		 </ पैरामीटर>
		 <पैरामीटर>
			 <नाम> शीर्षक </ name>
			 <value> दूसरा तत्व </ value>
		 </ पैरामीटर>
		 ...
	 </ तत्व>
	 <तत्व>
		 ...
	 </ तत्व>
 ...
 </ रूट>

हो सकता है कि मैंने इसे पूरा कर लिया हो, लेकिन ऐसा लगता है कि यह मेरे विचार को बेहतर तरीके से व्यक्त करेगा। (मैं आपसे संभावित गलतियों और गलतियों के लिए अग्रिम रूप से क्षमा करने के लिए कहता हूं। मैंने अभी तक अभ्यास में आरडीएफ का उपयोग नहीं किया है। इसके बजाय, मेरे पास एक गलत स्व-लिखित फ़ंक्शन है, जिसकी संक्षिप्तता से, तीसरे अंकन के वाक्य विन्यास के साथ तुलना नहीं की जा सकती है, लेकिन समान विचारों का उपयोग करता है।) अब हम इसे तीसरे में अनुवाद करते हैं। RDF संकेतन :

 @ उपसर्ग: <#>।

 : 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: शीर्षक "दूसरा तत्व"।
	 ...
 : element_3 a: तत्व
 ...

या, अधिक संक्षेप में लिखने के लिए:

 @ उपसर्ग: <#>।

 : element_1 a: तत्व;  : आईडी 1;  : शीर्षक "पहला तत्व";  : Xcoord 100;  : योकॉर्ड 100;  : यार्क 100;  : विवरण "..."।
 : element_2 a: तत्व;  : आईडी 2;  : शीर्षक "पहला तत्व";  : Xcoord 200;  : यार्क 200;  : यार्क 100;  : विवरण "..."।
 : element_3 a: तत्व;  : आईडी 3;  : शीर्षक "पहला तत्व";  : Xcoord 300;  : यार्क 300;  : यार्क 100;  : विवरण "..."।

आप तीसरे संकेतन के वाक्य-विन्यास के अन्य उदाहरणों को भी देख सकते हैं, ताकि यह सुनिश्चित हो सके कि मैं आपको धोखा नहीं देता या अपने लिए कुछ आकर्षित नहीं करता।



मैं यह नोट करना चाहता हूं कि रिकॉर्ड रूट तत्व का उल्लेख नहीं करता है, जिसके बिना कोई XML फ़ाइल नहीं कर सकता है। आप शायद अधिक संक्षिप्त वाक्यविन्यास को अनदेखा कर सकते हैं। यदि वांछित है, तो XML को टैम्प भी किया जा सकता है। मतभेदों में से एक तत्वों का अद्वितीय नाम है। यह इस तथ्य के बावजूद महत्वपूर्ण है कि पहली नज़र में, कोई बुनियादी मतभेद नहीं हैं। खैर, शायद यह थोड़ा और पठनीय हो गया है, अलग तरह से व्यवस्थित किया गया है, और यह सब। लेकिन नहीं। अद्वितीय तत्व नाम हमें एक ध्यान केंद्रित करने की अनुमति देते हैं - हम अब पूरी अभिव्यक्ति को उस क्रम में क्रमबद्ध कर सकते हैं जिसकी हमें आवश्यकता है। उदाहरण के लिए:

 @ उपसर्ग: <#>।

 : element_1 a: तत्व;  : आईडी 1;  : Xcoord 100;  : यार्क 100।
 : element_2 a: तत्व;  : आईडी 2;  : Xcoord 200;  : यार्क 200।
 : element_3 a: तत्व;  : आईडी 3;  : Xcoord 300;  : यार्क 300।
 ...
 : element_1: शीर्षक "पहला तत्व।"
 : element_2: शीर्षक "दूसरा तत्व"।
 : element_3: शीर्षक "तीसरा तत्व।"
 ...
 : element_1: विवरण "..."।
 : element_2: विवरण "..."।
 : element_3: विवरण "..."।
 ...

हमें कानों के साथ एक समान जंतु क्या देता है? कम मात्रा में डेटा के साथ इसका उपयोग करते समय लगभग कुछ भी नहीं। लेकिन अगर बहुत अधिक डेटा है, तो वेब एप्लिकेशन (उदाहरण के रूप में टैग के साथ एक ही नक्शे का उपयोग करके) अलग तरह से व्यवहार करना शुरू कर देता है। JSON या XML का उपयोग करके डेटा लोड करने के मामले में, लेबल द्वारा पूरी तरह से लेबल प्रदर्शित करने के बजाय? इसे पहले सभी लेबलों को आकर्षित करने, घटनाओं को उनके साथ बाँधने और अन्य डेटा के लिए मेमोरी स्पेस आवंटित करने का अवसर मिलता है और फिर धीरे-धीरे उन्हें डेटा से भर दिया जाता है। शीर्षक दिखाएं, फिर वर्णन करें, और फिर चित्र अपलोड करें ... सूची आगे बढ़ती है। उसी समय, कोई भी व्यक्ति वेब एप्लिकेशन को एक मनमानी वस्तु पर डेटा प्राप्त करने के लिए मजबूर करने के लिए परेशान नहीं करता है, अगर उपयोगकर्ता ने दूसरी धारा में एक विशिष्ट तत्व पर डेटा का अनुरोध करके इसमें रुचि दिखाई है, क्योंकि आईडी पहले स्थान पर लोड है। यदि हम एक बड़े, सक्रिय अनुप्रयोग के साथ इस तरह के उदाहरण को प्रक्षेपित करते हैं, तो हम लगभग किसी भी कार्य के लिए लगातार विवरण प्राप्त करने का अवसर देखेंगे - उपयोगकर्ता अंतिम डेटा डाउनलोड की प्रतीक्षा किए बिना वेब अनुप्रयोग के साथ बातचीत शुरू कर सकता है। और एक ही समय में प्रत्येक छींक के लिए डेटा का अनुरोध किए बिना बातचीत करना जारी रखें। बुरा नहीं है, है ना?



जिन लोगों ने मुझे इस तरह के चिप्स के सभी आकर्षण में विश्वास नहीं किया है, मैं कुछ और कारण बताऊंगा। सबसे पहले, इस तथ्य के बावजूद कि इस तरह की प्रणाली को किसी भी आरडीएफ को लागू किए बिना अच्छी तरह से लागू किया जा सकता है, आपको अभी भी इस तरह से कुछ का अनुकरण करने, या कई लगातार अनुरोध करने के लिए सर्वर की प्रतिक्रिया में स्क्रिप्ट का उपयोग करना होगा। दूसरे, RDF सिंटैक्स डेटाबेस से डेटा आउटपुट के समान है और आपको संदर्भ से जुड़ने की अनुमति नहीं देता है। व्यवहार में, यह ऐसी स्थिति को जन्म दे सकता है जहां पहले क्वेरी के परिणाम ब्राउज़र में पहले से ही संसाधित होंगे, जबकि डेटाबेस के लिए अंतिम क्वेरी अभी तक इसका निष्पादन पूरा नहीं किया है। क्या यह सुंदर नहीं है?





PS अगर मैं किसी चीज़ के बारे में गलत हूँ - मुझे सुधारो, मैं आभारी रहूँगा।

ZYY और मूल यहाँ निहित है