XML (Extensible Markup Language) Nedir? Tanımı, Evrimi & Kullanım Alanları

Yıl 2026 ve sistemler arası veri aktarımını düşündüğünüzde, aklınıza ilk gelen yapı taşlarından biri XML’dir. Üstelik bu durum beni hiç şaşırtmıyor. Dışarıdan baktığımızda JSON ve YAML daha havalı gelebilir.

Ancak kritik işlemlerin omurgasında yine de sağlam bir işaretleme dili XML’dir. Yazılım geliştiricileri, sistem yöneticileri ve veri analistleri bu yapıyla sık sık karşılaşırlar. Ayrıca, siz de bu gruba dahilsiniz ve XML’le çalışmanız kaçınılmazdır.

Peki bu kadar eski bir teknoloji neden hâlâ dimdik ayakta? Cevap aslında çok basit: Katı kuralları ve şema doğrulama yetenekleri sayesinde veri bütünlüğünü kusursuz sağlar. Emin olun finans dünyasından tutun da devlet arşivlerine kadar her yerde bu standardın izini sürersiniz.

Ben de bu rehberde size sadece teorik tanımlar sunmayacağım. Sahadaki acı tecrübelerimden süzülen pratik bilgileri, güvenlik tuzaklarını ve geleceğe dair öngörülerimi paylaşacağım. Amacım bu satırların sonunda elinize bir fincan kahve alıp bana “Usta, şimdi çözdüm bu işi!” dedirtmek.

Hazırsanız kemerleri bağlayın. Zira Genişletilebilir İşaretleme Dili dünyası göründüğünden çok daha heyecan vericidir. İşin sırrı şu: Ne kadar derine inerseniz, sistemlerin ne kadar şık konuştuğuna o kadar hayran kalacaksınız.

Başlamadan önce sizi uyarmalıyım; bu metni okurken bazı yerlerde “Aaa demek öyle yapılıyormuş!” diyeceksiniz. Özellikle e-ticaret entegrasyonu kısmındaki anılarım hâlâ aklımdayken anlattıklarım size çok tanıdık gelecektir. Haydi başlayalım!

XML Nedir? Tanımı ve Açılımı

XML Açılımı: Extensible Markup Language & Genişletilebilir İşaretleme Dili

Bu yapının adını ilk duyduğumda kafam karışmıştı doğrusu. Kısaltmanın açılımı Extensible Markup Language yani Türkçesiyle Genişletilebilir İşaretleme Dili olarak karşımıza çıkıyor.

Bu tanımı ezberlemek işin kolay kısmıdır. Ancak buradaki “Genişletilebilir” kelimesinin verdiği muazzam özgürlüğü kavramak asıl meseledir.

Çünkü diğer sabit dillerin aksine XML sizi belirli bir kelime haznesiyle kısıtlamaz. Siz ihtiyacınıza göre kendi özel etiketlerinizi oluşturup verinizi tanımlayabilirsiniz. Mesela bir kitap listesi için <kitap> veya bir müşteri kaydı için <musteri> etiketini gönül rahatlığıyla icat edersiniz.

Bu noktada şu soruyu duyar gibiyim: “Madem bu kadar serbest bir yapı var, Extensible Markup Language neden bir programlama dili değil?”

İşte tam burada işaretleme dili kavramı devreye giriyor. XML herhangi bir işlem yapmaz veya hesaplama gerçekleştirmez. Onun tek derdi veriyi düzenli, hiyerarşik ve anlamlı bir şekilde paketlemektir.

Yani bu araç sadece taşıyıcı bir konteyner görevi görür. İçindeki değerli yükün ne olduğunu anlamak ise ayrıştırıcı yazılımlara kalmıştır.

Bu sebeple XML açılımındaki “dil” ifadesi bir komut dizisi değildir. Ayrıca, bu ifade bir notasyon ve kurallar bütününü temsil eder.

Açıkçası ben her yeni projeye başlarken eğer farklı platformlar konuşacaksa mutlaka bu yapıyı tercih ederim.

Nedeni çok açık: Windows’ta yazıp Linux’ta okuyabilir, Java dili ile üretip Python ile tüketebilirsiniz. İşte bu platform bağımsız karakter Extensible Markup Language felsefesinin temel taşıdır.

XML Tanımı: Veriyi Yapılandıran Meta Dil

Şimdi işin biraz daha teknik kısmına dalalım. XML bir veri taşıma formatı olmanın çok ötesinde bir meta dildir.

Bunu şöyle açıklayayım: Nasıl ki bir dilbilgisi kitabı cümlelerin nasıl kurulacağını anlatır. Aynı şekilde bu standart da verilerin nasıl işaretleneceğinin kurallarını belirler.

Bu tanımı yaparken aklınızda bir ağaç yapısını hayal edin. Her şey bir kök eleman ile başlar. Bunun yanı sıra dallar buradan aşağıya doğru katmanlı bir düzende yer alır. Bu sayede karmaşık ilişkisel veriler bile son derece anlaşılır metin tabanlı bir forma dönüşür.

Metin tabanlı olması en büyük avantajlarından biridir. Çünkü herhangi bir hex editöre ihtiyaç duymadan not defterinde bile dosyanın içeriğini anlayabilirsiniz.

Bu durum insan tarafından okunabilir olma iddiasını fazlasıyla karşılar. Fakat dikkat edin, bu kolaylık beraberinde katı söz dizimi kurallarını getirir. Örneğin HTML’de bazı etiketleri kapatmayı unutsanız da tarayıcı sizi idare eder.

XML dünyasında ufak bir geçersiz karakter hatası veya kapatılmamış etiket, tüm belge işlemesini durdurur. Bu durum başta sinir bozucu gelse de veri bütünlüğü için etkili bir kalkandır.

Yıllar önce bir projede yüz binlerce satırlık XML çıktısını ayrıştırıyordum. Tek bir eksik tırnak işareti yüzünden saatlerce uğraşmak zorunda kaldım.

O gün anladım ki XML tanımı sadece bir format değil, aynı zamanda bir disiplin işidir. O yüzden bu yapıyı kullanmak demek, veri hijyenine önem vermek demektir.

XML’in Tarihçesi: SGML Alt Kümesinden W3C Standardına

Gelin biraz da nostalji yapıp takvimleri 1990’ların ortalarına saralım.

O dönemde web yeni yeni yaygınlaşıyordu. HTML’in karmaşık verileri göstermekte yetersiz kaldığı apaçık ortadaydı. İşte tam bu noktada W3C standardı olarak XML sahneye çıktı ve dijital dünyanın kaderini değiştirdi.

Yeni doğan bebeğin atası, karmaşık bir SGML alt kümesiydi. Bu yapı oldukça ağırdı. Standart Genelleştirilmiş İşaretleme Dili o kadar detaylıydı ki tam anlamıyla uygulamak pratikte imkansıza yakındı.

XML, bu büyük standartın yaklaşık %20’lik bölümünü aldı. Geriye kalan %80’lik karmaşayı ise dışarıda bıraktı.

Strateji son derece zekiceydi. Hedef web üzerinde veri alışverişi yapmayı kolaylaştırmaktı ve bu hedefe tam isabetle ulaştılar.

1998’de W3C tarafından resmi tavsiye olarak yayınlanmasıyla birlikte sektörde dev bir dönüşüm rüzgarı esti. Microsoft, Sun Microsystems ve IBM gibi devler bu standardı hemen benimsedi.

Doğal olarak insanlar, o günden bugüne bu teknolojiyi defalarca ‘öldü’ ilan ettiler. Ancak teknoloji, her seferinde yeni ihtiyaçlarla yeniden dirildi. Bana sorarsanız bu ölümsüzlüğün sırrı sadeliğinde ve katı kurallarındadır.

Üstelik 2026 itibarıyla finans ve sağlık sektöründeki regülasyonlar hala bu formata sıkı sıkıya bağlı.

