YAML’ı Savunurken

(opensource.posit.co)

1 puan yazan GN⁺ 21 시간 전 | 1 yorum | WhatsApp'ta paylaş

YAML 1.2, insanların doğrudan yazdığı iç içe yapılandırma dosyaları için girintiye dayalı bir serileştirme biçimidir; eski PyYAML deneyimlerinden kaynaklanan güvenilmezlik eleştirileriyle bunun ayrıştırılması gerekir
Yapılandırma dosyası biçimleri, INI’nin düz yapısı, XML’in aşırı ayrıntılı oluşu, JSON’ın yorum ve çok satırlı string eksikliği gibi önceki kuşakların sınırlamalarını düzeltme yönünde evrilmiştir
TOML, pyproject.toml ve Cargo.toml gibi sığ yapılarda nettir; ancak derin iç içe yapılar söz konusu olduğunda yol tekrarları ve tablo dizileri nedeniyle okuma ve düzenleme yükü artar
YAML 1.2 Core Schema, yes, no, on, off, y, n değerlerini string olarak işler; 60 tabanlı sayıları ve çekirdek tür olarak zaman damgalarını kaldırarak geçmişteki örtük tür çıkarımı sorunlarını azaltır
py-yaml12, Python için bir YAML 1.2 ayrıştırıcı ve biçimlendiricisidir; Rust uygulaması sayesinde güvenli varsayılanlar, yaml-test-suite ile %100 uyumluluk ve PyYAML C eklentisiyle yarışabilecek performans sunar

Sorunun çerçevesi

Son birkaç yılda yapılandırma dosyası biçimleri etrafındaki hava, YAML kötüdür ve TOML iyidir yönüne kaydı; ancak YAML değerlendirmesi tarihçeyi, belirtimdeki değişiklikleri ve 2026’daki araç durumunu birlikte görmeyi gerektiriyor
YAML eleştirileri uzun süre boyunca haklıydı ve dikkatli kullanıcılar bile beklenmedik davranışlarla karşılaştı; fakat belirtim değişti ve araç ekosistemi de buna yetişiyor
Günümüzdeki YAML eleştirilerini anlamak için yapılandırma dosyası biçimlerinin soy ağacına bakmak gerekir; önceki biçimlerin aşırılıklarının sonraki biçimlerce düzeltilmesi tartışması tekrar eden bir akıştır

Yapılandırma dosyası biçimlerinin kısa tarihi

INI dosyaları 1980’lerin başında MS-DOS ve ilk Windows sürümleriyle ortaya çıktı; anahtar-değer çiftleri, köşeli parantezli bölümler ve noktalı virgül yorumları içeren, düz yapılı ve kolay okunur, insan tarafından düzenlenebilir bir biçimdi
INI, aygıt sürücüsü yapılandırması, yazı tipi yolu tanımlama ve uygulama ayarları gibi dönemin ihtiyaçları için yeterliydi; ancak bir seviyeden fazla iç içe yapı kuramaması ve resmi bir belirtiminin olmaması nedeniyle ayrıştırıcıların farklı lehçeler uygulamasına yol açan yapısal sınırlamalara sahipti
XML, 1990’ların sonlarında kurumsal yazılım dünyasında yaygın biçimde benimsendi; keyfi hiyerarşi, şema, ad alanları, dönüşümler ve kendini açıklayan yapı sundu, fakat gerçek yapılandırma dosyaları fazlasıyla ayrıntılı hale geldi ve elde bakımı zorlaştı
JSON, XML’e daha hafif bir tepki olarak ortaya çıktı ve JavaScript nesne literallerinin sadeliği sayesinde 2000’lerin sonu ile 2010’ların başında web API’lerinde XML’in yerini aldı; ancak yapılandırma dosyası olarak kullanıldığında yorum yokluğu, çok satırlı string desteğinin olmaması ve sondaki virgüllerin yasaklanması gibi kısıtlar getirdi
YAML 2001’de, TOML ise 2013’te JSON’ın bıraktığı boşluğu doldurmak için ortaya çıktı; YAML girinti tabanlı sözdizimiyle keyfi iç içelik, çoklu belge, referanslar ve kullanıcı tanımlı türler sunarken, TOML açık türler ve resmi bir belirtimle “standartlaştırılmış INI” olmayı hedefledi
Her yeni kuşak biçim, önceki biçimin aşırılıklarından yola çıktı; bugün YAML ile ilgili sorunların önemli bir kısmı biçim tasarımının kendisinden ziyade belirli belirtim sürümlerinin ve onlara bağlı ayrıştırıcıların ürünü

