YAML के पक्ष में

(opensource.posit.co)

1 पॉइंट द्वारा GN⁺ 21 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें

YAML 1.2 मनुष्यों द्वारा सीधे लिखी जाने वाली nested configuration files के लिए indentation-आधारित serialization format है, और पुराने PyYAML अनुभवों से पैदा हुई अस्थिरता संबंधी आलोचनाओं से इसे अलग करके देखना ज़रूरी है
configuration file formats समय के साथ INI की सपाटता, XML की लंबाई-चौड़ाई, और JSON में comments व multi-line strings की कमी जैसी पुरानी पीढ़ी की सीमाओं को सुधारते हुए विकसित हुए हैं
TOML pyproject.toml और Cargo.toml जैसे उथले ढाँचों में स्पष्ट है, लेकिन गहरे nested structures में path repetition और array tables के कारण पढ़ना व संपादित करना अधिक बोझिल हो जाता है
YAML 1.2 Core Schema yes, no, on, off, y, n को strings की तरह मानता है और sexagesimal numbers व core type के रूप में timestamps को हटाकर पुराने implicit type inference की समस्याएँ कम करता है
py-yaml12 Python के लिए YAML 1.2 parser और formatter है, जो Rust implementation के जरिए सुरक्षित defaults, yaml-test-suite के साथ 100% compliance, और PyYAML C extension के मुकाबले की performance देता है

समस्या की पृष्ठभूमि

पिछले कुछ वर्षों में configuration file formats को लेकर माहौल इस तरफ गया है कि YAML बुरा है और TOML अच्छा, लेकिन YAML का मूल्यांकन इतिहास, spec में हुए बदलाव, और 2026 के tooling state को साथ देखकर ही किया जाना चाहिए
YAML की आलोचना लंबे समय तक वाजिब रही है और सावधान users ने भी अप्रत्याशित behavior झेला है, लेकिन spec बदल चुकी है और tooling ecosystem भी धीरे-धीरे उसके साथ आ रहा है
आज की YAML आलोचना को समझने के लिए configuration file formats की वंशावली को साथ देखना ज़रूरी है, क्योंकि यह बहस बार-बार दोहराई गई है कि अगला format पिछले format की अति को कैसे सुधारता है

configuration file formats का संक्षिप्त इतिहास

INI files 1980 के शुरुआती दशक में MS-DOS और शुरुआती Windows के साथ आईं, और key-value pairs, square-bracket sections, तथा semicolon comments वाले सपाट, पढ़ने में आसान, human-editable format थीं
INI उस समय device driver configuration, font paths, और application settings जैसी ज़रूरतों के लिए पर्याप्त था, लेकिन इसमें एक स्तर से अधिक nesting नहीं हो सकती थी और कोई औपचारिक spec न होने के कारण अलग-अलग parsers अपनी-अपनी dialects लागू करते थे
XML 1990 के दशक के अंत में enterprise software दुनिया में व्यापक रूप से अपनाया गया, और arbitrary hierarchy, schema, namespaces, transformations, तथा self-describing structure देता था, लेकिन वास्तविक configuration files बेहद verbose हो जाती थीं और हाथ से maintain करना मुश्किल था
JSON XML के हल्के विकल्प के रूप में आया और JavaScript object literal की सादगी के आधार पर 2000 के दशक के अंत और 2010 के दशक की शुरुआत में web APIs में XML की जगह लेने लगा, लेकिन configuration files के लिए इसमें comments की कमी, multi-line strings का अभाव, और trailing commas पर रोक जैसी सीमाएँ थीं
YAML 2001 में और TOML 2013 में JSON द्वारा छोड़ी गई जगह भरने के लिए आए; YAML ने indentation-आधारित syntax के साथ arbitrary nesting, multi-document support, references, और custom types दिए, जबकि TOML ने explicit types और औपचारिक spec के साथ “standardized INI” बनने की दिशा ली
हर पीढ़ी का नया format पिछले format की अतियों के जवाब में पैदा हुआ, और आज YAML से जुड़ी बहुत-सी समस्याएँ format design से ज़्यादा किसी खास spec version और उस version से बंधे parsers का परिणाम हैं

