XML dili 1996 yılında icat edildi. Ortaya çıktığı andan itibaren uygulama olanakları yanlış anlaşılmaya başlamıştı ve onu uyarlamaya çalıştıkları amaçlar açısından bu en iyi seçim değildi.
Gördüğüm XML şemalarının büyük çoğunluğunun uygunsuz veya yanlış XML kullanımı olduğunu söylemek abartı olmaz. Üstelik XML'in bu şekilde kullanılması, XML'in neyle ilgili olduğu konusunda temel bir yanlış anlaşılmayı ortaya koydu.
XML bir işaretleme dilidir. Bu bir veri formatı değil. Çoğu XML şeması bu ayrımı açıkça gözden kaçırmış, XML'i bir veri formatıyla karıştırmıştır; bu da aslında XML'in seçilmesinde bir hataya yol açmıştır, çünkü aslında ihtiyaç duyulan veri formatıdır.
Çok fazla ayrıntıya girmeden XML, metin bloklarına yapı ve meta verilerle açıklama eklemek için en uygun yöntemdir. Ana amacınız bir metin bloğuyla çalışmak değilse, XML'i seçmeniz pek doğru olmaz.
Bu açıdan bakıldığında XML şemasının ne kadar iyi yapıldığını kontrol etmenin basit bir yolu var. Örnek olarak amaçlanan şemadaki bir belgeyi ele alalım ve içindeki tüm etiketleri ve nitelikleri kaldıralım. Geriye kalan mantıklı değilse (veya boş bir satır kaldıysa), o zaman ya şemanız doğru şekilde oluşturulmamıştır ya da XML kullanmamalıydınız.
Aşağıda yanlış yapılmış devrelerin en yaygın örneklerinden bazılarını vereceğim.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Burada XML'de basit bir anahtar/değer sözlüğünü ifade etmeye yönelik temelsiz ve tuhaf (ama çok yaygın) bir girişimin örneğini görüyoruz. Tüm etiketleri ve nitelikleri kaldırırsanız boş bir satırla kalırsınız. Aslında bu belge, kulağa ne kadar saçma gelse de, boş bir satırın anlamsal açıklamasıdır.
<root name="John" city="London" />Daha da kötüsü, burada bir sözlüğü ifade etmenin abartılı bir yolu olarak boş bir dizenin semantik açıklamasına sahip değiliz - bu sefer "sözlük" doğrudan kök öğenin nitelikleri olarak kodlanmıştır. Bu, bir öğedeki verilen nitelik adları kümesini tanımsız ve dinamik hale getirir. Dahası, bu, yazarın gerçekten ifade etmek istediği tek şeyin basit bir anahtar-değer sözdizimi olduğunu, ancak onun yerine XML'i uygulamak için tamamen tuhaf bir karar verdiğini ve nitelik sözdizimini kullanmak için tek bir boş öğenin yalnızca bir önek olarak kullanılmasını zorladığını gösteriyor. Ve bu tür planlarla çok sık karşılaşıyorum.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Bu daha iyi bir şey, ancak şimdi bazı nedenlerden dolayı anahtarlar meta verilerdir ve değerler değildir. Sözlüklere çok tuhaf bir bakış. Tüm etiketleri ve nitelikleri kaldırırsanız bilgilerin yarısı kaybolur.
XML'deki doğru bir sözlük ifadesi şuna benzer:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Ancak eğer insanlar XML'i bir veri formatı olarak kullanmak gibi garip bir karar vermişlerse ve daha sonra onu bir kelime dağarcığını düzenlemek için kullanmışlarsa, o zaman yaptıklarının uygunsuz ve uygun olmadığını anlamaları gerekir. Tasarımcıların uygulamalarını oluştururken yanlışlıkla XML'i seçmeleri de yaygındır. Ancak daha da sık olarak, XML'i yukarıda açıklanan biçimlerden birinde anlamsız bir şekilde kullanarak, XML'in buna uygun olmadığı gerçeğini göz ardı ederek durumu daha da kötüleştirirler.
En Kötü XML Şeması? Bu arada ödül gördüğüm en kötü XML şeması, Polycom IP telefon telefonları için otomatik sağlama yapılandırma dosyası biçimini alır. Bu tür dosyalar, XML istek dosyalarının TFTP yoluyla indirilmesini gerektirir, bu da... Genel olarak, böyle bir dosyadan bir alıntıyı burada bulabilirsiniz:
<softkey
softkey.feature.directories="0"
softkey.feature.buddies="0"
softkey.feature.forward="0"
softkey.feature.meetnow="0"
softkey.feature.redial="1"
softkey.feature.search="1"
softkey.1.enable="1"
softkey.1.use.idle="1"
softkey.1.label="Foo"
softkey.1.insert="1"
softkey.1.action="..."
softkey.2.enable="1"
softkey.2.use.idle="1"
softkey.2.label="Bar"
softkey.2.insert="2"
softkey.2.action="..." />Bu birinin kötü şakası değil. Ve bu benim buluşum değil:
- öğeler, hiyerarşik adlara sahip olan nitelikleri eklemek için basitçe bir önek olarak kullanılır.
- Belirli bir kayıt türünün birden çok örneğine değer atamak istiyorsanız bunu yapmak için nitelik adlarını kullanmanız gerekir. indeksleri olan.
- Ayrıca ile başlayan özellikler
softkey., elemanların üzerine yerleştirilmelidir<softkey/>, ile başlayan özelliklerfeature., elemanların üzerine yerleştirilmelidir<feature/>vb. tamamen gereksiz ve ilk bakışta anlamsız görünmesine rağmen. - Ve son olarak, eğer bir nitelik adının ilk bileşeninin her zaman öğe adıyla aynı olmasını umuyorsanız - öyle bir şey yok! Örneğin, nitelikler
up.eklenmelidir<userpreferences/>. Nitelik adlarının öğelere eklenmesi sırası neredeyse tamamen keyfidir.
Belgeler veya veriler. Arada bir, birisi XML ile JSON'u karşılaştırmaya çalışarak tamamen tuhaf bir şey yapar ve böylece ikisini de anlamadığını gösterir. XML bir belge biçimlendirme dilidir. JSON yapılandırılmış bir veri formatıdır, dolayısıyla bunları birbirleriyle karşılaştırmak, sıcak ve yumuşak verileri karşılaştırmaya benzer.
Aradaki fark kavramı belgeler ve veriler. XML'in bir benzeri olarak, makine tarafından okunabilen bir belgeyi koşullu olarak alabiliriz. Her ne kadar makine tarafından okunabilir olması amaçlanmış olsa da mecazi olarak belgelere atıfta bulunur ve bu açıdan bakıldığında aslında çoğu zaman makine tarafından okunamayan PDF belgeleriyle karşılaştırılabilir.
Örneğin XML'de öğelerin sırası önemlidir. Ancak JSON'da nesneler içindeki anahtar/değer çiftlerinin sırası anlamsız ve tanımsızdır. Sırasız bir anahtar/değer çiftleri sözlüğü elde etmek istiyorsanız, öğelerin o dosyada göründüğü gerçek sıra önemli değildir. Ancak bu verilerden birçok farklı türde veri oluşturabilirsiniz. evraklarÇünkü belgede belli bir düzen vardır. Mecazi olarak, çıktı veya PDF dosyasından farklı olarak fiziksel boyutları olmamasına rağmen kağıt üzerindeki bir belgeye benzer.
Uygun bir XML sözlük temsili örneğim, JSON temsilinin aksine sözlükteki öğelerin sırasını gösterir. Bu sırayı göz ardı edemem: bu doğrusallık belge modelinin ve XML biçiminin doğasında vardır. Bazıları bu XML belgesini yorumlarken sırayı göz ardı etmeyi seçebilir, ancak konu formatın kendisiyle ilgili tartışmanın kapsamı dışında olduğundan bu konuda tartışmanın bir anlamı yoktur. Üstelik, belgeye basamaklı bir stil sayfası ekleyerek belgeyi tarayıcıda görüntülenebilir hale getirirseniz, sözlük öğelerinin belirli bir sırayla göründüğünü, başka hiçbir düzende görünmediğini göreceksiniz.
Başka bir deyişle, bir sözlük (yapılandırılmış veri parçası) dönüştürülebilir n çeşitli olası belgeler (XML, PDF, kağıt vb.), n - sözlükteki olası öğe kombinasyonlarının sayısı ve diğer olası değişkenleri henüz hesaba katmadık.
Ancak, yalnızca veri aktarmak istiyorsanız, bunun için makine tarafından okunabilen bir belge kullanmanın etkili olmayacağı da anlaşılmaktadır. Bu durumda gereksiz olan bir model kullanıyor; sadece yolunuza çıkacak. Ayrıca kaynak verileri çıkarmak için bir program yazmanız gerekecektir. Bir noktada belge olarak biçimlendirilmeyecek bir şey için XML kullanmanın pek bir anlamı yoktur (örneğin, CSS veya XSLT veya her ikisini birden kullanmak), çünkü bunu yapmanın ana (tek olmasa da) nedeni budur. belge modeline.
Üstelik XML'de sayı kavramı (veya Boolean ifadeleri veya diğer veri türleri) bulunmadığından, bu formatta temsil edilen tüm sayılar yalnızca ek metin olarak kabul edilir. Verileri çıkarmak için şema ve onun ifade edilen karşılık gelen verilerle ilişkisi bilinmelidir. Ayrıca bağlama bağlı olarak belirli bir metin öğesinin ne zaman bir sayıyı temsil ettiğini ve ne zaman bir sayıya dönüştürülmesi gerektiğini vb. bilmeniz gerekir.
Bu nedenle, XML belgelerinden veri çıkarma işlemi, örneğin birçok sayfalık sayısal veri oluşturan tablolar içeren taranmış belgeleri tanıma sürecinden çok farklı değildir. Evet, prensipte bunu yapmak mümkündür, ancak kesinlikle başka seçeneğin olmadığı son çare olması dışında bu en uygun yol değildir. Makul bir çözüm, verileri özel metinsel temsiliyle birleştiren bir belge modeline gömülmemiş orijinal verilerin dijital bir kopyasını bulmaktır.
Bununla birlikte, XML'in iş dünyasında popüler olması beni hiç şaşırtmadı. Bunun nedeni tam olarak belge formatının (kağıt üzerinde) anlaşılır ve iş dünyasına tanıdık gelmesi ve tanıdık ve anlaşılır bir model kullanmaya devam etmek istemeleridir. Aynı nedenden dolayı, işletmeler makine tarafından okunabilir formatlar yerine PDF belgelerini sıklıkla kullanıyor; çünkü bunlar hâlâ belirli bir fiziksel boyuta sahip basılı sayfa kavramına bağlı. Bu, hiçbir zaman yazdırılması muhtemel olmayan belgeler için bile geçerlidir (örneğin, kayıt belgelerinin 8000 sayfalık PDF'si). Bu açıdan bakıldığında XML'in iş dünyasında kullanımı esasen skeuomorfizmin bir tezahürüdür. İnsanlar, sınırlı boyuttaki basılı sayfanın metaforik fikrini anlıyor ve basılı belgelere dayalı iş süreçlerinin nasıl oluşturulacağını anlıyorlar. Kılavuzunuz buysa, makine tarafından okunabilen, fiziksel boyut sınırlaması olmayan belgeler (XML belgeleri), tanıdık ve rahat bir belge karşılığı olmanın yanı sıra yeniliği de temsil eder. Bu onların veri sunmanın yanlış ve aşırı çarpık bir yolu olarak kalmasını engellemez.
Bugüne kadar, formatın gerçekten geçerli bir kullanımı diyebileceğim bildiğim tek XML şemaları XHTML ve DocBook'tur.
Kaynak: habr.com