Siz istediğiniz kadar JSON ile modern uygulamalar yazın. Bankalar arasındaki transferler ISO 20022 ile bu eski dost sayesinde gerçekleşiyor. Bu da bize tarihçenin ne kadar güçlü köklere sahip olduğunu gösteriyor.

XML’in Temel Felsefesi: İnsan Tarafından Okunabilir, Makine Tarafından İşlenebilir

Bu yapının yaratıcıları tasarım aşamasında oturup çok temel bir ikilemi çözmeye çalıştılar. Veri, yazılımcıların kolayca okuyabileceği kadar sade olmalıydı.

Ayrıca bilgisayarların saniyeler içinde işleyebileceği bir standartta kalmalıydı. İşte bu dengeye insan tarafından okunabilir ve makine tarafından okunabilir olma prensibi diyoruz.

Aslında bu felsefe sayesinde XML debug işlemleri inanılmaz kolaylaşır. Bir API’dan dönen cevabı not defterinde açıp bakmak, karmaşık binary bloklarla uğraşmaktan katbekat hızlıdır. Elbette bu okunabilirlik bir bedel karşılığında gelir: Fazladan etiketler yüzünden dosya boyutu şişer.

Aradan geçen yıllar gösterdi ki maliyetler düştü. Bu düşüş sayesinde şişkinliği artık görmezden gelebiliriz. Öte yandan veri transferi sırasında karşılaşılan belirsizliklerin sıfıra inmesi paha biçilemez bir kazanımdır. Ben şahsen sunucu loglarını incelerken hata ayıklamanın bu kadar basit olmasını hep takdir etmişimdir.

Bu noktada şunu da eklemek isterim: Unicode desteği sayesinde nerede olursanız olun, Çince karakterler veya Kiril alfabesi kullanın, sorun yaşamazsınız. Bu özellik onu küresel bir standart haline getiren en önemli yapı taşlarından biridir.

Günün sonunda bu felsefe bize şunu söyler: Veri siyah bir kutu olmamalıdır. Açıp baktığınızda ne olduğunu anlarsınız. Bu, özellikle büyük veri aktarımı projelerinde hayat kurtarır. Bu araç yıllar sonra bile vazgeçilmezdir. Bunun sırrı tam da bu şeffaflıktır.

XML Ne İşe Yarar? En Yaygın Kullanım Alanları

Artık temelleri attığımıza göre gelin bu teorik bilgilerin gerçek dünyada hangi problemleri çözdüğüne odaklanalım.

Bu aracı anlamak demek aslında modern yazılım mimarisinin gizli kahramanını tanımak demektir. Çünkü kullanıcı arayüzlerinin o şık butonlarının arkasında sessiz sedasız çalışan bir işçi arı gibidir.

Yeni mezun arkadaşlarım “Bu kadar eski teknoloji ne işe yarar?” diye soruyor. Gülümseyerek e-ticaretten finansa, SEO’dan devlet entegrasyonlarına uzanan bir liste sayıyorum. Gözlerindeki şaşkınlık beni hep keyiflendirir.

Şimdi sizlerle bu kullanım alanlarını detaylı bir şekilde masaya yatıracağız. Ama şimdiden söyleyeyim, burada anlatacaklarım sadece klasik ders kitabı bilgileri değil. Bizzat sahada ter dökmüş bir mühendis olarak karşılaştığım en kritik senaryoları sizlerle paylaşacağım.

Platform Bağımsız Veri Alışverişi ve Veri Transferi

Günümüz teknoloji dünyasının en büyük sancısı hiç kuşkusuz ki heterojen sistemlerin birbiriyle konuşma zorunluluğudur. Eski bir IBM mainframe bir yanda durur. Diğer yanda ise bulutta çalışan modern bir mikroservis vardır.

Bu iki uç sistemin birbiriyle konuşması teknoloji dünyasının önemli bir sorunudur. İşte böyle bir ortamda veri alışverişi için ortak bir paydaya ihtiyaç duyarsınız.

XML tam olarak bu ortak paydayı sağlar. Dosyanın içeriğine baktığınızda onu hangi programlama dilinin ürettiğini veya hangi işletim sisteminde çalıştığını anlayamazsınız.

Bu bilinmezlik bir hata değil, bilakis en büyük lütuftur. Zira bu sayede uygulamalarınızı birbirine sıkı sıkıya bağlamaktan kurtulursunuz.

Örneğin diyelim ki bir üretim bandındaki sensör verilerini bir veri tabanına yazmak istiyorsunuz. Sensörün firmware’i C ile yazılmıştır ama sunucunuz Java çalıştırır.

Araya bir metin tabanlı veri paketi koyduğunuzda iki taraf da işini kusursuz yapar. Bu esneklik size inanılmaz bir mimari özgürlük tanır.

Ne var ki bu kadar esnek olması bazen performans kaygılarını da beraberinde getirir. Özellikle gigabyte’larca veri aktarımı yapıyorsanız etiketlerin yarattığı ek yükü hissetmeye başlarsınız. Veri bütünlüğü hızdan önemliyse, bu araç rakipsizdir. Finans ve sağlık sektöründe durum kesinlikle böyledir.

Benim geçmişte yaşadığım bir tecrübeyi paylaşayım: Eski bir Cobol sisteminden modern bir ERP’ye fatura aktarımı yapıyorduk. Araya koyduğumuz dönüşüm katmanı sayesinde bu legacy sistem hiç dokunulmadan yıllarca çalışmaya devam etti. İşte veri saklama ve transfer için bu güvenilirliği neden bu kadar sevdiğimi anlayın artık.

Web Servisleri: SOAP API ve REST API ile XML Kullanımı

Web servisleri denince akla ilk gelen iki dev rakip vardır: SOAP ve REST. Birçok modern geliştirici REST API ve JSON kullanır. Ancak SOAP API hala kurumsal dünyanın merkezinde yer alır. Ve tahmin edeceğiniz üzere SOAP tamamen bu işaretleme dilinin omuzlarında yükselir.

SOAP ile REST arasındaki farkı bir kargo şirketi üzerinden anlatalım. REST API esnek bir motorsikletli kurye gibidir; hafiftir, hızlıdır ve paketi alıp götürür. SOAP ise zırhlı bir araçtır; ağırdır, çok fazla evrak ister ama içindeki yükün güvenliğinden asla şüphe etmezsiniz.

Bu güvenlik ve standart takıntısı özellikle bankacılık işlemlerinde kendini gösterir. Bir para transferi yaparken araya sıkı bir zarf (SOAP Envelope) girer. Fakat bu zarfın içinde mutlaka bir XML belgesi vardır.

REST API ise genelde daha hızlı prototipler için tercih ederiz. Fakat verinin yapısı karmaşıklaştıkça JSON yetersiz kalmaya başlar.

Aslında REST mimarisi de isterseniz size XML formatında cevap dönebilir. Yani bu iki teknoloji birbirinin alternatifi olmaktan ziyade farklı ihtiyaçlara hizmet eden araçlardır.

Ancak SOAP API kullanıyorsanız kaçışınız yoktur; bu yapının inceliklerine hakim olmak zorundasınız.

Mesela bir WSDL dosyasını açıp okumak ilk başta gözünüzü korkutabilir. Dosya size servisin sunduğu metodları, kullandığı ad alanını ve parametreleri eksiksiz açıklar. Bu dili bilmek, web servisleri dünyasında kaybolmamak için şarttır.

Özellikle büyük kurumsal firmalarla entegrasyon yaparken hala size “Endpoint adresinize SOAP zarfı göndereceğiz” dediklerini duyacaksınız. İşte o an bu satırları okuduğunuza sevineceksiniz.

E-Ticaret Entegrasyonu, XML Bayilik Dosyası ve Stoksuz Satış