YAML के खिलाफ रहे तर्क

YAML की आलोचना बनावटी नहीं थी, बल्कि कई वर्षों तक programmers के वास्तविक अनुभवों पर आधारित थी
सबसे मशहूर Norway problem में YAML 1.1 unquoted scalar NO को boolean false की तरह पढ़ता था, जिससे country code list में no false value में बदल जाता था
```
countries:
  - dk
  - fi
  - is
  - no
  - se
```
```
["dk", "fi", "is", false, "se"]
```
यही नियम yes, on, off, y, n और कई uppercase-lowercase variants पर भी लागू होता था; 22:22 जैसे port mappings sexagesimal integer बन जाते थे, 10.23 जैसे version numbers strings के बजाय floating-point माने जाते थे, और date जैसे दिखने वाले values timestamps की तरह parse हो जाते थे
data science और machine learning code में स्वाभाविक variable names जैसे n और y भी YAML 1.1 के implicit boolean rules के तहत string keys नहीं बल्कि False और True keys की तरह interpret हो सकते थे
```
{"variables": {"x": "features", False: "sample_size", True: "target"}}
```
YAML 1.1 का आक्रामक implicit type inference unquoted true को boolean की तरह पढ़ने जैसी readability देने के लिए था, लेकिन वास्तविक configuration files में इसने unpredictability बढ़ा दी
configuration files अक्सर बार-बार edit नहीं की जातीं और कई बार मूल लेखक के अलावा कोई और उन्हें बदलता है, इसलिए चुपचाप हुई गलत parsing महीनों तक पूरे system में फैल सकती है; यह ऐसा क्षेत्र है जहाँ अप्रत्याशित behavior सबसे कम स्वीकार्य होता है
पूरे YAML spec की complexity भी एक बोझ थी, और YAML 1.2.2 spec 10 chapters तथा चार-स्तरीय numbering वाली sections के साथ एक बड़ा दस्तावेज़ है
multi-line strings लिखने के कई तरीके हैं, और anchors व aliases शक्तिशाली reference system बनाते हैं, लेकिन ज़्यादातर configuration कामों के लिए यह ज़रूरत से अधिक conceptual weight जोड़ते हैं
tag-based object deserialization की security समस्याएँ, खासकर Python की yaml.load() vulnerability, एक जाने-पहचाने attack vector बन गईं; इसलिए यह आलोचना YAML 1.1 और उसके आसपास के tooling ecosystem के लिए सही थी

TOML क्या अच्छा करता है

TOML सपाट या उथले configuration structures में साफ, पढ़ने में आसान और unambiguous format है
TOML syntax उन लोगों को परिचित लगती है जिन्होंने INI files देखी हैं, लेकिन इसमें explicit types, औपचारिक spec, और dot-separated keys के ज़रिए nested tables का support भी जुड़ता है
pyproject.toml और Cargo.toml में आमतौर पर एक या दो स्तर गहरे, अच्छी तरह परिभाषित sections और predictable contents होते हैं, इसलिए वे TOML के लिए उपयुक्त उदाहरण हैं
TOML में strings हमेशा quotes में रहती हैं, इसलिए no boolean है या शब्द, यह अस्पष्ट नहीं रहता; integers, floating-point values, और dates first-class types हैं, और comments भी अपेक्षित तरीके से काम करते हैं
Python packaging ecosystem में PEP 518 को अपनाना और Rust community में Cargo का उपयोग इस बात का प्रमाण है कि ऐसी problem scope के लिए TOML उपयुक्त विकल्प है
TOML spec इतनी छोटी है कि कोई सक्षम programmer सप्ताहांत में compatible parser लिख सकता है; इसका नतीजा यह है कि parser ecosystem बड़ा, अच्छी तरह tested, और अपेक्षाकृत consistent है
TOML में YAML 1.1 और 1.2 जैसी version split समस्या नहीं है; TOML 1.0 हर जगह TOML 1.0 ही है

