XML, JSON से लगभग एक दशक पहले आया था और 2000 के दशक में वेब सेवाओं (SOAP, RSS, अधिकांश उद्यम एकीकरण) के लिए डिफ़ॉल्ट विकल्प था। JSON ने इसे क्षमता में प्रतिस्पर्धा नहीं की, XML JSON जो कुछ भी कर सकता है और अधिक प्रस्तुत कर सकता है; यह सर्वर और क्लाइंट के बीच डेटा ले जाने के विशिष्ट कार्य के लिए वजन और प्रत्यक्षता में जीता।
वही डेटा, दो तरीके
<user>
<name>Ada Lovelace</name>
<age>36</age>
<active>true</active>
<skills>
<skill>mathematics</skill>
<skill>writing</skill>
</skills>
</user>{
"user": {
"name": "Ada Lovelace",
"age": 36,
"active": true,
"skills": ["mathematics", "writing"]
}
}XML संस्करण को हर ओपनिंग टैग के लिए एक क्लोजिंग टैग की आवश्यकता होती है, और एक सूची का प्रतिनिधित्व करने के लिए एक दोहराया गया <skill> एलीमेंट, क्योंकि XML में नेटिव एरे वाक्यविन्यास नहीं है; कई <skill> चाइल्ड्स वाला एक <skills> एलीमेंट उतना ही आसानी से एक <skill> चाइल्ड हो सकता है, और केवल एक स्कीमा या परंपरा पाठक को बताती है कि कौन सा है। JSON के [ ] दो वर्णों में अस्पष्ट रूप से “सूची” कहते हैं।
जहाँ XML अभी भी जीतता है
सामग्री के साथ एट्रिब्यूट्स। <price currency="USD">42.00</price> एक रैपर ऑब्जेक्ट बनाए बिना एक मान से मेटाडेटा जोड़ता है। JSON में कोई एट्रिब्यूट अवधारणा नहीं है; वही डेटा {"price": {"value": 42.00, "currency": "USD"}} या @currency कुंजी जैसी परंपरा बन जाता है, दोनों इस आकार के लिए XML की नेटिव वाक्यविन्यास से कम प्रत्यक्ष हैं।
मिश्रित सामग्री। इनलाइन मार्कअप के साथ पाठ का एक पैराग्राफ, <p>Some <b>bold</b> text</p>, XML की नेटिव शक्ति है, इसलिए दस्तावेज़ प्रारूप (DocBook, अधिकांश प्रकाशन पाइपलाइनें, SVG) अभी भी इसका उपयोग करते हैं। JSON में पाठ और मार्कअप को एक साथ जोड़ने का कोई तरीका नहीं है; JSON में एक समृद्ध दस्तावेज़ का प्रतिनिधित्व करने का मतलब आमतौर पर टाइप किए गए नोड्स का एक पेड़ है, जो XML के मार्कअप से जो पहले से मुफ्त में दिया जाता है उससे लिखने और पढ़ने के लिए अधिक कोड है।
नेमस्पेस और सख्त स्कीमा। XML Schema (XSD) और नेमस्पेस एक बड़े संगठन को एक दस्तावेज़ में विभिन्न स्रोतों से शब्दावलियों को बिना नाम टकराव के मिलाने देते हैं, बीस से अधिक वर्षों से मौजूद टूलिंग के साथ। JSON Schema मौजूद है और वास्तविक काम करता है (JSON Schema Generator एक वास्तविक दस्तावेज़ से एक को अनुमानित करता है), लेकिन यह बड़े उद्यम सिस्टम में XSD से कम युवा और सार्वभौमिक रूप से तैनात है।
जहाँ JSON जीतता है, जो अधिकांश API है
वजन। कोई क्लोजिंग टैग नहीं होने का मतलब उन्हीं डेटा के लिए कम ट्रांसमिट करना और कम पार्स करना है, अक्सर गहराई से नेस्टेड दस्तावेज़ों में एक बड़े मार्जिन से।
प्रोग्राम के अपने डेटा संरचनाओं का प्रत्यक्ष मैपिंग। JavaScript में JSON.parse, या लगभग हर अन्य भाषा में एक समकक्ष वन-लाइनर, एक JSON दस्तावेज़ को उस भाषा के नेटिव ऑब्जेक्ट और एरे प्रकारों में बदल देता है बिना किसी इंटरमीडिएट मॉडल के। XML को एक DOM, या एक स्कीमा-जनित क्लास की आवश्यकता होती है, जो पाठ और उस डेटा के बीच बैठता है जिसे एक प्रोग्राम वास्तव में उपयोग करता है।
कोई निहित टाइपिंग प्रश्न नहीं। हर XML मान टेक्स्ट है जब तक कि कुछ बाहरी (एक स्कीमा, एक परंपरा) इसके विपरीत न कहे; <age>36</age> “36” युक्त एक स्ट्रिंग है जब तक कि इसे संख्या होने के लिए नहीं कहा जाता। JSON के number, boolean, और null प्रकार स्वयं वाक्यविन्यास में स्पष्ट हैं, इसलिए कॉन्फ़िगर करने या अनुमान लगाने के लिए कुछ भी नहीं है।
व्यवहार में
नई REST API आज बिना किसी अपवाद के लगभग JSON को डिफ़ॉल्ट करती हैं। XML तब बना रहता है जहाँ इसकी अपनी ताकतें महत्वपूर्ण हैं: पुराने उद्यम सिस्टम में SOAP सेवाएँ, RSS और Atom फ़ीड, SVG और अन्य मार्कअप-नेटिव प्रारूप, और जहाँ एट्रिब्यूट्स या मिश्रित सामग्री डेटा की वास्तविक आकृति हैं न कि एक अजीब फिट।
उनके बीच रूपांतरण
JSON to XML Converter दोनों दिशाओं में चलता है, नेमस्पेस प्रीफिक्स और इस बात के नियंत्रण के साथ कि दिया गया मान XML एट्रिब्यूट या चाइल्ड एलीमेंट में बदलता है या नहीं, क्योंकि उस विकल्प का कोई एक सही उत्तर नहीं है और यह इस बात पर निर्भर करता है कि आउटपुट क्या उपभोग कर रहा है। यह XML पढ़ने के लिए ब्राउज़र के अपने DOMParser का उपयोग करता है न कि एक हाथ से बने पार्सर का, और हर मान अंदर आने पर एक स्ट्रिंग के रूप में वापस आता है, जिसे उपकरण बताता है न कि XML स्वयं जो प्रकार नहीं ले जाता उनका चुपचाप अनुमान लगाता है।