Eğer bir e-ticaret siteniz varsa ya da ileride olmasını planlıyorsanız bu bölüm tam size göre. Özellikle stoksuz satış yani dropshipping yapan girişimciler için XML hayatın ta kendisidir. Çünkü tedarikçilerle aramızdaki ürün bilgisi köprüsünü bu teknoloji kurar.

Diyelim ki yüzlerce farklı toptancıdan ürün çekip kendi sitenizde satıyorsunuz. Her tedarikçi size Excel dosyası gönderse işin içinden çıkamazsınız.

Standart bir XML bayilik dosyası formatı hazırlayın. Bu sayede dosyayı ister Trendyol’a, ister kendi sisteminize sorunsuzca ekleyebilirsiniz. Haliyle tüm süreçleriniz tıkır tıkır işler.

Benzer bir senaryoda bir müşterimin binlerce ürününü güncellemek için cron job yazmıştık. Tedarikçinin gönderdiği devasa ürün listesini çözümlüyorduk. Ardından stok ve fiyat bilgilerini otomatik olarak veri tabanına işliyorduk. Veri düzensiz bir CSV veya TXT olsaydı, işler karışırdı. Haliyle bir sütun kayması bütün fiyatları alt üst edebilirdi.

İşte tam burada hiyerarşik yapı imdadımıza yetişir. Ürünün kodu, adı, fiyatı, kategorisi ve varyantları ağaç yapısı içerisinde birbirinden keskin çizgilerle ayrılır. Böylece hangi alanın ne anlama geldiğini tahmin etmeye çalışarak vakit kaybetmezsiniz.

Ayrıca bu entegrasyonlar sırasında karşılaşılan en büyük sorun karakter kodlamalarıdır.Tedarikçiler bazen dosyaları farklı bir biçimde gönderir. Haliyle Türkçe karakterler bozulma olur. Sonuç olarak ürün isimlerini hatalı görürsünüz. Bu yüzden her zaman UTF-8 kodlaması kullanmak için ısrar edin.

Netice itibarıyla e-ticaret entegrasyonu işi ciddiye alınması gereken bir disiplindir. Siz eğer bu standartla konuşmayı öğrenirseniz, istediğiniz kadar farklı tedarikçiyi sitenize bağlarsınız. İnanın bana bu yetenek sizi rakiplerinizin bir adım önüne geçirecektir.

Site Haritası (Sitemap.xml) ve RSS Beslemesi ile SEO

Şimdi işin bir de SEO boyutuna bakalım. Web siteniz ne kadar kaliteli içerik üretirse üretsin, eğer arama motorları sayfalarınızı tarayamıyorsa yok hükmündesiniz.

İşte burada site haritası dediğimiz sitemap.xml dosyasını oluşturmak sizin için bir tercih değil, zorunluluktur.

Bu dosyayı oluşturma adımları oldukça basittir:

1. Öncelikle sitenizdeki tüm önemli URL’leri bir liste halinde toplayın.
2. Bu listeyi W3C’nin belirlediği protokol formatına uygun bir şekilde etiketleyin.
3. Oluşturduğunuz dosyayı sunucunuzun kök dizinine yükleyin.
4. Google Search Console veya Bing Webmaster Tools üzerinden bu dosyanın adresini arama motorlarına bildirin.
5. Son olarak robots.txt dosyasına site haritasının konumunu ekleyin.

Kendi tecrübelerime göre, haber siteleri ve sık güncellenen bloglar için RSS beslemesi kritiktir. Aslında RSS de bir XML formatıdır. Kullanıcılarınız bu özellikle yeni yazıları anlık takip edebilir.

Bu iki uygulama sayesinde hem insanlara hem de botlara yol gösterirsiniz. Web sitesini devreye aldığımda ilk iş dinamik bir site haritası üreten script yazmaktır. Çünkü içerik arttıkça bu haritanın kendi kendini güncellemesi şarttır.

Unutmayın ki geçerli belge kurallarına uymayan bir site haritası arama motorları tarafından yok sayılır. Bu sebeple dosyanın iyi biçimlendirilmiş olmasına ve maksimum URL sınırını aşmamasına özen gösterin. Hatalı bir yapılandırma size fayda yerine zarar getirir.

Finansal Raporlama: XBRL ve Bankalararası Transferde ISO 20022

Gelelim işin en ciddi kısmına, yani paranın yönetildiği yere. Finans dünyası on yıllardır veri standardizasyonu için bu teknolojiyi kullanıyor. Özellikle XBRL (eXtensible Business Reporting Language) ve bankalararası transfer mesajlaşması için ISO 20022 standardı tamamen bu yapı üzerine inşa edilmiştir.

XBRL, şirketlerin finansal raporlarını analistlerin ve düzenleyici kurumların anlayabileceği ortak bir dille sunmasını sağlar. Artık şirket bilançolarını indirip Excel’de açmanıza gerek kalmaz. Dolayısıyla bu akıllı veri paketini okuyan bir yazılım, anında karşılaştırmalı analizler yapar.

ISO 20022 ise bankacılıkta devrim yaratan bir adımdır. Eski nesil SWIFT MT mesajlarının aksine bu yeni standart çok daha fazla bilgi taşıyabilir. Bir ödeme emri, tutar ve IBAN’dan fazlasını sunar. Buna ek olarak, fatura detayları, vergi numaraları ve gönderici mesajları da içerir.

Bu sistemlerin çalışma mantığı şöyledir: Devasa bir XML şeması oluşturursunuz. Bu şema, her alanın uzunluğunu belirler. Ayrıca, alanın hangi veri tipini kabul ettiğini gösterir. Bununla birlikte, alanın zorunlu olup olmadığını da belirtir.

EFT yaptığınızda banka, kurallara uygun bir XML dosyası hazırlar. Ardından bu dosyayı karşı bankaya iletir.

Her ne kadar kullanıcılar bunu görmese de finansal raporlama ve ödeme sistemlerinin bel kemiği budur. Bu yüzden, bu alanda çalışan bir yazılım geliştiricisiyseniz, büyük bir fırsat yakalayabilirsiniz. Şöyle ki, XPath ve XSLT gibi teknolojileri bilmeniz size ciddi bir kariyer avantajı sunar.

Kısacası konu para olduğunda, kimse hata payını kabul etmez. Sistem fatura tutarını yanlış okuyamaz. Ayrıca IBAN bilgisini hatalı ayrıştıramaz; yani bunları kabul edemeyiz. Bu güven ortamını sağlayan şey de katı şema doğrulama mekanizmalarıdır.

XML ve HTML Farkı: Birbirine Karıştırılan İki İşaretleme Dili

Şimdi en sık kafa karıştıran konuya el atalım. Bu iki dilin adı ve köşeli parantez kullanımı benzerdir ancak amaçları tamamen farklıdır. Birini diğerinin yerine kullanmak ciddi hatalara yol açar. Gelin bu iki akraba teknolojiyi masaya yatıralım ve keskin çizgilerle ayıralım.

Veri Sunumu (HTML) ve Veri Tanımı (XML) Ayrımı

HTML’in tek derdi vardır: İçeriği tarayıcıda nasıl göstereceğini tarif etmek. Mesela bir metni kalın yapmak için <b> etiketini kullanır. Bu bir sunum komutudur. Oysa ki bu yapı içerik hakkında hiçbir şey söylemez; sadece orada bir metin olduğunu ve bu metnin kalın gösterilmesi gerektiğini söyler.

Buna karşılık bu işaretleme dili içeriğin ne olduğunu tanımlar. Örneğin <fiyat>19.99</fiyat> yazdığınızda bu verinin bir fiyat bilgisi olduğunu hem insana hem de makineye ilan etmiş olursunuz. Yazılımınız bu veriyi alıp bir grafikte kullanabilir veya bir veri tabanına yazabilir.