जहाँ TOML भारी पड़ने लगता है

जब configuration file को गहराई व्यक्त करनी होती है, तब TOML की nested structure dot-separated section headers ([servers.alpha]) या arrays of tables ([[products]]) पर निर्भर करती है, और nesting बढ़ने के साथ इसे पढ़ना कठिन होता जाता है
PyTOML के Martin Vejnár ने अपनी library को pip dependency बनने देने से इनकार करते हुए यह अनुभव बताया कि configuration schema जटिल होने पर TOML syntax बदसूरत और पढ़ने में कठिन लगने लगती है

YAML में indentation hierarchy को एक नज़र में दिखा देती है, जबकि TOML में हर section header में पूरा path बार-बार लिखना पड़ता है

services:
  web:
    image: nginx:latest
    environment:
      DB_HOST: postgres
      DB_PORT: 5432
    resources:
      limits:
        memory: 512M
        cpu: "0.5"

[services.web]
image = "nginx:latest"

[services.web.environment]
DB_HOST = "postgres"
DB_PORT = 5432

[services.web.resources.limits]
memory = "512M"
cpu = "0.5"

TOML reader को सपाट qualified names की श्रृंखला से tree structure को दिमाग में फिर से बनाना पड़ता है, और StrictYAML documentation के माप के अनुसार वही data व्यक्त करने पर TOML file path prefixes की पुनरावृत्ति के कारण लगभग 50% अधिक characters इस्तेमाल करती है
Python ने बहुत पहले दिखा दिया था कि indentation को structure की तरह इस्तेमाल करना कमजोरी नहीं बल्कि ताकत है, क्योंकि इससे visual structure और syntax structure के बीच mismatch से पैदा होने वाले bugs खत्म होते हैं
YAML इसी indentation-आधारित structure के फायदे को अपनाता है, लेकिन TOML indentation नहीं मांगता, इसलिए key और उसके भीतर की table का संबंध file की physical layout में नहीं बल्कि सिर्फ section headers में मौजूद होता है
गहराई से nested configuration files में TOML को scan करना कठिन और आत्मविश्वास के साथ edit करना मुश्किल हो जाता है

YAML 1.2 में क्या बदला

YAML 1.2 spec 2009 में प्रकाशित हुई थी, और इसका clarification revision 1.2.2 अक्टूबर 2021 में पूरा हुआ
YAML 1.2 Core Schema में केवल true, false और True, False, TRUE, FALSE को boolean माना जाता है; yes, no, on, off, y, n सामान्य strings हैं
22:22 समस्या पैदा करने वाले sexagesimal numeric literals पूरी तरह हटा दिए गए, और timestamps अब core type नहीं हैं; इसलिए Core Schema में unquoted 2026-05-05 auto-detected date नहीं बल्कि string है
JSON अब YAML 1.2 का एक strict और valid subset है, इसलिए हर valid JSON document उसी तरह YAML के रूप में भी parse होता है
tag resolution rules अधिक सख्त और स्पष्ट हो गए हैं, और spec खुद भी अब ज़्यादा स्पष्ट रूप से लिखी गई है तथा GitHub पर खुले तौर पर maintain होती है
लोग जिस YAML की आलोचना करते रहे हैं वह YAML 1.1 है; आज का प्रमुख spec अधिक सुरक्षित और predictable YAML 1.2 है
समस्या यह है कि users का YAML अनुभव spec से नहीं बल्कि parser के ज़रिए आता है, और अधिकतर Python users के लिए वह parser PyYAML है, जो YAML 1.1 लागू करता है और 2006 के बाद से अपने core semantics में बदलाव नहीं लाया है

Python YAML parsers का परिदृश्य