YAML’a karşı öne sürülen sorunlar

YAML eleştirileri uydurulmuş değildi; yıllar boyunca gerçek programcıların yaşadığı deneyimlere dayanıyordu
En ünlü örnek olan Norway sorunu, YAML 1.1’de tırnaksız skaler NO değerinin boolean false olarak yorumlanması ve ülke kodu listelerindeki no değerinin false’a dönüşmesiydi
```
countries:
  - dk
  - fi
  - is
  - no
  - se
```
```
["dk", "fi", "is", false, "se"]
```
Aynı kural yes, on, off, y, n ve bunların farklı büyük-küçük harf varyasyonlarına da uygulanıyordu; ayrıca 22:22 gibi port eşlemeleri 60 tabanlı tamsayıya, 10.23 gibi sürüm numaraları string yerine kayan noktalı sayıya, tarih gibi görünen değerler ise zaman damgasına çevriliyordu
Veri bilimi ve makine öğrenimi kodlarında doğal değişken adları olan n ve y de, YAML 1.1’in örtük boolean kuralları altında string anahtarlar yerine False ve True anahtarları olarak yorumlanabiliyordu
```
{"variables": {"x": "features", False: "sample_size", True: "target"}}
```
YAML 1.1’in agresif örtük tür çıkarımı, tırnaksız true değerini boolean olarak okuyarak okunabilirlik sağlamayı amaçlıyordu; fakat gerçek yapılandırma dosyalarında sonuç çoğu zaman öngörülemezlik oldu
Yapılandırma dosyaları sık düzenlenmez ve çoğu zaman ilk yazan kişi dışındaki insanlar tarafından değiştirilir; sessiz yanlış ayrıştırmalar aylar boyunca sisteme yayılabildiğinden, beklenmedik davranışların en az tolere edilebildiği alanlardan biridir
Tüm YAML belirtiminin karmaşıklığı da ek bir yük oluşturuyordu; YAML 1.2.2 belirtimi, 10 bölüm ve dört seviyeli numaralı bölüm yapısı içeren oldukça kapsamlı bir dokümandır
Çok satırlı string ifade etmenin birçok yolu vardır ve anchor ile alias güçlü bir referans sistemi kurar; ancak bunlar çoğu yapılandırma işi için gerekli olandan daha ağır kavramsal araçlardır
Etiket tabanlı nesne ters serileştirmesinin güvenlik sorunları, özellikle Python’daki yaml.load() açığı, iyi bilinen bir saldırı vektörü haline geldi; bu eleştiriler YAML 1.1 ve çevresindeki araç ekosistemi için geçerliydi

TOML’in iyi yaptığı şeyler

TOML, düz ya da sığ yapılandırma yapılarında temiz, okunabilir ve belirsizlik içermeyen bir biçimdir
TOML sözdizimi, INI dosyası görmüş herkes için tanıdıktır; bunun üzerine açık türler, resmi belirtim ve noktayla ayrılmış anahtarlar üzerinden iç içe tablolar desteği ekler
pyproject.toml ve Cargo.toml, genellikle bir veya iki seviye derinlikte iyi tanımlanmış bölümler ve öngörülebilir içerik taşıdıkları için TOML’e çok uygundur
TOML’de string’ler her zaman tırnak içindedir; bu sayede no değerinin boolean mı yoksa kelime mi olduğu belirsiz değildir, tamsayı, kayan noktalı sayı ve tarih birinci sınıf türlerdir, yorumlar da beklendiği gibi çalışır
Python paketleme ekosisteminde PEP 518’in benimsenmesi ve Rust topluluğunda Cargo kullanımı, bu problem alanında TOML’in uygun bir seçim olduğunu gösterir
TOML belirtimi, yetkin bir programcının hafta sonunda uyumlu bir ayrıştırıcı yazabileceği kadar kısadır; bunun sonucu olarak ayrıştırıcı ekosistemi geniş, iyi test edilmiş ve tutarlıdır
TOML’de, YAML 1.1 ile 1.2 arasındaki sürüm bölünmesine benzer bir sorun yoktur; TOML 1.0 her yerde TOML 1.0’dır

TOML’in zorlandığı noktalar