XML ve HTML arasındaki fark işte bu noktada ortaya çıkar. HTML sunumu, XML ise anlamı temsil eder. Eski günlerde web sitelerini sadece HTML ile yapıyorduk ama veriyi yönetmek imkansızdı. Şimdi ise veri katmanını bu yapı ile yönetip HTML ile şık bir şekilde paketliyoruz.

Geliştiriciler veriyi bu yapıdan alıp XSLT ile HTML’e çevirmeyi sıkça tercih ederler. Bu sayede aynı veri farklı cihazlar için farklı sunumlara adapte edilebiliyordu. Açıkçası bu yaklaşım bana her zaman çok zekice gelmiştir.

Etiket Yapısı: Sabit ve Özel Etiketler

HTML’de kullanabileceğiniz kelimeleri W3C önceden belirler. <h1>, <p>, <div> gibi sınırlı bir evrenin içinde yaşarsınız. Yeni bir etiket uydurmaya kalkarsanız tarayıcılar bunu görmezden gelir veya beklemediğiniz sonuçlar doğurur.

Fakat bu esnek yapıda durum çok daha özgürlükçüdür. Siz kendi iş alanınıza uygun istediğiniz etiketi oluşturabilirsiniz. Bir emlak uygulaması için <oda_sayisi> veya bir hastane otomasyonu için <tahlil_sonucu> etiketleri tamamen size özeldir.

Bu özgürlük sayesinde XML son derece semantik bir hale gelir. Dosyayı açan bir yabancı bile etiket adlarına bakarak verinin neyle ilgili olduğunu anlayabilir. Bu durum özellikle takım çalışmalarında ve büyük projelerde dokümantasyon ihtiyacını azaltır.

Ne var ki bu esneklik disiplini de beraberinde getirmelidir. Özel etiketlerinizi bir XML Şeması ile belgelemezseniz. Altı ay sonra projeye döndüğünüzde hangi etiketin ne işe yaradığını unutabilirsiniz. O yüzden ben her zaman şema tanımlamayı birinci öncelik olarak görürüm.

Büyük-Küçük Harf Duyarlılığı ve Söz Dizimi Katılığı

HTML yazarken <Body> ile <BODY> arasında tarayıcı açısından hiçbir fark yoktur. Hepsi aynı kapıya çıkar ve sayfayı render eder. Bu hoşgörü yeni başlayanlar için bir nimettir. Ancak profesyonel yazılım geliştirme pratiklerine terstir.

XML ise bu konuda son derece titizdir. Eğer bir elemanı <Kitap> olarak açtıysanız onu </kitap> olarak kapatamazsınız. Büyük ve küçük harf ayrımı başta sinir bozar. Açıkçası bu hassasiyet, hata payını sıfıra indirir.

Bu katılık sayesinde iyi biçimlendirilmiş bir belge elde ederiz. Bir ayrıştırıcı dosyayı okurken kararsızlık yaşamaz. Binlerce satırlık dosyada bu kesinlik sayesinde hata ayıklama sürenizi yarıya indirirsiniz. Yani işiniz çok kolaylaşır.

Aynı şekilde öznitelik değerlerini de mutlaka tırnak içinde yazmalısınız. HTML’de bazı tarayıcılar tırnaksız değerleri affedebilir. Ama burada affetmek diye bir şey yoktur; hata alırsınız ve işlem durur. Bu sebeple bir XML editörü kullanmak hataları anında görmenizi sağlar.

Ben şahsen bu katı kuralları bir tür kalite kontrol mekanizması olarak görüyorum. Eğer dosyanız parse ediliyorsa içiniz rahat olsun, veri yapısı sağlamdır. Eğer hata alıyorsanız da bilin ki sorun veride değil, formatın kurallarına uymamanızdadır.

Boşluk Karakterleri ve Kapanış Zorunluluğu Açısından Karşılaştırma

HTML render motorları genellikle ardışık boşlukları tek bir boşluk olarak yorumlar. Yani siz kaynak kodda ne kadar enter basarsanız basın sayfanın görünümü değişmez. Bu durum kod yazımını kolaylaştırsa da veri taşıma söz konusu olduğunda baş belasıdır.

Bu format, boşluk karakterlerini kendiliğinden korur. xml:space="preserve" gibi bir öznitelik ile bu davranışı kontrol edebilirsiniz. Özellikle şiir veya kod bloğu gibi girintili metinlerde, bu yöntem hayat kurtarır.

Kapanış etiketleri konusuna gelirsek bu en belirleyici farktır. HTML’de bir <li> maddesini kapatmadan yenisini açsanız da liste görünmeye devam eder.

Ama bu dilde her açılan etiket mutlaka kapanmak zorundadır. Bu kuralın istisnası sadece kendiliğinden kapanan etiketlerdir (Örn: <bos_etiket />).

Bu katılık, hiyerarşik yapıyı daima korur. Hangi elemanın hangi elemanın içinde olduğu kesin olarak bellidir. Bu netlik veri işleme kütüphanelerinin (parser) işini son derece kolaylaştırır.

Dosyanız açılmıyorsa önce şu iki noktayı kontrol edin: Etiketi kapatmış mısınız? Yapı iç içe doğru geçmiş mi? Söz konusu bu aracı kullanmak olduğunda tembelliğe yer yoktur.

XML Dosyası Nasıl Açılır ve Oluşturulur?

Teori tamam da pratikte bu işi nasıl halledeceğiz? Dosyayı açmak için illa pahalı programlara mı ihtiyacımız var? Yoksa basit bir not defteri iş görür mü? Gelin bu soruların cevaplarını uygulamalı olarak inceleyelim.

XML Dosyası Açma: En İyi XML Editörleri ve Tarayıcılar

Herhangi bir dosyayı görüntülemenin en hızlı yolu modern bir web tarayıcısı kullanmaktır. Dosyayı Chrome, Firefox veya Edge’e sürükleyin. Tarayıcı size renklendirilmiş, katlanabilir bir ağaç yapısı gösterir. Bu yöntem hızlı bir göz atmak için birebirdir.

Fakat iş düzenleme ve doğrulamaya gelince işler değişir. Dosyayı Not Defteri ile açabilirsiniz. Ancak bu yöntem hataya çok açıktır. Benim favori araçlarım arasında şunlar yer alır:

• Notepad++ (Ücretsiz): XML Tools eklentisi ile formatlama ve XPath sorgulama yapabilirsiniz.
• VS Code (Ücretsiz): Red Hat XML eklentisi ile otomatik tamamlama ve şema doğrulama alırsınız.
• Oxygen XML Editor (Ücretli): Özellikle XSLT dönüşümleri ve devasa dosyalar için biçilmiş kaftandır.
• Altova XMLSpy (Ücretli): Kurumsal dünyada en çok karşılaşacağınız editördür.

Ben şahsen günlük işlerimde VS Code’u tercih ediyorum. Ücretsiz olması ve inanılmaz hızlı çalışması beni kendine bağladı. Ancak ciddi finansal raporlar veya karmaşık şema dönüşümleri yapıyorsanız, mutlaka daha profesyonel bir araç kullanın. Bu gibi yoğun işler için Oxygen gibi profesyonel çözümleri şiddetle öneririm.

Adım Adım XML Dosyası Oluşturma Rehberi

Hadi şimdi birlikte sıfırdan bir dosya oluşturalım. Çok karmaşık bir şey değil, sadece bir arkadaş listenizi tutacak basit bir yapı kuracağız. Adımları takip edin:

1. Editörü Açın: Masaüstünüzde boş bir metin belgesi oluşturun ve adını arkadaslar.xml olarak değiştirin.
2. Bildirim Satırını Ekleyin: Dosyanın en başına <?xml version="1.0" encoding="UTF-8"?> yazın. Bu satır ayrıştırıcıya hangi sürümü ve hangi karakter setini kullanacağını söyler.
3. Kök Elemanı Tanımlayın: Hemen alt satıra <liste> yazın ve bir alt satırda kapatmayı unutmayın: </liste>. Diğer tüm veriler bu iki etiketin arasına girecek.
4. Alt Elemanları Ekleyin: <kisi> etiketi ile bir kayıt başlatın. İçerisine <ad>, <soyad> ve <yas> gibi alanlar koyun.
5. Dosyayı Kaydedin: Değişiklikleri kaydedin ve tarayıcınızla açıp test edin.

Eğer her şey yolunda gittiyse tarayıcıda iç içe geçmiş renkli bir yapı görmelisiniz. Eğer bir hata mesajı aldıysanız, muhtemelen bir yerde tırnak işaretini eksik bırakmışsınız demektir. Bu adımları takip ederek XML dosyası oluşturma işlemini başarıyla tamamlamış olursunuz.

XML Formatı ve Temel Söz Dizimi Kuralları

Bu dili kullanırken asla çiğnememeniz gereken bazı altın kurallar vardır. Bu kuralları bir liste halinde sıralayalım:

• Tek Kök Eleman: Bir belgede her şeyi kapsayan sadece bir tane kök eleman bulunabilir. Birden fazla olamaz.
• Düzgün İç İçe Geçiş: Etiketler asla çaprazlama kapanmamalıdır. Doğru: <a><b></b></a> — Yanlış: <a><b></a></b>.
• Öznitelik Değerleri Tırnak İçinde: Tek tırnak (‘) veya çift tırnak (“) kullanabilirsiniz ama kararlı olun.
• Özel Karakterleri Kaçırın: < işareti yerine <, & işareti yerine & yazmalısınız.
• Yorum Satırları: Tıpkı HTML’deki gibi <!-- Bu bir yorumdur --> şeklinde yazılır.

Bu kurallar ilk başta kısıtlayıcı görünse de aslında sizi büyük facialardan korur. Özellikle özel karakterleri kaçırmayı unutmak en sık karşılaşılan acemiliklerdendir. Bu kurallara uyarsanız, dosyanızı her yerde sorunsuz açarsınız.

UTF-8 Kodlaması ve BOM İşareti: Karakter Hatalarının Önüne Geçmek

Gelelim işin en çok baş ağrıtan kısmına. Dosyanızı oluşturdunuz. Her şey mükemmel görünüyor. Ancak bir türlü parse edemiyorsunuz. Hata mesajı “Content is not allowed in prolog” gibi anlamsız bir şey söylüyor. İşte bu noktada büyük ihtimalle suçlu BOM işareti (Byte Order Mark) adlı görünmez bir düşmandır.

BOM, dosyanın başında bulunan ve metnin hangi byte sıralamasıyla yazıldığını belirten birkaç byte’lık bir veridir. Bazı editörler (özellikle Windows Not Defteri) dosyayı UTF-8 olarak kaydederken bu işareti ekler. Fakat birçok XML ayrıştırıcı bu beklenmedik karakteri gördüğünde çıldırır.

Çözüm çok basittir: Dosyanızı kaydederken mutlaka UTF-8 without BOM seçeneğini kullanın. Ben tüm projelerimde bu kuralı bir standart haline getirdim. Ayrıca versiyon kontrol sistemine (Git) göndermeden önce dosyaları bu açıdan kontrol eden bir script çalıştırırım.

Bunun yanı sıra farklı dillerden gelen içeriklerle çalışıyorsanız doğru karakter kodlaması şarttır. Türkçe’deki ‘ı’, ‘ş’, ‘ğ’ gibi harfler yanlış encoding yüzünden bozulursa veri okunamaz hale gelir. Bu sebeple her zaman başlangıç etiketinde encoding="UTF-8" ibaresini görmeyi beklerim.

Sık sık hata alıyorsanız, gelişmiş bir düzenleyici kullanın. Ardından, dosya biçimini sağ alt köşeden kontrol edin. Bu basit alışkanlık size saatler kazandıracaktır.

XML Örnekleri ve İyi Biçimlendirilmiş (Well-Formed) Belge Yapısı

Biraz da elinizi kirletip somut kod parçacıklarına bakalım. Soyut kuralları okumak güzeldir ama gerçek öğrenme kod yazarken gerçekleşir. Şimdi size birkaç XML örnekleri sunacağım ve hangisinin neden doğru veya yanlış olduğunu açıklayacağım.

Basit Bir XML Örneği: Kitap Listesi

Aşağıda bir kitap koleksiyonunu temsil eden son derece sade bir yapı görüyorsunuz. Bu yapıda her bir <kitap> elemanı kendi içerisinde ad, yazar ve yıl bilgilerini barındırır. Bu temel yapıyı anladığınızda gerisi çorap söküğü gibi gelecektir.

<?xml version="1.0" encoding="UTF-8"?>
<kutuphane>
  <kitap>
    <ad>Suç ve Ceza</ad>
    <yazar>Fyodor Dostoyevski</yazar>
    <yil>1866</yil>
  </kitap>
  <kitap>
    <ad>İnce Memed</ad>
    <yazar>Yaşar Kemal</yazar>
    <yil>1955</yil>
  </kitap>
</kutuphane>

Buradaki <kutuphane> bizim kök elemanımızdır. Gördüğünüz gibi etiketler tamamen anlamlıdır ve veri hakkında fikir verir. Bu dosyayı bir API’dan döndüğünüzü düşünün; yazılımınız kolayca kitapların üzerinde dönüp listeyi işleyebilir.

Dikkat ettiyseniz girintileme (indentation) kullandık. Bu girintiler zorunlu değildir. Yine de dosyanın insanlarca okunmasını kolaylaştırır. Ayrıştırıcı bu boşlukları görmezden gelir veya kurallara göre işler.

Öznitelik Kullanımına Dair XML Örnekleri

Veriyi saklamanın bir diğer yolu da öznitelik kullanmaktır. Yukarıdaki kitap listesini özniteliklerle şu şekilde de yazabilirdik:

<kutuphane>
  <kitap ad="Suç ve Ceza" yazar="Dostoyevski" yil="1866" />
  <kitap ad="İnce Memed" yazar="Yaşar Kemal" yil="1955" />
</kutuphane>

Bu kullanım çok daha kompakt görünür ve dosya boyutunu küçültür. Peki hangisini tercih etmeli? Bu sorunun net bir cevabı yoktur.

Benim şahsi kuralım şudur: Veri gelecekte karmaşıklaşırsa, örneğin bir yazarın çok sayıda kitabı olursa, öğe kullanırım. Basit anahtar-değer ikilileri için öznitelik yeterlidir.

Bu karşılaştırmayı yaparken aklınızda bulunsun: Öznitelik değerleri her zaman metin olarak saklanır ve içlerinde etiket bulunduramazsınız. Bu sebeple uzun açıklamalar veya zengin metin içerikleri için asla öznitelik kullanmayın.

İyi Biçimlendirilmiş (Well-Formed) ve Geçerli (Valid) XML Arasındaki Fark

Bu iki terim sıklıkla birbirine karıştırılır ama aralarında dağlar kadar fark vardır. İyi biçimlendirilmiş bir belge sadece söz dizimi kurallarına uyar. Yani etiketleri düzgün kapatırsınız. Ayrıca belgede tek bir kök bulunur ve sistem özel karakterleri doğru işler.

Geçerli belge olmak ise bir adım ötesidir. Bu durumda belgenin belirli bir şemaya (DTD veya XSD) uygun olması gerekir. Mesela şemanız <yil> etiketinin içinde sadece sayısal değer olabileceğini söylüyorsa, siz oraya “Bin Sekiz Yüz” yazamazsınız.

Pratik hayatta şöyle düşünebilirsiniz: İyi biçimlendirilmiş olmak bir arabanın tekerleklerinin yerinde olması gibidir. Geçerli olmak ise o arabanın motorunun çalışıp viteslerinin düzgün olmasıdır. İkisi bir arada olmazsa yol alamazsınız.