PyYAML Python की de facto standard YAML library है, जो performance के लिए C library LibYAML को wrap करती है और pure Python fallback path भी देती है
PyYAML हर हफ्ते लाखों बार डाउनलोड होती है और अनगिनत packages की dependency है, लेकिन यह YAML 1.1 लागू करती है; इसी वजह से Python ecosystem में “YAML ने country code को boolean की तरह parse कर दिया” वाला अनुभव पैदा हुआ
PyYAML repository में 200 से अधिक खुले issues और 100 से अधिक खुले pull requests हैं; project maintained तो है, लेकिन धीरे चलता है, और YAML 1.2 semantics की ओर major-version transition अभी तक नहीं हुआ है
ruamel.yaml YAML 1.2 support के साथ comments, flow style, और key order को preserve करने वाली round-trip editing देता है, इसलिए comment preservation या formatting-aware editing के लिए यह PyYAML से कहीं अधिक शक्तिशाली विकल्प है
ruamel.yaml अपने default round-trip mode में मुख्यतः pure Python implementation है, इसलिए यह PyYAML के C-based fast path से काफी धीमा है, और namespace package समस्याओं तथा dependency chain के कारण इसकी packaging history ने deployment pipelines को उलझाया भी है
StrictYAML YAML का एक जानबूझकर सीमित subset लागू करता है, जो सभी implicit type inference, tags, anchors, और flow style को हटा देता है
StrictYAML दार्शनिक रूप से पूरे YAML से अधिक TOML के करीब है; यह YAML की indentation syntax का उपयोग करने वाला सुरक्षित और सरल format है, लेकिन यह Python-only है, अन्य भाषाओं में इसका implementation नहीं है, और spec compliance इसका लक्ष्य भी नहीं है
इस परिदृश्य में ऐसी library की कमी रही है जो तेज़ हो, पूरा YAML 1.2 compliance दे, और PyYAML के default interface की जगह आसानी से ले सके

py-yaml12 का परिचय

py-yaml12 Python के लिए YAML 1.2 parser और formatter है, जिसे speed और accuracy के लिए Rust में implement किया गया है
py-yaml12, Rust YAML library saphyr crate के ऊपर बना है, और loading के लिए parse_yaml(), read_yaml(), तथा serialization के लिए format_yaml(), write_yaml() जैसा छोटा और focused API देता है
सरलता
- ज़्यादातर use cases में यह शुरू से अंत तक dict, list, int, float, str, None जैसे basic Python built-in types के साथ काम करने के लिए डिज़ाइन किया गया है
- सामान्य path में कोई special document classes या custom node types नहीं हैं, और क्योंकि YAML 1.2 JSON का superset है, हर valid JSON समान रूप से parse हो जाता है
- py-yaml12 community-maintained edge cases और conformance tests के संग्रह yaml-test-suite पर 100% compliance हासिल करता है
- regions list में no, PyYAML के YAML 1.1 behavior में चुपचाप False बन जाता है, लेकिन py-yaml12 के YAML 1.2 behavior में spec के अनुसार string "no" ही रहता है
- file API भी सीधी-सादी है; Python dictionary को disk पर लिखकर फिर वापस पढ़ें तो वही object lossless round trip के साथ मिलता है
- tagged values जैसे advanced YAML features के लिए यह Yaml wrapper type देता है, लेकिन सामान्य configuration कार्यों में यह optional है
सुरक्षा
- py-yaml12 के defaults सिर्फ convenience नहीं बल्कि सुरक्षा भी बढ़ाते हैं; इसके विपरीत PyYAML tags को commands की तरह मानने की दिशा में गया, जिससे सिर्फ YAML file पढ़ने भर से arbitrary Python code execution का जोखिम पैदा हो सकता है
- यदि PyYAML के Python object-apply tag namespace को alias करने वाली YAML file को yaml.load(f, Loader=yaml.Loader) से पढ़ा जाए, तो साधारण dictionary लौटाने से पहले Python code execute हो सकता है
- उदाहरण में parsing result {'debug': False, 'retries': 3} जैसा दिखाई देता है, लेकिन उससे पहले environment variable YAML_PAYLOAD_RAN को '1' पर set किया जा चुका होता है; सिर्फ result देखकर execution का पता नहीं चलता
- py-yaml12 ऐसे tags को execute नहीं करता जिन्हें स्पष्ट रूप से opt in न किया गया हो, बल्कि उन्हें data की तरह रखता है; unhandled tags value और tag दोनों को रखने वाले Yaml wrapper के रूप में लौटते हैं
गति
- py-yaml12 benchmarks kilobytes से megabytes तक की file sizes पर read और write performance की तुलना PyYAML के default pure Python path, LibYAML-based CSafeLoader और CSafeDumper, तथा ruamel.yaml से करते हैं
- क्योंकि core parsing और formatting logic interpreted Python के बजाय compiled Rust में implement है, py-yaml12 पूरा YAML 1.2 compliance बनाए रखते हुए PyYAML के C extension के मुकाबले की performance देता है
- अभी Python libraries में ऐसे विकल्प बहुत कम हैं जो पूर्ण YAML 1.2 compliance और PyYAML C extension स्तर की performance दोनों साथ दें

