XML, समझाया गया: वह डेटा फ़ॉर्मैट जो सूट और टाई पहनता है

एक वाक्य में

XML कस्टम टैग का उपयोग करके डेटा को स्ट्रक्चर करने का एक बहुत ही सख़्त तरीका है, जो इसे आपके और आपके कंप्यूटर दोनों के लिए पठनीय बनाता है, लेकिन ज़्यादातर आपके कंप्यूटर के लिए।

यह क्या समस्या हल करता है

कंप्यूटिंग के शुरुआती दिनों में, अलग-अलग प्रोग्राम के बीच डेटा शेयर करना एक बड़ा सिरदर्द था। हर कंपनी का अपना ख़ुफ़िया फ़ाइल फ़ॉर्मैट होता था। WordPerfect के एक डॉक्यूमेंट को Microsoft Word में खोलने की कोशिश करना एक एडवेंचर जैसा था। इसे वेंडर लॉक-इन (vendor lock-in) कहा जाता था, और यह एक बहुत बड़ी गड़बड़ थी।

इंटरनेट के आने से यह समस्या दस गुना बदतर हो गई। अब, यह सिर्फ़ एक कंप्यूटर पर दो प्रोग्राम की बात नहीं थी; यह दुनिया भर में हज़ारों अलग-अलग सर्वर और क्लाइंट थे जिन्हें आपस में बात करने की ज़रूरत थी।

वेब के लिए इसे हल करने का पहला प्रयास HTML (HyperText Markup Language) था। HTML ब्राउज़र को यह बताने के लिए शानदार है कि जानकारी को कैसे दिखाना है: यह एक हेडिंग (<h1>) है, यह एक पैराग्राफ (<p>) है, यह बोल्ड (<b>) में है। लेकिन यह यह बताने में बहुत ख़राब है कि जानकारी क्या है। क्या वह बोल्ड टेक्स्ट किसी प्रोडक्ट का नाम है, कोई चेतावनी है, या बस कुछ ऐसा है जो आपको बोल्ड में अच्छा लगा? कंप्यूटर को इसका कोई अंदाज़ा नहीं होता।

फिर 90 के दशक के अंत में XML (eXtensible Markup Language) आया। यह SGML नामक एक पुराने, ज़्यादा अकादमिक स्टैण्डर्ड से आया था, लेकिन इसे वेब-स्केल उपयोग के लिए सरल बनाया गया था। "eXtensible" (विस्तारणीय) वाला हिस्सा ही इसका असली मक़सद है: HTML के टैग के फिक्स्ड सेट के विपरीत, XML आपको अपने ख़ुद के टैग बनाने की सुविधा देता है।

<p> के बजाय, आप <product_name>, <price>, <shipping_address>, या <top_secret_volcano_lair_coordinates> बना सकते हैं।

अचानक, आपके पास डेटा का आदान-प्रदान करने का एक ऐसा तरीका आ गया जिसका अपना अर्थ था। डेटा सेल्फ़-डिस्क्राइबिंग (self-describing) था। यह बिज़नेस-टू-बिज़नेस लेन-देन से लेकर एप्लिकेशन कॉन्फ़िगरेशन फ़ाइलों तक हर चीज़ के लिए क्रांतिकारी था। इसने एक यूनिवर्सल भाषा बनाई जिस पर कोई भी दो सिस्टम बात करने के लिए सहमत हो सकते थे, जब तक कि वे नियमों का पालन करते।

यह अंदर से कैसे काम करता है

XML सिर्फ़ एंगल ब्रैकेट का एक गुच्छा लगता है, लेकिन उस नुकीले से दिखने वाले फॉर्मेट के नीचे एक शक्तिशाली और तार्किक सिस्टम है। यह कुछ मुख्य कॉन्सेप्ट्स पर बना है।

मुख्य एनाटॉमी: टैग, एलीमेंट्स, और एट्रिब्यूट्स

XML की मूल इकाई एलिमेंट (element) है। एक एलिमेंट में एक स्टार्ट टैग, कंटेंट, और एक एंड टैग होता है।

<book>War and Peace</book>