Sık Yapılan Geçersiz Karakter Hataları ve Çözümleri

Yeni başlayanların en çok takıldığı nokta budur. Aşağıdaki listeyi bir kenara not edin, inanın hayat kurtarır:

• & işareti: Tek başına kullanamazsınız. & şeklinde yazmalısınız.
• < işareti: Sistem bu işareti etiket başlangıcı olarak algılar; bu yüzden < ifadesini kullanmalısınız. < kullanın.
• > işareti: Zorunlu değildir ama tutarlılık için > tercih edebilirsiniz.
• Çift Tırnak: Öznitelik içinde kullanılacaksa " yapabilirsiniz.
• Kontrol Karakterleri: ASCII’nin ilk 31 karakteri (NULL, BEL, vb.) kesinlikle yasaktır.

Bu geçersiz karakter hatası ile karşılaştığınızda dosyayı hex modunda açıp bakmak bazen tek çaredir. Özellikle kullanıcıların formlardan girdiği metinleri taşırken bu tip sorunlarla mutlaka karşılaşırsınız.

Benim tavsiyem, veriyi XML’e yazmadan önce mutlaka bir temizleme fonksiyonundan geçirmenizdir.

XML Şeması (XSD), DTD ve Ad Alanı (Namespace) Kavramları

Şimdi işler biraz daha derinleşiyor. Artık sadece veriyi yazmayı değil, o verinin nasıl olması gerektiğini tarif etmeyi de öğreneceğiz. İşte sizi sıradan bir kullanıcı olmaktan çıkarıp gerçek bir mimar seviyesine taşıyacak.

DTD (Document Type Definition) Nedir?

DTD bu işin dedesidir. SGML alt kümesi günlerinden beri hayatımızdadır. Amacı bir belgenin içerebileceği elemanları, onların sıralamasını ve hangi öznitelikleri alabileceğini tanımlamaktır. Söz dizimi XML’e benzemez, kendine has bir yapısı vardır.

Bir DTD örneği şöyle görünür: <!ELEMENT kutuphane (kitap+)>. Bu ifade bize kütüphane elemanının içinde bir veya daha fazla kitap olması gerektiğini söyler. Basit projeler için hala kullanışlı olsa da DTD’nin ciddi kısıtları vardır.

Öncelikle DTD veri tiplerini desteklemez. Bir alanın sayı mı yoksa metin mi olduğunu söyleyemezsiniz. Ayrıca ad alanı desteği yoktur.

Bu yüzden modern projelerde neredeyse tamamen yerini XML Şeması yani XSD’ye bırakmıştır. Yine de eski sistem entegrasyonu yaparken karşınıza çıkma ihtimali yüksektir.

Ben şahsen yeni bir projeye başlarken asla DTD tercih etmem. Onun yerine XSD’nin sunduğu zengin tip kütüphanesini kullanırım. Yine de eski web servislerini kullanıyorsanız, WSDL içinde mutlaka bir DTD referansı görürsünüz.

XML Şeması (XSD) ile Gelişmiş Doğrulama

XSD, DTD’nin tüm eksiklerini kapatmak için W3C tarafından geliştirilmiş modern bir dildir. En büyük avantajı kendisinin de bir XML belgesi olmasıdır. Yani XSD dosyalarını da aynı ayrıştırıcılar ile okuyup işleyebilirsiniz.

XSD ile bir alanın tam olarak integer, decimal, date veya string olduğunu belirtebilirsiniz. Hatta düzenli ifadeler (regex) kullanarak metin formatını kısıtlayabilirsiniz. Örneğin, TC kimlik numarasını on bir haneli sayı yapmaya zorlamak oldukça kolaydır.

Bir XSD tanımına baktığınızda <xs:element name="yil" type="xs:gYear"/> gibi bir satır görürsünüz. Burada kullanılan xs ön eki bize bir ad alanı kullanıldığını gösterir. Bu sayede şema tanımındaki kelimeler ile sizin veri kelimeleriniz birbirine karışmaz.

Açıkçası benim için bir projenin olmazsa olmazı XSD’dir. Eğer entegrasyon yaptığınız karşı taraf size bir XSD vermiyorsa, bilin ki başınız ağrıyacak demektir. Çünkü verinin formatı hakkında sürekli mail trafiği yapmak zorunda kalırsınız.

Ad Alanı (Namespace) ile Çakışmaları Önleme

Büyük bir proje yaptığınızı hayal edin. Ayrıca, farklı bölümlerden gelen verileri tek bir çatı altında topluyorsunuz. Hem İnsan Kaynakları hem de Muhasebe departmanı <personel> adında bir eleman kullanıyor ama içerikleri farklı. İşte tam bu noktada ad alanı imdadımıza yetişir.

Namespace bir aile soyadı gibidir. Elemanın başına bir ön ek (prefix) getirerek onun hangi aileden geldiğini belirtirsiniz. Örneğin: <ik:personel> ve <muh:personel>. Bu iki eleman artık birbirinden tamamen bağımsızdır.

Namespace tanımı genellikle kök elemanda xmlns:ik="http://www.sirket.com/ik" şeklinde bir URL ile yapılır. Buradaki URL’nin gerçekten bir internet adresine işaret etmesi gerekmez; bu sadece benzersiz bir isim üretme yöntemidir.

Bu kavram özellikle SOAP API ve XSLT gibi ileri seviye konularda hayati önem taşır. Namespace’leri doğru yönetemezseniz XPath sorgularınız çalışmaz ve dönüşümleriniz patlar. O yüzden bu konuyu lütfen hafife almayın.

XSD Örneği ile Geçerli Bir XML Belgesi Nasıl Tanımlanır?

Hadi gelin yukarıdaki kitap listesi için basit bir XSD yazalım. Bu şema bize kitap elemanının bir sıra dahilinde ad, yazar ve yıl içermesi gerektiğini söyleyecek.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="kutuphane">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="kitap" maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="ad" type="xs:string"/>
              <xs:element name="yazar" type="xs:string"/>
              <xs:element name="yil" type="xs:gYear"/>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Bu kod bloğunu bir .xsd dosyasına kaydedip XML dosyanızı buna göre doğrularsanız, veri giriş hatalarının önüne geçersiniz. Bu sayede sisteminize çöp veri girmesini engellersiniz.

XML Ayrıştırıcı (Parser) Türleri: DOM & SAX Parser Farkları

Bir dosyayı okumak için kullandığımız yazılım bileşenlerine ayrıştırıcı (parser) diyoruz. Seçeceğiniz parser türü uygulamanızın performansını ve bellek tüketimini doğrudan etkiler. Yanlış bir seçim sunucunuzu çökertip sizi zor durumda bırakabilir.

DOM Parser: Bellekte Ağaç Yapısı Oluşturma

DOM (Document Object Model), dosyanın tamamını okuyup bellekte devasa bir ağaç yapısı oluşturur. Bu sayede dosya içerisinde ileri geri gezinebilir, eleman ekleyip çıkarabilir ve sürekli değişiklik yapabilirsiniz. Bir nevi belgenin zihinsel bir haritasını çıkarmak gibidir.

Bu yöntem küçük konfigürasyon dosyaları veya sık sık güncellenmesi gereken yapılar için mükemmeldir. Mesela bir ayarlar dosyasını okumak için DOM parser kullanmak çok mantıklıdır. Kod yazımı da diğer yöntemlere göre daha basittir.

Lakin DOM parser ile ilgili dev bir sorun vardır: Bellek tüketimi. Eğer 10 megabyte’lık bir dosyayı DOM ile açarsanız, bellek kullanımınız 50-60 megabyte’lara fırlayabilir. Yüzlerce megabyte’lık devasa log dosyaları veya veri aktarımı yapıyorsanız DOM kullanmak intihar etmekle eşdeğerdir.