निष्कर्ष

आम YAML बनाम TOML बहस अब काफी हद तक ऐसे format के खिलाफ बहस जैसी है, जो अपनी समस्याग्रस्त पुरानी शक्ल में अब मौजूद ही नहीं है; आलोचना वास्तविक थी, लेकिन उसका स्वभाव ऐतिहासिक है
YAML की आलोचना अक्सर spec-compliant YAML 1.2 नहीं बल्कि PyYAML के माध्यम से अनुभव की गई YAML 1.1 पर निशाना साधती है
TOML उथली और सपाट configuration के लिए अब भी अच्छा विकल्प है, और pyproject.toml उस भूमिका में ठीक बैठता है; लेकिन यह दावा कि YAML मूलतः असुरक्षित या अप्रत्याशित है, compatible YAML 1.2 parser के सामने टिकता नहीं
असली प्रश्न यह नहीं कि अमूर्त रूप में कौन-सा format सर्वोत्तम है, बल्कि यह है कि कौन-सा format और कौन-से tools किसी खास काम के लिए उपयुक्त हैं
जटिल, deeply nested, मानव-लिखित configuration files के लिए आधुनिक parser के साथ YAML 1.2 एक मजबूत जवाब है, और formats उसी तरह सुधरते हैं जैसे अगली पीढ़ी पिछली पीढ़ी की खुरदरी किनारों को ठीक करती है
Python में pip install py-yaml12 चलाकर आधुनिक, spec-compliant YAML अनुभव देखा जा सकता है
R environment में r-yaml12 वही फायदे देता है: पूर्ण YAML 1.2 compliance, Rust-आधारित performance, और सुरक्षित defaults, ठीक Python package की तरह

1 टिप्पणियां

GN⁺ 21 시간 전

Lobste.rs प्रतिक्रियाएँ