• टैग (Tags): <book> स्टार्ट टैग है, और </book> एंड टैग है। एंड टैग में स्लैश / पर ध्यान दें। यह अनिवार्य है।
• कंटेंट (Content): War and Peace एलिमेंट का कंटेंट है। कंटेंट सरल टेक्स्ट हो सकता है, या यह... और ज़्यादा एलिमेंट्स हो सकते हैं! यही नेस्टिंग (nesting) XML को उसका स्ट्रक्चर देती है।

एलिमेंट्स में एट्रिब्यूट्स (attributes) भी हो सकते हैं, जो मेटाडेटा के छोटे टुकड़े होते हैं जो स्टार्ट टैग के अंदर रहते हैं।

<book language="en">
  <title>War and Peace</title>
  <author>Leo Tolstoy</author>
</book>

यहाँ, language="en" book एलिमेंट का एक एट्रिब्यूट है। यह एलिमेंट के बारे में अतिरिक्त जानकारी प्रदान करता है, बजाय इसके कि यह उसके प्राइमरी कंटेंट का हिस्सा हो। एट्रिब्यूट बनाम चाइल्ड एलिमेंट का उपयोग करने का विकल्प एक क्लासिक डेवलपर बहस है, लेकिन एक अच्छा नियम यह है: यदि यह कंटेंट का वर्णन करता है, तो यह एक एलिमेंट है; यदि यह कंटेनर का वर्णन करता है, तो यह एक एट्रिब्यूट है।

ट्री स्ट्रक्चर (DOM)

जब कोई कंप्यूटर एक XML फ़ाइल को पार्स (parse) करता है, तो वह टेक्स्ट की दीवार नहीं देखता है। वह एक ट्री (tree) देखता है। इस तार्किक स्ट्रक्चर को डॉक्यूमेंट ऑब्जेक्ट मॉडल (Document Object Model) या DOM कहा जाता है।

इसे एक फैमिली ट्री की तरह सोचें:

• सबसे ऊपर हमेशा एक ही रूट एलिमेंट (root element) होता है (हमारे उदाहरण में, <book>)। एक XML डॉक्यूमेंट में दो रूट नहीं हो सकते।
• हर दूसरा एलिमेंट ट्री में एक नोड (node) है।
• दूसरे एलिमेंट्स के अंदर के एलिमेंट्स चाइल्ड नोड्स (child nodes) होते हैं (<title> <book> का चाइल्ड है)।
• कंटेन करने वाला एलिमेंट पैरेंट नोड (parent node) होता है (<book> <title> और <author> का पैरेंट है)।
• एक ही लेवल के एलिमेंट्स सिबलिंग नोड्स (sibling nodes) होते हैं (<title> और <author> सिबलिंग्स हैं)।

अपने XML को एक ट्री के रूप में विज़ुअलाइज़ करना यह समझने की कुंजी है कि इसे कैसे नेविगेट और क्वेरी किया जाए। आप एक पार्सर से कह सकते हैं "बुक एलिमेंट के अंदर ऑथर एलिमेंट ढूंढो," और वह जानता है कि वहां पहुंचने के लिए ट्री पर कैसे चलना है।

नियम: वेल-फॉर्म्ड बनाम वैलिड

यहीं से XML को सख़्त होने की प्रतिष्ठा मिलती है। "सही" होने के दो लेवल हैं।

1. वेल-फॉर्म्ड (Well-Formed) XML: यह बिल्कुल न्यूनतम आवश्यकता है। यह सही व्याकरण होने जैसा है।