Yapılandırma dosyası derinlik ifade etmek zorunda kaldığında, TOML’in iç içe yapısı noktayla ayrılmış bölüm başlıklarına ([servers.alpha]) veya tablo dizilerine ([[products]]) dayanır; iç içelik arttıkça yapı daha zor okunur hale gelir
PyTOML’den Martin Vejnár, kendi kütüphanesinin pip bağımlılığı olmasını reddederken, yapılandırma şeması karmaşıklaştıkça TOML sözdiziminin çirkinleştiği ve okunmasının zorlaştığı deneyimini gerekçe gösterdi

YAML’de girinti hiyerarşiyi tek bakışta gösterir; TOML’de ise tam yolun her bölüm başlığında tekrar edilmesi gerekir

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 okuyucusu, düzleştirilmiş niteleyici isimler dizisinden ağaç yapısını zihninde yeniden kurmak zorundadır; StrictYAML belgelerindeki ölçümlere göre aynı veriyi ifade ederken TOML dosyası, tekrar eden yol önekleri nedeniyle yaklaşık %50 daha fazla karakter kullanır
Python, girintiyi yapı olarak kullanmanın zayıflık değil güç olduğunu uzun zaman önce gösterdi; görsel yapı ile sözdizimsel yapının ayrışmasından doğan hata türlerini ortadan kaldırır
YAML, bu girinti tabanlı yapı avantajını devralır; TOML ise girintiyi zorunlu kılmadığından, anahtarlarla kapsayan tablolar arasındaki ilişki dosyanın fiziksel yerleşiminde değil yalnızca bölüm başlıklarında bulunur
Derin iç içe yapılandırma dosyalarında TOML taraması zor, güvenle düzenlemesi daha da zordur

YAML 1.2’deki değişiklikler

YAML 1.2 belirtimi 2009’da yayımlandı, açıklık getiren 1.2.2 revizyonu ise Ekim 2021’de tamamlandı
YAML 1.2 Core Schema, yalnızca true, false ile True, False, TRUE, FALSE değerlerini boolean olarak tanır; yes, no, on, off, y, n ise normal string’lerdir
22:22 sorununu yaratan 60 tabanlı sayı literalleri tamamen kaldırıldı ve zaman damgası artık çekirdek tür olmadığından, Core Schema altında tırnaksız 2026-05-05 otomatik algılanan tarih değil string’dir
JSON, YAML 1.2’nin katı ve doğru bir alt kümesi haline geldi; geçerli her JSON belgesi YAML olarak da aynı şekilde ayrıştırılır
Etiket yorumlama kuralları daha sıkı ve nettir; belirtimin kendisi de daha açık yazılmıştır ve GitHub üzerinde açık biçimde sürdürülür
İnsanların eleştirdiği YAML çoğu zaman YAML 1.1’dir; bugün dili tanımlayan baskın belirtim ise daha güvenli ve daha öngörülebilir YAML 1.2’dir
Sorun şu ki kullanıcıların YAML deneyimi belirtim üzerinden değil, ayrıştırıcılar üzerinden şekillenir; Python kullanıcılarının çoğu için bu ayrıştırıcı, YAML 1.1 uygulayan ve 2006’dan beri temel anlambilimini değiştirmemiş olan PyYAML’dir

Python YAML ayrıştırıcı ekosistemi

PyYAML, Python’un fiili standart YAML kütüphanesidir; performans için C kütüphanesi LibYAML’i sarar ve saf Python yedek yolu da sunar
PyYAML haftada milyonlarca kez indirilir ve sayısız paketin bağımlılığıdır; ancak YAML 1.1 uygular ve Python ekosistemindeki “YAML ülke kodunu boolean’a çevirdi” deneyiminin kaynağıdır
PyYAML deposunda 200’den fazla açık issue ve 100’den fazla açık pull request bulunur; proje bakım görüyor olsa da yavaş ilerliyor ve YAML 1.2 anlambilimine büyük sürüm geçişi henüz gerçekleşmedi
ruamel.yaml, YAML 1.2 desteğiyle birlikte yorumları, flow style’ı ve anahtar sırasını koruyan round-trip düzenleme imkânı sunar; yorum koruma veya biçim duyarlı düzenleme için PyYAML’den çok daha güçlü bir seçenektir
ruamel.yaml, varsayılan round-trip modunda çoğunlukla saf Python uygulaması kullandığından, PyYAML’in C tabanlı hızlı yolundan belirgin biçimde daha yavaştır; ayrıca namespace package sorunları ve bağımlılık zinciri nedeniyle dağıtım süreçlerini zorlaştıran bir paketleme geçmişi vardır
StrictYAML, YAML’in kasıtlı bir alt kümesini uygular; tüm örtük tür çıkarımını, etiketleri, anchor’ları ve flow style’ı kaldırır
StrictYAML felsefi olarak tam YAML’den çok TOML’e yakındır; YAML’in girinti sözdizimini kullanan güvenli ve sade bir biçimdir, ancak yalnızca Python’a yöneliktir, başka dil uygulamaları yoktur ve belirtime tam uyum hedeflemez
Bu tabloda, hızlı, tam YAML 1.2 uyumlu ve PyYAML’in temel arayüzünün yerine kolayca geçebilecek bir kütüphane eksikti