यह कहना अजीब है कि YAML, JSON की कमियाँ भरने के लिए आया था। याददाश्त के हिसाब से YAML, Perl कम्युनिटी से निकला था, और संभव है कि वह JSON जितना पुराना या उससे भी पुराना हो।
असल इतिहास देखने पर YAML के संस्थापकों में से एक Ingy dot Net की दिलचस्प पोस्ट में इसकी शुरुआत नवंबर 1999 से जनवरी 2001 के बीच बताई गई है।
और JSON के इतिहास पर यह लेख देखें तो JSON जैसा प्रारंभिक रूप अप्रैल 2001 में hidden iframe और <script> टैग के जरिए server से client तक message भेजने के तरीके में दिखता है, और Douglas Crockford ने json.org सार्वजनिक करने के बाद 2002 में जाकर यह एक स्वतंत्र format बना।
इसलिए YAML, JSON से थोड़ा पहले आया था, या उदारता से देखें तो दोनों लगभग साथ-साथ विकसित हुए। यह कहना सही नहीं है कि YAML, JSON की प्रतिक्रिया में या उसकी कमियाँ भरने के लिए बना; YAML वास्तव में XML की प्रतिक्रिया था। JSON भी <script> टैग में data सीधे डालने की व्यावहारिक ज़रूरत से शुरू हुआ था, लेकिन XML के मुकाबले एक सरल विकल्प के रूप में लोकप्रिय हुआ — यह मानने से इनकार करना मुश्किल है।
खुद लेख में भी LLM द्वारा लिखा हुआ लगने वाला असर है, और जिस project का ज़िक्र है वह भी vibe-coded लगता है।
- यह कहना सही है कि YAML मूल रूप से XML की प्रतिक्रिया और उसका विकल्प था।
- YAML की complexity की आलोचना करने के बाद आगे चलकर नई YAML spec की तारीफ़ करने वाले हिस्से में मुझे भी LLM वाली गंध आई। 1.2.2 spec को 4-level depth पर लंबा कहकर कोसा गया है, लेकिन बाद में कहा गया है कि 1.2.2 अभी भी बड़ा है, पर 1.1 से काफी कम complex है।
  हर वाक्य अपने-आप में ठीक लगता है, लेकिन कुल मिलाकर बात उलझी हुई है। और TOML को यह कहकर बचाया जाता है कि वह spec वाला language है, जबकि YAML पर complex spec होने के लिए हमला किया जाता है — यह भी थोड़ा अजीब है। ऐसा लगने लगता है मानो YAML में पहले spec नहीं थी और TOML में थी।
- उस इतिहास में एक बात और जोड़ें तो Crockford मूल रूप से E के subset Data-E के साथ काम कर रहे थे, और Data-E सिर्फ simple data को represent करता था। E के लेखकों ने अपनी भाषा को आगे बढ़ाने के बजाय ECMAScript को capability-safe बनाने की दिशा ली, और उसके परिणामस्वरूप E के कई ideas जैसे WeakMap, ECMAScript में आए।
  JSON असल में ECMAScript-जैसा Data-E के ज्यादा करीब है। Data-E का archived page देखें तो पता चलता है कि वे भी XML की प्रतिक्रिया में काम कर रहे थे।
- अगर लेख को सद्भावना से दोबारा पढ़ें, तो शायद यह कहा जा सकता है कि YAML का development नहीं, बल्कि YAML का adoption JSON की सीमाओं की प्रतिक्रिया था। निजी तौर पर मुझे भी YAML का पता JSON के पहले से व्यापक रूप से फैल जाने के बाद ही चला। लेकिन इस धारणा के समर्थन में मेरे पास कोई data नहीं है।
अगर inline tables का इस्तेमाल करें, तो “खराब” TOML उदाहरण कुछ ऐसा बनता है:
```
[services.web]  
image = "nginx:latest"

environment = {  
  DB_HOST = "postgres",  
  DB_PORT = 5432,  
}

resources.limits = {  
  memory = "512M",  
  cpu = "0.5",  
}  
```
देखने में ठीक है, और अगर अक्षर गिनें तो YAML उदाहरण से भी छोटा लगता है।
अगर इस लेख का लक्ष्य YAML का बचाव करना है, तो शायद यह दायरे से बाहर हो, लेकिन अच्छा होता अगर TOML 1.1 और नए inline table features की भी बात की जाती। ये JSON की तीन नापसंद चीज़ें ठीक कर देते हैं: बिना quotes वाले key names, comment strings, और trailing commas का support।
- यह कहा जा सकता है कि “YAML की आलोचना अब ऐसे format पर हमला है जो अपनी problematic form में अब मौजूद ही नहीं है”, लेकिन उसके बाद पुराने TOML versions के खिलाफ तर्क देना थोड़ा अजीब लगता है।
  Python 3.15, TOML 1.1 को support करता है, और TOML 1.1 का adoption YAML 1.2 की तुलना में कहीं बेहतर लगता है। TOML 1.0 parser को 1.1 पर update करना शायद लगभग मामूली काम होगा, लेकिन YAML 1.1 को 1.2 पर ले जाना वैसा नहीं लगता। yaml.org पर मुझे changes की सूची भी ठीक से नहीं मिली, बस दो बहुत बड़ी specs दिखीं।
  “Norway Problem” जैसी चीज़ें YAML को नापसंद करने के कारणों में मेरे लिए बस छोटे footnote जैसी हैं; असली वजह यह है कि इसे edit करना झंझट वाला है, इसमें significant whitespace है, और कुल मिलाकर यह काफी complex है।