SAX Parser: Olay Tabanlı ve Bellek Dostu Okuma

SAX (Simple API for XML) tamamen farklı bir yaklaşım benimser. Bu parser dosyayı satır satır okur ve bir etiketle karşılaştığında bir olay (event) fırlatır. Siz bu olayları yakalayıp gerekli işlemleri yaparsınız. Dosya okunduktan sonra bellekte hiçbir şey kalmaz.

Bu yöntemin en büyük artısı inanılmaz derecede hızlı ve bellek dostu olmasıdır. Dosya boyutu ne olursa olsun bellek kullanımınız neredeyse sabit kalır. Büyük veri aktarımı yaparken veya akış (stream) halinde gelen verileri işlerken SAX parser rakipsizdir.

Ne var ki SAX parser ile çalışmak daha zahmetlidir. Dosyada geriye dönüp bakamazsınız. Bir kere okuduğunuz veri geçip gider. Eğer veriyi düzenlemeniz veya farklı bölümleri arasında ilişki kurmanız gerekiyorsa SAX parser işinizi görmez.

StAX Parser: İki Dünyanın En İyisi mi?

Geliştiriciler, DOM’un basitliğini ve SAX’ın hızını birleştirmek için StAX (Streaming API for XML) yapısını oluşturdular. Bu araç sayesinde verileri bir akış olarak okuyabilir ve süreci tamamen siz yönetebilirsiniz. Siz next() metodunu çağırmadıkça parser bir sonraki elemana geçmez.

Bu sayede ihtiyacınız olmayan kısımları hızla atlayıp sadece ilgilendiğiniz veriyi okuyabilirsiniz. Ben şahsen modern Java projelerimde neredeyse her zaman StAX kullanırım. Performansı müthiştir ve kod karmaşıklığı SAX’a göre çok daha yönetilebilir seviyededir.

StAX parser adeta bir çekme (pull) mekanizmasıdır. SAX ise itme (push) mekanizmasıyla çalışır. Veriyi sizin çekmeniz, olayların size dayatılmasından her zaman daha kontrollü bir süreç yaratır. Eğer sık sık büyük dosyalarla uğraşıyorsanız StAX’a bir şans vermenizi tavsiye ederim.

Web servisleri aslında API’lar arası iletişim için standart bir yol sunuyor. Bu arayüzler sistemlerin birbirini anlamasını kolaylaştırıyor. SOAP ve REST bu konuşmanın dilini belirliyor. Net olmak gerekirse her iki yöntem de farklı ihtiyaçlara hizmet ediyor. Projenizin gereksinimlerine göre doğru tercihi yapmalısınız.

XML & JSON Karşılaştırması: Hangisi Daha İyi?

Bu soru yazılım dünyasında neredeyse emacs vs vi tartışması kadar eskidir. Her iki formatın da kendine göre fanatik destekçileri vardır. Ben tarafsız bir gözle artıları ve eksileri masaya yatıracağım.

Veri Boyutu, Okunabilirlik ve Performans Karşılaştırması

JSON şüphesiz ki daha az karakter kullanır. Kapanış etiketleri olmadığı için aynı veriyi çok daha kompakt bir şekilde ifade eder. Bu durum özellikle mobil uygulamalarda veya yavaş internet bağlantılarında JSON’u bir adım öne çıkarır.

Okunabilirlik açısından ise bu bir zevk meselesidir. JSON süslü parantezleri ve köşeli parantezleri ile JavaScript geliştiricilerine çok tanıdık gelir.

Ancak çok derin iç içe geçmiş yapılarda nerede olduğunuzu anlamak JSON’da daha zordur. XML’de ise kapanış etiketi size hangi objeden çıktığınızı net bir şekilde söyler.

Performans karşılaştırması yaptığım testlerde JSON parser’ların XML parser’lara göre yaklaşık %30 daha hızlı olduğunu gözlemledim. Bu fark özellikle saniyede binlerce istek alan sunucularda ciddi maliyet avantajı sağlar.

Sunucu tarafında sıkça XML üretmek veya tüketmek zorunda kalırsınız. PHP’nin DOM eklentisi bu iş için oldukça yetkindir. Büyük dosyalarla uğraşırken memory limitine dikkat edin. Küçük bir tüyo: XMLReader sınıfı düşük bellek kullanımı için hayat kurtarıcıdır. Özellikle veri aktarım işlerinde bu sınıfı kullanmanızı öneririm.

JSON’un Yetersiz Kaldığı Durumlar: XML’in Hala Tercih Edilme Sebepleri

Peki madem JSON bu kadar havalı, neden hâlâ bu eski dostu kullanıyoruz? Çünkü JSON’un ciddi handikapları vardır. En önemlisi JSON’da yorum satırı yazamazsınız. Bu özellikle konfigürasyon dosyası hazırlarken büyük bir eksikliktir.

Dahası, JSON şema doğrulamayı neredeyse hiç desteklemez. JSON Şema vardır; fakat geliştiriciler onu pek kullanmazlar. Verinin belli bir kalıba uyup uymadığını kontrol etmek için ekstra kod yazmak zorunda kalırsınız. Oysa ki bu dilde XSD ile veri doğrulama otomatiktir ve hatasızdır.

Ayrıca isim çakışmalarını önleyecek bir ad alanı mekanizması JSON’da yoktur. Bu yüzden büyük kurumsal entegrasyonlarda veri kirliliği yaşama ihtimaliniz yüksektir. İşte tam da bu sebeplerle JSON karşılaştırması yaparken sadece hıza bakarak karar vermemelisiniz.

JSON ve XML Arasında Dönüşüm Yöntemleri

Günümüzde her iki formatı da birbirine çevirmek oldukça kolaylaştı. Birçok programlama dili bu iş için hazır kütüphaneler sunar. İşte popüler yöntemler:

• Java: org.json kütüphanesi ile XML.toJSONObject() metodunu kullanabilirsiniz.
• Python: xmltodict modülü ile XML’i sözlüğe, oradan da JSON’a rahatça çevirirsiniz.
• JavaScript: Tarayıcıda DOMParser ile okuduğunuz veriyi manuel olarak bir JS objesine map edersiniz.
• Komut Satırı: yq veya xq gibi araçlarla terminalden direkt dönüşüm yapabilirsiniz.

Ancak burada bir uyarı yapmalıyım: Dönüşüm sırasında öznitelikler ve metin içerikleri arasındaki ayrım bulanıklaşabilir. Bu sebeple otomatik dönüştürücülere %100 güvenmeyin ve çıktıyı mutlaka kontrol edin.

XML Güvenliği: XXE Saldırısı (XML External Entity) ve Korunma Yöntemleri

Bu bölüme kadar hep faydalarından bahsettik. Şimdi işin karanlık yüzüne, yani güvenlik açıklarına göz atalım. Bu konuyu atlarsanız, bir gün sisteminizi hiç beklemediğiniz bir anda saldırganlar ele geçirebilir.

XXE Saldırısı Nedir ve Nasıl Çalışır?

XXE saldırısı (XML External Entity), eski veya yanlış yapılandırılmış ayrıştırıcıları hedef alan sinsi bir tekniktir. Saldırganlar, dosyaya özel bir DTD tanımı ekleyerek sunucunun yerel dosyalarını okuyabilirler. Hatta bu yöntemle, sunucunun dış ağlara istek yapmasını da sağlayabilirler.

Saldırının nasıl işlediğini şöyle düşünebilirsiniz: Diyelim ki bir kullanıcıdan profil resmi yerine XML dosyası yüklemesini istiyorsunuz. Saldırgan dosyanın içine <!ENTITY xxe SYSTEM "file:///etc/passwd"> yazar ve bu entity’i çağırır. Eğer parser güvenli değilse sunucu /etc/passwd dosyasını okuyup saldırgana geri gönderir.