py-yaml12’ye giriş

py-yaml12, Python için bir YAML 1.2 ayrıştırıcı ve biçimlendiricisidir; hız ve doğruluk için Rust ile uygulanmıştır
py-yaml12, Rust YAML kütüphanesi saphyr crate’i üzerine kuruludur ve yükleme için parse_yaml(), read_yaml(), serileştirme için format_yaml(), write_yaml() adlarında küçük ve odaklı bir API sunar
Sadelik
- Çoğu kullanım senaryosunda baştan sona yalnızca dict, list, int, float, str, None gibi temel Python yerleşik türleriyle çalışacak şekilde tasarlanmıştır
- Genel yolda özel belge sınıfları veya kullanıcı tanımlı düğüm türleri yoktur; YAML 1.2 JSON’ın üst kümesi olduğundan tüm geçerli JSON aynı şekilde ayrıştırılır
- py-yaml12, topluluk tarafından sürdürülen uç durum ve uygunluk testleri koleksiyonu olan yaml-test-suite içinde %100 uyumluluk sağlar
- regions listesindeki no, PyYAML’in YAML 1.1 davranışında sessizce False olurken, py-yaml12’nin YAML 1.2 davranışında belirtimin gerektirdiği string "no" olarak kalır
- Dosya API’si de doğrudandır; bir Python sözlüğünü diske yazıp geri okuduğunuzda aynı nesneyi veren kayıpsız bir round-trip davranışı sağlar
- Etiketli değerler gibi ileri YAML özellikleri için Yaml sarmalayıcı türü sunar; fakat tipik yapılandırma işleri için bu isteğe bağlıdır
Güvenlik
- py-yaml12’nin varsayılanları yalnızca kullanım kolaylığı değil, güvenlik de sağlar; PyYAML’in ters yaklaşımı etiketleri komut gibi ele alır ve yalnızca bir YAML dosyasını okumak bile keyfi Python kodunun çalıştırılması riskini doğurabilir
- PyYAML’in Python object-apply etiket ad alanına takma ad veren bir YAML dosyasını yaml.load(f, Loader=yaml.Loader) ile okumak, sıradan bir sözlük döndürmeden önce Python kodunun çalıştırılmasına yol açabilir
- Örnekte ayrıştırma sonucu {'debug': False, 'retries': 3} gibi görünür; ancak bundan önce YAML_PAYLOAD_RAN ortam değişkeni '1' olarak ayarlanmıştır ve yalnızca sonuca bakarak yürütmenin gerçekleştiği anlaşılmaz
- py-yaml12, açıkça seçmediğiniz etiketleri çalıştırmaz; onları veri olarak tutar ve işlenmeyen etiketleri değer ile etiketi içeren bir Yaml sarmalayıcı olarak döndürür
Hız
- py-yaml12 kıyaslamaları, kilobayttan megabayta kadar dosya boyutlarında okuma ve yazma performansını PyYAML’in varsayılan saf Python yolu, LibYAML tabanlı CSafeLoader ve CSafeDumper, ayrıca ruamel.yaml ile karşılaştırır
- Temel ayrıştırma ve biçimlendirme mantığı yorumlanan Python yerine derlenmiş Rust ile yazıldığından, py-yaml12 tam YAML 1.2 uyumluluğunu korurken PyYAML’in C eklentisiyle yarışabilecek performans sunar
- Günümüzde Python kütüphaneleri arasında hem tam YAML 1.2 uyumluluğu hem de PyYAML C eklentisi düzeyinde performans sağlayan seçenek sayısı azdır