मेरे हिसाब से YAML, JSON, और TOML — तीनों की अपनी-अपनी जगह है। जो जगह मुझे लंबे समय तक खाली लगती थी, उसे https://kdl.dev/ ने भर दिया।
JSON = मनमाने तरीके से nested data interchange
YAML = multi-line strings रखने के लिए shallow container format
TOML = लगभग flat config files
KDL = Ruby-style DSL को data के रूप में व्यक्त करना
- नए projects में जब config की ज़रूरत होती है, तो मैं भी अब KDL पर आकर टिक गया हूँ। क्योंकि यह कई गैर-ज़रूरी delimiter syntax और indentation rules को हटा देता है।
- KDL वाकई अच्छा है। इसे इस्तेमाल करने का मौका ढूँढ़ता रहता हूँ। XML की तरह कुछ स्थितियों में attributes और child nodes साथ होने पर markup कहीं ज़्यादा readable हो जाता है, और यह उस विकल्प को हल्के syntax में देता है, जो बहुत अच्छा है।
- उदाहरण देखते ही मेरा पहला ख़याल था, “यह तो SDLang जैसा दिखता है,” और वह संयोग नहीं था। KDL से परिचय कराने के लिए अच्छा लगा।
Norway problem जैसी चीज़ों की वजह से मुझे YAML पसंद नहीं है। YAML 1.2 ने इसे थोड़ा कम किया है, लेकिन बिना quotes वाली strings की वजह से "", "Null", "true", "FALSE" जैसी strings अभी भी समस्या बनती हैं, और YAML को समझने वाला encoder चाहिए। इसकी कुल मिलाकर complexity भी पसंद नहीं, लेकिन YAML से मेरी नफ़रत की असली वजह यह है

tab characters must not be used in indentation
जब indentation का अर्थ होता है, तब tabs और spaces को मिलाकर या असंगत तरीके से इस्तेमाल करने पर रोक लगाना ठीक है। Python 3 का approach काफ़ी अच्छा लगता है
Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case.
लेकिन YAML ऐसा इकलौता file format लगता है जो indentation को allow या require तो करता है, पर tabs और spaces दोनों को support नहीं करता।
आप कह सकते हैं कि Make spaces को support नहीं करता, लेकिन .RECIPEPREFIX को tab के अलावा किसी और value पर set किया जा सकता है। यहाँ तक कि Make में tab को indentation नहीं, बल्कि Make का marker भी माना जा सकता है
- अभी मिल नहीं रहा, लेकिन मुझे याद है कि मैंने एक quote पढ़ी थी जिसमें Guido van Rossum ने कहा था कि अगर वह Python को शुरू से फिर बनाते, तो जिन चीज़ों को वह ज़रूर बदलना चाहते, उनमें से एक indentation में actual tab character पर रोक होती।
  PEP-8 भी indentation में tabs न इस्तेमाल करने की मज़बूती से सिफारिश करता है।
  
  Tabs should be used solely to remain consistent with code that is already indented with tabs.
  -- https://peps.python.org/pep-0008/#tabs-or-spaces
