NDJSON को XML में बदलें

दोनों प्रारूप एक ही सवाल के दो सिरों पर बैठे हैं। NDJSON इस तरह बना है कि कोई पंक्ति किसी दूसरी पर निर्भर नहीं — इसे कहीं भी काटा जा सकता है। XML दस्तावेज़ बिलकुल उल्टा है — यह तब तक मान्य नहीं जब तक बंद root टैग न आ जाए।

यही गुण योजना बनाने लायक़ है, एलिमेंट के नाम नहीं। बड़े निर्यात का बदलाव एक ऐसा दस्तावेज़ देता है जिसे पूरा भेजना, पार्स करना और स्वीकार करना पड़ता है, और उसमें कहीं भी विफलता पूरे को विफल कर देती है।

आकार तय है क्योंकि इनपुट का आकार तय है। न्यूलाइन-अलग की गई फ़ाइल हमेशा एक सूची होती है, और सूची का अपना कोई नाम नहीं होता, इसलिए दस्तावेज़ एक root एलिमेंट है जिसमें हर रिकॉर्ड के लिए एक item एलिमेंट है।

बदलाव के दौरान इन दो नामों को बदलने का कोई विकल्प नहीं है। आउटपुट जान-बूझकर सबसे सादा सही दस्तावेज़ है, जो आगे होने वाले नाम-बदलाव को सोचा-समझा खोज-और-बदलाव बनाता है, उलझन नहीं।

लगभग हर XML इनटेक अपने रिकॉर्ड एलिमेंट का नाम अपने स्कीमा में तय रखता है। तो ये दो सामान्य नाम प्लेसहोल्डर हैं, और उन्हें बदलना किसी भी संपादक में दो-लाइन का काम है।

पहली डिलीवरी से पहले ही यह करना दो मिनट की क़ीमत चुकाने लायक़ है। स्कीमा के ख़िलाफ़ जाँचने वाला इनटेक एलिमेंट के नाम पर पूरा दस्तावेज़ अस्वीकार कर देगा।

XML में सूची हमेशा से एक टैग का कई बार लिखा जाना रहा है, तो तीन tags वाला रिकॉर्ड तीन tags एलिमेंट पंक्ति में देता है। न गिनती, न जोड़ना, न आपकी ओर से कोई फ़ैसला — ढाँचा पूरा बचा रहता है।

यही इस फ़ाइल के लिए तालिका वाले लक्ष्यों पर XML के पक्ष में सबसे मज़बूत दलील है। इन्हीं रिकॉर्ड को CSV में बदलना गिनी हुई कॉलम, जोड़ी हुई स्ट्रिंग या अतिरिक्त पंक्तियों के बीच चुनाव मजबूर करता है।

JSON की कुंजियाँ कुछ भी हो सकती हैं: ख़ाली जगह, स्लैश, शुरुआत में अंक। XML एलिमेंट के नाम ऐसा नहीं कर सकते। लेखक नाकाम होने की बजाय दोबारा लिखता है — XML जिन अक्षरों को मना करता है वे अंडरस्कोर बन जाते हैं।

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

तालिका वाले बदलाव जो मेल-मिलाप करते हैं, वह यहाँ नहीं होता। हर item एलिमेंट उतने ही फ़ील्ड लेता है जितने उसकी पंक्ति में थे, तो मिश्रित घटना वाली फ़ाइल एक ही दस्तावेज़ में कई आकार के item एलिमेंट देती है।

ऐसा स्कीमा जो एलिमेंट का तय क्रम बताता है, वह पहले ही रिकॉर्ड पर अस्वीकार करेगा जिसमें कोई एक छूट गया। जहाँ यह मामला हो, या तो स्रोत को एक तरह के रिकॉर्ड तक फ़िल्टर कीजिए या छूटे एलिमेंट को ख़ाली जोड़िए।

किसी मूल्य में एम्परसैंड, कोणीय कोष्ठक या दोहरे उद्धरण चिह्न एस्केप किए जाते हैं, जो दस्तावेज़ को समय से पहले ख़त्म होने से रोकता है। बाक़ी सब, संयुक्ताक्षर और ग़ैर-लैटिन पाठ समेत, UTF-8 में लिखा जाता है।

JSON का null एक ख़ाली एलिमेंट बनता है: टैग मौजूद रहता है, बीच में कुछ नहीं। कुछ स्कीमा उसकी जगह xsi:nil चाहते हैं। स्रोत के पास «कुछ नहीं» कहने का एक ही तरीक़ा है, इसलिए यह फ़र्क़ आउटपुट पर की गई स्क्रिप्टेड संपादना है।

हर फ़ील्ड का नाम रिकॉर्ड में दो बार आता है — खुलने और बंद होने वाले टैग में — जहाँ NDJSON उसे एक बार लिखता है। इंडेंटेशन जोड़कर लंबे फ़ील्ड नामों वाली छोटी क़ीमतों की फ़ाइल स्रोत से दो से तीन गुना बड़ी बैठती है।

SFTP ड्रॉप पर इससे कोई फ़र्क़ नहीं पड़ता। आकार-सीमित मैसेज क़तार पर यह तय करता है कि एक बैच में कितने रिकॉर्ड आएँगे। जवाब लगभग हमेशा संपीड़न है, ढाँचा बदलना नहीं।

बदलाव इसी ब्राउज़र टैब में चलता है: फ़ाइल को पंक्ति-दर-पंक्ति पढ़ा जाता है और दस्तावेज़ पन्ने के भीतर छोटे लेखक द्वारा लिखा जाता है। कुछ अपलोड नहीं होता, न कोई खाता है, न कोई क़तार, और मुफ़्त स्तर 100 MB तक स्वीकार करता है।

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