Sonuç

Yaygın YAML ve TOML tartışması, sorunlu hali artık fiilen var olmayan bir biçim etrafında dönen bir tartışmaya daha çok benziyor; eleştiriler gerçekti ama tarihsel nitelik taşıyor
YAML eleştirileri çoğu zaman belirtime ve doğru uygulanmış YAML 1.2’ye değil, PyYAML üzerinden deneyimlenen YAML 1.1’e yöneliktir
TOML, sığ ve düz yapılandırmalar için hâlâ iyi bir seçimdir ve pyproject.toml bu role çok uygundur; ancak YAML’in özünde güvensiz veya öngörülemez olduğu iddiası, uyumlu bir YAML 1.2 ayrıştırıcısı karşısında geçerli değildir
Asıl önemli soru, soyut olarak hangi biçimin en iyi olduğu değil; belirli bir iş için hangi biçim ve hangi aracın uygun olduğudur
Karmaşık ve iç içe, insanlar tarafından yazılan yapılandırma dosyaları için modern ayrıştırıcılı YAML 1.2 güçlü bir yanıttır; biçimler, önceki kuşakların pürüzlerinin sonraki kuşaklarca giderilmesiyle gelişir
Python’da pip install py-yaml12 ile modern ve belirtime uygun bir YAML deneyimi denenebilir
R ortamında ise r-yaml12, tam YAML 1.2 uyumluluğu, Rust tabanlı performans ve güvenli varsayılanlar dahil aynı avantajları sunar

1 yorum

GN⁺ 21 시간 전

Lobste.rs görüşleri

YAML’ın JSON’daki boşlukları doldurmak için ortaya çıktığı açıklaması tuhaf. Hatırladığım kadarıyla YAML, Perl topluluğundan çıktı ve JSON’la yaşıt, hatta ondan daha eski olma ihtimali var
Gerçek tarihe bakınca, YAML’ın yaratıcılarından Ingy dot Net’in ilginç yazısında kökeni 1999 Kasım ile 2001 Ocak arasına tarihlendiriliyor
Ayrıca JSON tarihçesi yazısına bakılırsa, ilkel JSON biçimi 2001 Nisan’ında sunucudan istemciye gizli iframe ve <script> etiketiyle mesaj gönderme yönteminde ortaya çıkmış, ancak Douglas Crockford’un json.org’u yayımladığı 2002’de bağımsız bir format haline gelmiş
Bu yüzden YAML JSON’dan biraz daha önce gelmiş olabilir ya da en cömert yorumla ikisi eşzamanlı gelişmiş sayılır. JSON’a bir tepki olarak ya da JSON’daki boşlukları doldurmak için ortaya çıktığı açıklaması doğru değil; YAML aslında XML’e bir tepkiydi. JSON da <script> etiketine veriyi doğrudan gömmeye yönelik pratik bir ihtiyaçtan doğdu, ama XML’den daha basit bir alternatif olarak yerleşip popülerleştiğini inkâr etmek zor
Yazının kendisinde de sanki bir LLM yazmış gibi izler var; tanıtılan proje de vibe coding ile yapılmış gibi duruyor
- YAML’ın başlangıçta XML’e bir tepki ve alternatif olduğunu söylemek doğru
- YAML karmaşıklığını eleştirip sonra yeni YAML spesifikasyonunu öven bölümde ben de LLM kokusu aldım. 1.2.2 spesifikasyonunu 4 seviye derinlikte uzuyor diye eleştirirken, ileride 1.2.2’nin hâlâ büyük olsa da 1.1’den çok daha az karmaşık olduğunu söylüyor
  Cümlelerin her biri tek tek makul ama bütün olarak kafa karıştırıcı. Ayrıca TOML’ü spesifikasyonu olan bir dil diye savunurken YAML’ı karmaşık bir spesifikasyonu var diye eleştirmesi de biraz tuhaf. Sanki YAML’ın başta spesifikasyonu yokmuş da TOML’ün varmış gibi bir izlenim doğuyor
- Bu tarihe bir şey daha eklemek gerekirse, Crockford aslında E’nin bir alt kümesi olan Data-E ile uğraşıyordu ve Data-E yalnızca basit veriyi ifade ediyordu. E’nin yazarları kendi dillerini öne çıkarmak yerine ECMAScript’i capability-safe hale getirmeye yöneldi; bunun sonucu olarak WeakMap gibi E’den birçok fikir ECMAScript’e girdi
  JSON aslında fiilen ECMAScript tarzı bir Data-E’ye daha yakın. Data-E’nin arşivlenmiş sayfasına bakınca onların da XML’e tepki verdiği görülüyor