- संदर्भ के लिए, NestedText spec भी यह कहती है
  
  Only ASCII spaces are allowed in the indentation. Specifically, tabs and the various Unicode spaces are not allowed.
“YAML बुरा नहीं है, YAML 1.1 बुरा था, और वैसे भी ज़्यादातर लोग 1.1 parser इस्तेमाल करते हैं” वाली दलील उतनी असरदार नहीं लगती जितना लेख चाहता है।
मैं सीमित और सावधानी से इस्तेमाल किया गया YAML पसंद करता हूँ, और YAML 1.2 के लिए नए high-performance parsers आना भी अच्छा है, लेकिन अगर “बुरा” version अब भी बहुमत में इस्तेमाल हो रहा है, तो मैं शायद कुछ और चुनूँगा। अगर मैं यह control नहीं कर सकता कि कौन-सा parser इस्तेमाल होगा, इसलिए यह भरोसा भी नहीं कर सकता कि मेरा YAML सही तरह interpret होगा, तो कुल मिलाकर YAML अब भी “बुरी” स्थिति में है।
सबको 1.2 पर जाना चाहिए, लेकिन तब तक YAML को सावधानी से लेना ठीक है
“YAML बनाम TOML बहस अक्सर ऐसे format पर हमला करने वाली बहस है जो अब समस्याग्रस्त रूप में लगभग मौजूद ही नहीं है, और शिकायतें असली हैं लेकिन ऐतिहासिक हैं” — यह पंक्ति GitHub Actions और Kubernetes के सामने चीख निकलवा देती है
बचाव की दलील मज़बूत है। फिर भी बहुत simple documents में TOML ज़्यादा readable है, और लोगों से YAML की बजाय TOML इस्तेमाल करवाना आसान है।
अफ़सोस की बात है कि tools को लेकर public developer perception बदलने में inertia बहुत लंबी चलती है। लोग कोई कहानी पढ़ते हैं, राय बना लेते हैं, और फिर ऐसे दूसरे tool पर चले जाते हैं जिसने सार्वजनिक रूप से ऐसी गलती नहीं की हो
- arrays को शामिल करने पर अगर organization 2 levels से आगे निकल जाए, तो फिर यह सही नहीं रहता। उस point के बाद indentation structure को समझना काफ़ी आसान बना देती है
काश Ruby interpreter में शामिल YAML parser YAML 1.2.2 को support करता।
लेकिन ecosystem तोड़े बिना नए version को default पर switch करने का तरीका मुझे समझ नहीं आता
अच्छा होता अगर config file formats में standardized schema specify करने की सुविधा होती। तब editors किसी भी random config file को देखकर typo वाले keys या type mismatch बता सकते।
hover hints में यह भी document किया जा सके कि कोई key किस काम की है, और valid keys की autocomplete भी आसानी से मिलनी चाहिए। अगर गलत values पकड़ने के लिए simple assertions या contracts का support भी हो, तो और अच्छा। उदाहरण के लिए "color" key को /#[a-fA-F0-9]{6}/ से match करना चाहिए।
आदर्श रूप से इससे config file data structures भी auto-generate हो सकें
- वह तो बस XML का ही वर्णन है।
  XSD या Relax NG जैसी कई validation spec formats हैं, और मैं XML DTD से सबसे ज़्यादा परिचित हूँ, इसलिए बाकी के बारे में ज़्यादा नहीं कह सकता
- JSON files में top-level key के रूप में $schema property रखना और सही schema define करने वाली JSON Schema file को refer करना काफ़ी आम है। मूल रूप से यह JSON के लिए XSD है। अच्छे editors आम तौर पर इसी आधार पर autocomplete और red underlines दे सकते हैं।
  अच्छी बात यह है कि TOML और YAML लगभग सिर्फ़ syntax में अलग JSON ही हैं, इसलिए अक्सर JSON Schema files को इनके साथ भी इस्तेमाल किया जा सकता है