• एक, और सिर्फ़ एक, रूट एलिमेंट होना चाहिए।
• हर स्टार्ट टैग का एक मैचिंग एंड टैग होना चाहिए।
• टैग केस-सेंसिटिव होते हैं: <Book> और <book> एक जैसे नहीं हैं।
• एलिमेंट्स को सही ढंग से नेस्ट किया जाना चाहिए। <b><i>text</i></b> सही है; <b><i>text</b></i> एक आपदा है।
• एट्रिब्यूट वैल्यू कोट्स (" या ') में होनी चाहिए।

यदि कोई XML डॉक्यूमेंट वेल-फॉर्म्ड नहीं है, तो कोई भी पार्सर तुरंत एक एरर देगा और आगे बढ़ने से मना कर देगा। कोई अपवाद नहीं।

2. वैलिड (Valid) XML: यह अगला लेवल है। एक XML डॉक्यूमेंट "वैलिड" होता है यदि वह वेल-फॉर्म्ड हो और यह नियमों के एक पूर्व-परिभाषित सेट का पालन करता है जिसे स्कीमा (schema) कहा जाता है।

एक स्कीमा एक ब्लूप्रिंट या एक कॉन्ट्रैक्ट की तरह है। यह एक अलग फ़ाइल होती है (आमतौर पर एक .xsd या .dtd) जो इन चीज़ों को परिभाषित करती है:

• कौन से एलिमेंट्स की अनुमति है?
• उन्हें किस क्रम में दिखना चाहिए?
• कौन से एलिमेंट्स आवश्यक हैं और कौन से वैकल्पिक हैं?
• एक एलिमेंट में कौन से एट्रिब्यूट्स हो सकते हैं?
• क्या किसी एलिमेंट का कंटेंट एक संख्या, एक स्ट्रिंग, या एक तारीख होना चाहिए?

उदाहरण के लिए, हमारी किताब के उदाहरण के लिए एक स्कीमा यह कह सकता है: "हर <book> एलिमेंट में एक <title> और कम से कम एक <author> होना चाहिए। इसमें एक language एट्रिब्यूट हो सकता है। <price> एलिमेंट, यदि मौजूद है, तो उसमें एक पॉजिटिव संख्या होनी चाहिए।"

यह XML की सुपरपावर है। यह दो सिस्टम (जैसे, एक खरीदार और एक विक्रेता) को एक कठोर डेटा कॉन्ट्रैक्ट पर सहमत होने की अनुमति देता है। कॉन्ट्रैक्ट का उल्लंघन करने वाला कोई भी डेटा स्वचालित रूप से अस्वीकार कर दिया जाता है, जिससे अनगिनत बग और गलतफहमियां रुक जाती हैं।

असल दुनिया की कहानियाँ

वह बैंकिंग API जो फेल नहीं हो सकता था

एक बड़ा बैंक बड़े कॉर्पोरेट ग्राहकों के लिए पेमेंट निर्देशों को स्वचालित रूप से सबमिट करने के लिए एक सिस्टम बना रहा था। हम प्रति ट्रांजैक्शन लाखों डॉलर की बात कर रहे हैं। गलती की कोई गुंजाइश नहीं थी। एक गायब करेंसी सिंबल या एक ग़लत जगह पर लगा दशमलव विनाशकारी हो सकता था। टीम ने एक सख़्त XML स्कीमा डेफ़िनिशन (XSD) के साथ XML को चुना। इससे पहले कि कोर बैंकिंग सिस्टम किसी पेमेंट निर्देश को देखता, उसे स्कीमा के ख़िलाफ़ वैलिडेट किया जाता था। यदि कोई क्लाइंट <amount>100000.00</amount> के बजाय <amount>100,000</amount> भेजता, या <currency>USD</currency> के बजाय <currency>usd</currency> भेजता, तो API उसे तुरंत स्कीमा उल्लंघन की ओर इशारा करते हुए एक स्पष्ट एरर के साथ रिजेक्ट कर देता। सबक: मिशन-क्रिटिकल डेटा एक्सचेंज के लिए जहाँ अस्पष्टता बहुत महंगी पड़ सकती है, एक वैलिडेटेड XML डॉक्यूमेंट की सख़्ती एक फ़ीचर है, बग नहीं।

वह वेक्टर ग्राफ़िक जो सिर्फ़ टेक्स्ट था

एक वेब डेवलपर को एक नई साइट के लिए एक कॉम्प्लेक्स लोगो की ज़रूरत थी। एक डिज़ाइनर ने उन्हें एक .svg फ़ाइल भेजी। डेवलपर ने उत्सुकतावश, फ़ाइल को एक टेक्स्ट एडिटर में खोला और यह देखकर हैरान रह गया कि यह पिक्सेल का बाइनरी ढेर नहीं था। यह XML था! <svg>, <path>, और <circle> जैसे टैग शेप, रंग और कोऑर्डिनेट्स का वर्णन कर रहे थे। उन्होंने महसूस किया कि वे ग्राफ़िक्स प्रोग्राम खोले बिना, सिर्फ़ XML में एट्रिब्यूट वैल्यू को ढूंढकर और बदलकर लोगो के रंगों को प्रोग्रामेटिक रूप से बदल सकते हैं। उन्होंने जावास्क्रिप्ट के साथ XML नोड्स में हेरफेर करके इसे एनिमेट भी किया। सबक: आपके द्वारा प्रतिदिन उपयोग किए जाने वाले कई शक्तिशाली फ़ाइल फ़ॉर्मैट, जैसे SVG (स्केलेबल वेक्टर ग्राफ़िक्स), वास्तव में XML की विशिष्ट बोलियाँ हैं, जो उन्हें जांचने, एडिट करने और स्क्रिप्ट करने योग्य बनाती हैं।

वह प्राचीन कॉन्फ़िगरेशन का दैत्य

एक जूनियर डेवलपर को 15 साल पुराने एंटरप्राइज़ जावा एप्लिकेशन पर एक बग को ठीक करने का काम सौंपा गया था। समस्या का स्रोत कहीं कॉन्फ़िगरेशन में था। उनके डर का ठिकाना नहीं रहा जब उन्होंने देखा कि कॉन्फ़िग एक साधारण टेक्स्ट फ़ाइल नहीं थी; यह config.xml नामक एक 25,000-लाइन की XML फ़ाइल थी। यह एक उलझा हुआ, बिना इंडेंट वाला गड़बड़झाला था। इसे पढ़ना असंभव था। लेकिन फिर उन्होंने इसे एक XML व्यूअर में लोड किया। तुरंत, टूल ने इसे फ़ॉर्मैट किया, कलर हाइलाइटिंग जोड़ी, और उन्हें ट्री के बड़े सेक्शन को कोलैप्स करने दिया। वे संबंधित सेक्शन (<databaseConnectionPool>) को खोज सकते थे, संबंधित सेटिंग्स की पूरी ब्रांच देख सकते थे, और तुरंत सर्वर के नाम में एक टाइपो को पकड़ सकते थे। सबक: XML बहुत ज़्यादा वर्बोस हो सकता है, लेकिन इसका स्वाभाविक ट्री स्ट्रक्चर, जब सही टूल के साथ देखा जाता है, तो सबसे ज़्यादा कॉम्प्लेक्स फ़ाइलों को भी मैनेजेबल बना देता है।

आम गलतियाँ और जाल

• इसे HTML के साथ कन्फ्यूज करना। वे चचेरे भाइयों की तरह दिखते हैं, लेकिन उनके काम अलग-अलग हैं। HTML प्रेजेंटेशन के लिए है (चीज़ें कैसी दिखती हैं)। XML डेटा डिस्क्रिप्शन के लिए है (चीज़ें क्या हैं)। आपका ब्राउज़र ख़राब HTML को माफ़ कर देगा; एक XML पार्सर ख़राब XML को माफ़ नहीं करेगा।
• एट्रिब्यूट्स बनाम एलिमेंट्स की चिंता। नए लोग अक्सर इस बात पर अटक जाते हैं कि डेटा का एक टुकड़ा एक एट्रिब्यूट (<book isbn="123">) होना चाहिए या एक चाइल्ड एलिमेंट (<book><isbn>123</isbn></book>)। इसका कोई एक सही जवाब नहीं है, लेकिन एक आम दिशानिर्देश यह है कि एलिमेंट्स कंटेंट रखते हैं, जबकि एट्रिब्यूट्स उस कंटेंट के बारे में मेटाडेटा रखते हैं। इस पर बहुत ज़्यादा चिंता न करें, लेकिन कंसिस्टेंट रहें।
• इसे रेगुलर एक्सप्रेशन से पार्स करने की कोशिश करना। मत करो। बस मत करो। यह सरल मामलों के लिए आकर्षक लग सकता है, लेकिन क्योंकि XML एक नेस्टेड, रिकर्सिव स्ट्रक्चर है, एक साधारण Regex किसी भी नॉन-ट्रिविअल फ़ाइल पर बुरी तरह से फेल हो जाएगा। यह एक क्लासिक प्रोग्रामिंग हॉरर स्टोरी है। हमेशा अपनी पसंद की भाषा के लिए एक उचित XML पार्सर लाइब्रेरी का उपयोग करें।
• यह भूल जाना कि यह केस-सेंसिटिव है। यदि आपकी स्कीमा <name> की अपेक्षा करती है, तो <Name> भेजने से वैलिडेशन एरर आएगा। यह कम सख़्त फ़ॉर्मैट से आने वाले डेवलपर्स को फंसा देता है।
• नेमस्पेस को अनदेखा करना। बड़े XML डॉक्यूमेंट में जो अलग-अलग वोकैबुलरी को मिलाते हैं (जैसे, SVG और XSLT को मिलाना), आप <xsl:template> या <svg:path> जैसे टैग देखेंगे। वह xsl: वाला हिस्सा एक नेमस्पेस है, जो टकराव को रोकता है यदि दोनों वोकैबुलरी में <template> नामक टैग होता। वे एक सिरदर्द हो सकते हैं, लेकिन वे कॉम्प्लेक्स डॉक्यूमेंट के लिए आवश्यक हैं।

यह आपके रडार पर क्यों होना चाहिए

हो सकता है कि आप किसी नए प्रोजेक्ट की शुरुआत एक सिंपल API के लिए XML के साथ न करें (वहाँ JSON आमतौर पर संक्षिप्तता के लिए जीत जाता है)। लेकिन आपको XML का सामना करना ही पड़ेगा, यह गारंटी है। आपको XML के बारे में सोचना चाहिए जब:

• आप पुराने, एंटरप्राइज़ सिस्टम के साथ इंटीग्रेट कर रहे हों, विशेष रूप से वे जो SOAP या WSDL का उपयोग करते हैं।
• आपको दो पार्टियों के बीच एक मज़बूत, अटूट डेटा कॉन्ट्रैक्ट (XSD का उपयोग करके) को परिभाषित करने की आवश्यकता है।
• आप डॉक्यूमेंट-सेंट्रिक डेटा के साथ काम कर रहे हैं, जैसे RSS/Atom फ़ीड, Office डॉक्यूमेंट (OOXML), या वेक्टर ग्राफ़िक्स (SVG)।
• आप जावा इकोसिस्टम (जैसे Maven या Ant) या .NET में टूल कॉन्फ़िगर कर रहे हैं।
• आपको .xml, .svg, .rss, .atom, या .plist में समाप्त होने वाली कोई फ़ाइल मिलती है और आपको सिर्फ़ उसके कंटेंट को ही नहीं, बल्कि उसके स्ट्रक्चर को भी समझने की आवश्यकता है।

XML की बुनियादी बातें जानना वैसा ही है जैसे यह जानना कि एक कार्बोरेटर कैसे काम करता है। हो सकता है आप एक आधुनिक फ्यूल-इंजेक्टेड कार चलाते हों, लेकिन वह ज्ञान आपको इंजनों की गहरी समझ देता है और जब आप किसी क्लासिक कार का सामना करते हैं तो आपको एक बेहतर मैकेनिक बनाता है।

और गहराई से जानें

• W3C: एक्सटेंसिबल मार्कअप लैंग्वेज (XML) - मानकों का आधिकारिक घर।
• विकिपीडिया: XML - एक व्यापक और पठनीय इतिहास और अवलोकन।
• MDN वेब डॉक्स: XML का परिचय - एक वेब डेवलपर के दृष्टिकोण से एक बढ़िया प्राइमर।
• XML स्कीमा भाग 0: प्राइमर (W3C सिफ़ारिश) - स्कीमा के लिए आधिकारिक गाइड, जब आपको नियमों को लागू करने की आवश्यकता हो।
• एक्सटेंसिबल मार्कअप लैंग्वेज (XML) 1.0 (पांचवां संस्करण) - वास्तविक स्पेसिफिकेशन। घना, लेकिन सत्य का अंतिम स्रोत।