- Yazıyı iyi niyetli biçimde yeniden yorumlarsak, YAML’ın geliştirilmesinin değil ama YAML’ın benimsenmesinin JSON’ın sınırlamalarına bir tepki olduğu söylenebilir. Ben de şahsen YAML’ı ancak JSON zaten çok yaygınlaştıktan sonra öğrendim. Ama bunu destekleyen bir veri yok

Inline table kullanılırsa “kötü” TOML örneği şöyle oluyor

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

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

resources.limits = {  
  memory = "512M",  
  cpu = "0.5",  
}

Gayet iyi görünüyor; hatta harf sayısını sayarsak YAML örneğinden de kısa gibi duruyor

Bu yazının amacı YAML’ı savunmak olduğu için kapsam dışı sayılabilir ama TOML 1.1 ve yeni inline table özelliklerinin de ele alınmasını isterdim. JSON’da hoşuma gitmeyen üç şeyi çözüyor: tırnaksız anahtar adları, yorum dizeleri ve sonda virgül desteği
- “YAML eleştirileri artık sorunlu biçimiyle var olmayan bir formatı hedef alıyor” denebilir ama ardından eski TOML sürümlerine karşı argüman kurmak biraz tuhaf
  Python 3.15, TOML 1.1’i destekliyor ve TOML 1.1’in benimsenmesi YAML 1.2’den çok daha iyi görünüyor. TOML 1.0 ayrıştırıcısını 1.1’e güncellemek muhtemelen neredeyse önemsiz bir işken, YAML 1.1’den 1.2’ye geçmek öyle görünmüyor. yaml.org’da değişiklik listesini de pek bulamadım, sadece iki devasa spesifikasyon görüyorum
  “Norway Problem” gibi şeyler YAML’dan hoşlanmamamın küçük bir dipnotu sayılır; asıl sebep düzenlemesinin zor olması, anlam taşıyan boşluklar kullanması ve genel olarak epey karmaşık olması
Bence YAML, JSON ve TOML’ün her birinin kendi alanı var. Uzun süre boş olduğunu düşündüğüm yeri ise https://kdl.dev/ doldurdu
JSON = keyfi biçimde iç içe geçebilen veri alışverişi
YAML = çok satırlı dizeler barındıran sığ kapsayıcı format
TOML = neredeyse düz yapıdaki yapılandırma dosyası
KDL = Ruby tarzı DSL’nin veri olarak ifadesi
- Yeni bir projede yapılandırma gerekiyorsa ben de artık KDL kullanıyorum. Çünkü konuyla ilgisiz ayraç sözdiziminin ve girinti kurallarının çoğunu ortadan kaldırıyor
- KDL gerçekten çok iyi. Onu kullanmak için sürekli fırsat kolluyorum. XML’de olduğu gibi öznitelikler ve alt düğümler birlikte olduğunda işaretlemenin çok daha okunabilir olduğu durumlar var; KDL bunun için hafif bir sözdizimiyle iyi bir seçenek sunuyor
- Örnekleri görür görmez “bu SDLang’e benziyor” diye düşündüm; meğer tesadüf değilmiş. KDL’ü tanıttığın için sevindim
Norway problemi gibi şeyler yüzünden YAML'dan hoşlanmıyorum. YAML 1.2 bunu biraz azalttı ama tırnaksız dizgeler yüzünden "", "Null", "true", "FALSE" gibi dizgeler hâlâ sorun çıkarıyor ve YAML'ı bilen bir encoder gerekiyor. Genel karmaşıklığından da hoşlanmıyorum ama YAML'dan gerçekten nefret etmemin asıl sebebi şu