Bu sadece dosya okumakla sınırlı değildir. Saldırganlar dış ağa istek göndererek SSRF (Server Side Request Forgery) saldırıları düzenleyebilirler. Üstelik, Milyar Kahkaha saldırısı ile sunucu kaynaklarını tamamen tüketebilirler.

XML Ayrıştırıcılarda XXE Güvenlik Açığını Kapatma

Neyse ki bu açığı kapatmak sandığınızdan çok daha kolaydır. Yapmanız gerekenler şunlardır:

• DTD İşlemeyi Kapatın: Kullandığınız parser kütüphanesinde harici entity’leri devre dışı bırakın. Java’da DocumentBuilderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) kullanın.
• Harici Genel Entity’leri Devre Dışı Bırakın: setFeature("http://xml.org/sax/features/external-general-entities", false).
• Harici Parametre Entity’lerini Devre Dışı Bırakın: setFeature("http://xml.org/sax/features/external-parameter-entities", false).
• Alternatif Parser Kullanın: Eğer mümkünse, güvenli varsayılan ayarlarla gelen daha modern parser’ları tercih edin.

Benim sahada edindiğim tecrübeye göre en sık yapılan hata, sadece parser’ı güncellemenin yeterli olduğunu sanmaktır. Hayır, güncel bir parser kullanıyor olsanız bile güvenlik ayarlarını manuel olarak kontrol etmek zorundasınız.

Milyar Kahkaha Saldırısı (Billion Laughs Attack) Nedir?

Bu saldırı türü hizmet engelleme (DoS) amaçlıdır. Saldırgan küçücük bir XML dosyasının içine iç içe geçmiş entity tanımları koyar. Parser bu tanımları açmaya kalktığında bellek katlanarak büyür ve sunucu çöker.

Örnek olarak: <!ENTITY lol "lol"> tanımını on kere iç içe geçirirseniz parser bellekte gigabyte’larca “lollollol…” metni oluşturmaya çalışır. Bu basit ama etkili saldırı yüzünden birçok büyük firma geçmişte zor anlar yaşamıştır.

Korunmak için yapmanız gerekenler XXE önlemleriyle neredeyse aynıdır. DTD işlemeyi tamamen kapatmak veya entity genişletme limitleri koymak bu riski ortadan kaldırır. Unutmayın, kullanıcıdan gelen hiçbir XML girdisine asla güvenmemelisiniz.

XML ile Veri Sorgulama ve Dönüştürme: XPath, XSLT ve XQuery

Artık dosyayı okuyup güvenliğini sağladığımıza göre sıra geldi içindeki veriyi akıllıca yönetmeye. Bu teknolojiler, veri ambarlarında saatlerce arama yapmak yerine, istediğiniz bilgilere hızla ulaşmanızı sağlar.

XPath ile XML Düğümlerine Erişim

XPath, belgelerdeki belirli elemanların veya özniteliklerin konumunu bulmanızı sağlayan bir sorgulama dilidir. Yani, bu dille hiyerarşik veri yapıları içinde kolayca gezebilirsiniz.

Tıpkı bir dosya sisteminde /home/kullanici/belgeler yazmak gibi düşünün. Ama bu kez hiyerarşik bir veri yapısı içinde geziniyorsunuz.

Örneğin, Yaşar Kemal’in kitabını listelerde bulmak isterseniz şu XPath kodunu yazabilirsiniz: /kutuphane/kitap[yazar='Yaşar Kemal']/ad. Bu sorgu size doğrudan sonucu getirir.

XPath öğrenmek başlangıçta biraz zaman alsa da bir kez kavradığınızda veri çekme işlemleriniz inanılmaz hızlanır. Özellikle web scraping veya test otomasyonu yapıyorsanız XPath bilmeden bir yere varamazsınız.

XSLT ile XML’i Farklı Formatlara Dönüştürme

XSLT ile belgeleri HTML veya farklı metin formatlarına dönüştürebilirsiniz. Bu süreçte döngüleri ve değişkenleri tıpkı bir programlama dilindeki gibi rahatça kullanabilirsiniz. Adeta bir programlama dili gibidir.

Veritabanından aldığım ham verileri XSLT ile şık bir PDF faturaya dönüştürmeyi çok seviyorum. Bu sayede sunucu tarafında kod değişikliği yapmadan sadece XSLT dosyasını güncelleyerek tasarımı değiştirebilirsiniz.

XSLT söz dizimi de yine XML tabanlıdır. Bu yüzden öğrenme eğrisi biraz diktir. Hazırladığınız bu şablonu, yıllar boyunca rahatlıkla kullanabilirsiniz.

XQuery: XML Veritabanları için SQL Benzeri Sorgulama Dili

Eğer verileriniz bir veri tabanında değil de devasa dosyalar içinde duruyorsa XQuery tam size göre. Bu dil tıpkı SQL’in ilişkisel veri tabanlarında yaptığını XML koleksiyonları için yapar. Gruplama, sıralama, filtreleme ve birleştirme işlemlerini destekler.

Bir XQuery ifadesi şöyle görünür: for $x in doc("kitaplar.xml")/kutuphane/kitap where $x/yil > 2000 return $x/ad. Bu sorgu 2000 yılından sonra basılmış kitapların adlarını listeler.

Günümüzde bazı NoSQL veri tabanları (örneğin MarkLogic veya BaseX) doğrudan XQuery çalıştırır. Büyük veri ve arşivleme projelerinde bu yetenek paha biçilmezdir.

XML İçin Takip Etmeniz Gereken Otoriter Kaynaklar

Bu rehberde anlattıklarım buzdağının sadece görünen kısmıdır. Daha derinlere dalmak isterseniz işte size sektörün en saygın ve güncel kaynaklarından birkaçı. Bu kaynaklar bilginizi taze tutmanıza ve en yeni gelişmeleri takip etmenize yardımcı olacaktır.

• W3C XML Resmi Dokümantasyonu: Standartların kaynağına inmek istiyorsanız W3C’nin XML sayfası ilk durağınız olmalıdır. Burada tüm tavsiye kararlarını ve taslakları bulabilirsiniz.
• OWASP XML Security Cheat Sheet: Güvenlik kısmını asla ihmal etmeyin. OWASP XML Güvenlik Rehberi sistemlerinizi korumak için başucu kitabınızdır.
• ISO 20022 Standartları: Finans sektöründe çalışıyorsanız ISO 20022 resmi sitesi üzerinden güncel şemaları ve mesaj tanımlarını inceleyebilirsiniz.

XML Dili Hakkında 10 Kritik Soru

Sonuç: XML Dili Öğrenmeye ve Kullanmaya Değer mi?

Bu uzun yolculuğun sonuna geldik. Şimdi en baştaki soruya dönelim: 2026 yılında bu teknolojiyi öğrenmek için zaman harcamak mantıklı mı? Cevabım kocaman bir evet. Hem de hiç tereddüt etmeden verdiğim bir evet.

Çünkü bu yapı asla bir moda akımı olmadı. O bir standart, bir anayasa niteliğindedir. Bugün yazdığınız bir mikroservisi, yarın 20 yıllık sistemlere bağlamanız gerekecek. Bu durumda, sahip olduğunuz bu bilgi sizi bir kahramana dönüştürür.

Unutmayın ki teknoloji dünyasında köklü bilgi her zaman değerlidir. Siz sadece XML öğrenmiyorsunuz; aynı zamanda veri modelleme disiplinini, hiyerarşik düşünmeyi ve güvenli kod yazma pratiklerini öğreniyorsunuz.

Ben şahsen kariyerim boyunca bu aracın bana kazandırdığı esneklik sayesinde bir çok krizden sağ çıktım. Umarım siz de bu rehberden faydalanır ve kendi projelerinizde bu gücü sonuna kadar kullanırsınız. Kalın sağlıcakla!