XML का लगभग हमेशा दुरुपयोग होता है

XML भाषा का आविष्कार 1996 में हुआ था। जैसे ही यह सामने आया, इसके अनुप्रयोग की संभावनाओं को पहले से ही गलत समझा जाने लगा, और जिन उद्देश्यों के लिए वे इसे अनुकूलित करने का प्रयास कर रहे थे, यह सबसे अच्छा विकल्प नहीं था।

यह कहना कोई अतिशयोक्ति नहीं होगी कि मैंने जो XML स्कीमा देखी हैं उनमें से अधिकांश XML के अनुचित या गलत उपयोग थे। इसके अलावा, XML के इस उपयोग ने XML के बारे में एक बुनियादी गलतफहमी को प्रदर्शित किया।

XML एक मार्कअप भाषा है. यह कोई डेटा प्रारूप नहीं है. अधिकांश XML स्कीमा ने स्पष्ट रूप से इस अंतर को नजरअंदाज कर दिया है, XML को डेटा प्रारूप के साथ भ्रमित कर दिया है, जिसके परिणामस्वरूप अंततः XML चुनने में गलती होती है क्योंकि यह डेटा प्रारूप है जिसकी वास्तव में आवश्यकता होती है।

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

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

नीचे मैं गलत तरीके से निर्मित सर्किट के कुछ सबसे सामान्य उदाहरण दूंगा।

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

यहां हम XML में एक सरल कुंजी-मूल्य शब्दकोश को व्यक्त करने के एक निराधार और अजीब (हालांकि बहुत सामान्य) प्रयास का एक उदाहरण देखते हैं। यदि आप सभी टैग और विशेषताएँ हटा देते हैं, तो आपके पास एक खाली पंक्ति रह जाएगी। मूलतः, यह दस्तावेज़, चाहे यह कितना भी बेतुका क्यों न लगे, एक खाली पंक्ति का अर्थपूर्ण एनोटेशन है।

<root name="John" city="London" />

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

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

यह कुछ बेहतर है, लेकिन अब किसी कारण से कुंजियाँ मेटाडेटा हैं और मान नहीं हैं। शब्दकोशों पर एक बहुत ही अजीब नज़र। यदि आप सभी टैग और विशेषताएँ हटा देते हैं, तो आधी जानकारी नष्ट हो जाएगी।

XML में एक सही शब्दकोश अभिव्यक्ति कुछ इस तरह दिखाई देगी:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

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

सबसे ख़राब XML स्कीमा? वैसे, के लिए पुरस्कार सबसे खराब XML स्कीमा जो मैंने कभी देखी है, पॉलीकॉम आईपी टेलीफोनी फोन के लिए स्वचालित प्रावधान कॉन्फ़िगरेशन फ़ाइल प्रारूप प्राप्त करता है। ऐसी फ़ाइलों के लिए TFTP के माध्यम से XML अनुरोध फ़ाइलों को डाउनलोड करने की आवश्यकता होती है, जो... सामान्य तौर पर, यहां ऐसी ही एक फ़ाइल का एक अंश दिया गया है:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

ये किसी का घटिया मजाक नहीं है. और यह मेरा आविष्कार नहीं है:

• तत्वों को केवल विशेषताओं को संलग्न करने के लिए उपसर्ग के रूप में उपयोग किया जाता है, जिनके स्वयं पदानुक्रमित नाम होते हैं।
• यदि आप किसी विशेष प्रकार के रिकॉर्ड के एकाधिक उदाहरणों को मान निर्दिष्ट करना चाहते हैं, तो आपको ऐसा करने के लिए विशेषता नामों का उपयोग करना होगा। जिसमें अनुक्रमणिकाएं हैं.
• इसके अलावा, विशेषताएँ शुरू होती हैं softkey., तत्वों पर रखा जाना चाहिए <softkey/>, से शुरू होने वाली विशेषताएँ feature., तत्वों पर रखा जाना चाहिए <feature/> आदि, इस तथ्य के बावजूद कि यह पूरी तरह से अनावश्यक और पहली नज़र में अर्थहीन लगता है।
• और अंत में, यदि आप उम्मीद कर रहे थे कि किसी विशेषता नाम का पहला घटक हमेशा तत्व नाम के समान होगा - तो ऐसा कुछ नहीं है! उदाहरण के लिए, गुण up. से संलग्न होना चाहिए <userpreferences/>. तत्वों में विशेषता नाम जोड़ने का क्रम मनमाना है, लगभग पूरी तरह से।

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

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

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

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

दूसरे शब्दों में, एक शब्दकोश (संरचित डेटा का एक टुकड़ा) में परिवर्तित किया जा सकता है n विभिन्न संभावित दस्तावेज़ (एक्सएमएल, पीडीएफ, पेपर इत्यादि में), जहां n - शब्दकोश में तत्वों के संभावित संयोजनों की संख्या, और हमने अभी तक अन्य संभावित चरों को ध्यान में नहीं रखा है।

हालाँकि, इससे यह भी पता चलता है कि यदि आप केवल डेटा ट्रांसफर करना चाहते हैं, तो इसके लिए मशीन-पठनीय दस्तावेज़ का उपयोग करना प्रभावी नहीं होगा। यह एक मॉडल का उपयोग करता है, जो इस मामले में अनावश्यक है; यह केवल रास्ते में आएगा। इसके अलावा, स्रोत डेटा निकालने के लिए, आपको एक प्रोग्राम लिखना होगा। किसी ऐसी चीज़ के लिए XML का उपयोग करने का शायद ही कोई मतलब है जिसे किसी बिंदु पर दस्तावेज़ के रूप में स्वरूपित नहीं किया जाएगा (जैसे, CSS या XSLT, या दोनों का उपयोग करना), क्योंकि ऐसा करने का यही मुख्य (यदि एकमात्र नहीं) कारण है। दस्तावेज़ मॉडल के लिए.

इसके अलावा, चूंकि XML में संख्याओं (या बूलियन अभिव्यक्ति, या अन्य डेटा प्रकार) की कोई अवधारणा नहीं है, इसलिए इस प्रारूप में दर्शाए गए सभी नंबरों को केवल अतिरिक्त पाठ माना जाता है। डेटा निकालने के लिए, स्कीमा और व्यक्त किए जा रहे संबंधित डेटा से उसका संबंध ज्ञात होना चाहिए। आपको यह भी जानना होगा कि संदर्भ के आधार पर, एक विशेष पाठ तत्व एक संख्या का प्रतिनिधित्व करता है और उसे एक संख्या में परिवर्तित किया जाना चाहिए, आदि।

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

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

आज तक, एकमात्र एक्सएमएल स्कीमा जिसके बारे में मैं जानता हूं, जिसे मैं वास्तव में प्रारूप का वैध उपयोग कह सकता हूं, वे हैं एक्सएचटीएमएल और डॉकबुक।

स्रोत: www.habr.com