tab characters must not be used in indentation
Girintinin anlam taşıdığı durumlarda tab ve boşluğu karıştırmayı ya da tutarsız kullanmayı yasaklamak gayet makul. Python 3'ün yaklaşımı oldukça iyi görünüyor
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.
Ama YAML, girintiye izin verip hatta onu gerektirirken hem tabı hem boşluğu desteklemeyen tek dosya biçimi gibi görünüyor
Make'in boşluğu desteklemediği söylenebilir ama .RECIPEPREFIX tab dışındaki bir değere ayarlanabiliyor. Hatta Make'te tabın girinti değil, Make'in kullandığı bir işaret olduğu da söylenebilir
- Şu an bulamıyorum ama Guido van Rossum'un Python'ı baştan yeniden yapsa mutlaka değiştirmek isteyeceği şeylerden birinin girintide gerçek tab karakterlerini yasaklamak olduğunu söylediği bir alıntı okuduğumu hatırlıyorum
  PEP-8 de girintide tab kullanılmamasını güçlü biçimde tavsiye eder
  
  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
- Bu arada NestedText belirtimi de şöyle der
  
  Only ASCII spaces are allowed in the indentation. Specifically, tabs and the various Unicode spaces are not allowed.
“Sorunlu olan YAML değil, YAML 1.1'di; ama çoğu şey 1.1 parser'ı” argümanının yazının istediği kadar ikna edici olmadığını düşünüyorum
Ölçülü kullanıldığında YAML'ı seviyorum ve YAML 1.2 için yeni yüksek performanslı parser'ların çıkmasını da memnuniyetle karşılıyorum, ama “kötü” sürüm hâlâ çoğunlukta kullanılıyorsa ben muhtemelen başka bir şey seçerim. Hangi parser'ın kullanılacağını kontrol edemediğim için kendi YAML'ımın doğru yorumlanacağına güvenemiyorsam, YAML'ın geneli hâlâ “kötü” durumdadır
Herkesin 1.2'ye geçmesi gerekir ama o zamana kadar YAML'a temkinli yaklaşmanın makul olduğunu düşünüyorum
“YAML vs TOML tartışması, genelde artık sorunlu biçimde var olmayan bir formatı hedef alan; şikâyetleri gerçek ama tarihsel olan bir tartışmadır” cümlesi karşısında GitHub Actions ve Kubernetes yüzünden çığlık atmak geliyor içimden
Savunma argümanı güçlü. Yine de çok basit belgelerde TOML daha okunaklı ve insanlara YAML yerine TOML kullandırmak daha kolay
Ne yazık ki araçlar hakkındaki kamusal geliştirici algısını değiştirmede uzun bir atalet kuyruğu var. İnsanlar bir hikâye okuyup fikrini oluşturuyor, sonra da kamuya açık hatalar yapmamış başka araçlara geçiyor
- Diziler de dahil olmak üzere yapılanma 2 seviyeyi aşınca durum böyle değil. O noktadan sonra girinti, yapıyı anlamayı çok daha kolaylaştırıyor
Ruby yorumlayıcısına gömülü YAML parser'ının YAML 1.2.2 desteklemesini isterdim
Ama ekosistemi bozmadan yeni sürüme varsayılan olarak nasıl geçileceğini pek bilmiyorum
Yapılandırma dosyası biçimlerinin standartlaştırılmış bir şema belirtmesini isterdim. Böylece editörler rastgele bir yapılandırma dosyasına bakıp yazım hatalı anahtarları veya tür uyuşmazlıklarını gösterebilirdi
Anahtarların ne işe yaradığını “hover” ipuçlarıyla belgelemek ve geçerli anahtarlar için otomatik tamamlama sunmak da kolay olmalı. Hatalı değerleri yakalamak için basit assertion'lar veya sözleşmeler bile desteklense daha iyi olurdu. Örneğin "color" anahtarı /#[a-fA-F0-9]{6}/ ile eşleşmeli gibi
İdeal olarak bununla yapılandırma dosyası veri yapıları da otomatik üretilebilmeli
- Bu, düpedüz XML tarif etmek oluyor
  XSD ya da Relax NG gibi çeşitli doğrulama belirtim biçimleri var; ben en çok XML DTD'ye aşinayım, bu yüzden diğerleri hakkında çok şey söyleyemem
- JSON dosyalarında en üst düzey anahtar olarak $schema özelliğini koyup doğru şemayı tanımlayan bir JSON Schema dosyasına başvurmak oldukça yaygın. Bu özünde JSON için XSD demek. İyi editörler genelde buna dayanarak otomatik tamamlama ve kırmızı alt çizgi sağlayabiliyor
  Güzel yanı şu: TOML ve YAML kabaca sadece sözdizimi farklı JSON sayıldığı için, çoğu zaman aynı JSON Schema dosyaları onlarla da kullanılabiliyor