XML çok kötüyse… neden bu kadar çok insan kullanıyor? [kapalı]


37

XML'in amacını anlıyorum ama insanların her zaman ne kadar KÖTÜ olduğundan şikayet ettiğini duyuyorum? Gerçekten bu konuda neyin kötü olduğunu anlamıyorum? Genelde "şişirilmiş" ve "yavaş" terimlerinin atıldığını duyuyorum.

Ama programcılar olarak sanırım, esas olarak ne için kullanıyorsunuz? Ve bunu gerçekten "kötü" olarak mı düşünüyorsunuz .... çünkü eğer öyleyse, çok fazla insan veriyi taşımak için kullanır ...


1
Cevabınız soruda. İnsanlar hala kullanıyor, çünkü insanlar kullanıyordu ve seçenekler (1) JSON ve YAML'dan önce kullanılan tüm kodu yeniden yazmak ya da (2) onu emmek ve aptalca şeyleri yapmak. Birçok insan hala şiddet döngüsünü devam ettiriyor. Bu, uygulamanın kendine özgü değerini kanıtlamaz.
Parthian,

5
JSON'u gerçek bir belge için deneyin (man sayfası, Knuth, Hamlet, vb.). XML'in neden gerekli olduğunu daha sonra anlayacaksınız. Bu, JSON'un berbat olduğu bir alandır (devam edin, deneyin). Birini diğerinin tasarım alanında kullanmak şüphelidir. JSON'un alanında XML kullanmanın problemleri esasen ayrıntılı ve hızlıdır, JSON'un XML alanında kullanılmasındaki problemler taşınabilirliği (JSON'da bir kitap yapan bir arkadaşıyla birlikte çalışmayı deneyin, fakat kendi yolunda), dürüstlük ve düzeltilmesi gereken çok fazla insan çabası gerektiren yorumlama sorunları. İşiniz için doğru aracı kullanın.
TextGeek,

XML yalnızca kötüdür, çünkü birçok insan bunu istismar ettiği için tasarlamaz. Verilerinizin kolayca genişletilebilmesi için ihtiyacınız yoksa (ör. Şema, yetkili bir tarafça merkezi olarak dikte edilmek yerine, birlikte çalışması gereken birden fazla taraf tarafından kullanılıyor) ve verileriniz bir belge değilse (örneğin DOM Verilerinizin kötü bir soyutlaması oldum), o zaman XML bu uygulamalar için uygun değil. Sorunlu etki alanınız XML'in ne için tasarlandığının altına düştüğünde, başka hiçbir şey XML ile eşleşmez. JSON, YAML, vb. XML'in gerçekten tasarlandığı alan için uygun değildir.
Yalan Ryan

Yanıtlar:


90

Xml, ne tasarlandığına göre harika - platformun tarafsız, insan tarafından okunabilen bir veri aktarım protokolü olup, düşük seviyelerde veri doğrulamayı zorlama yeteneğine sahiptir. Bu şekilde Xml kullanan herkesin gerçek bir şikayeti olduğundan şüpheliyim. En özlü tel formatı mı? Hayır. Ancak daha kötü seçenekler var. Özel ikili biçiminizi okumak kadar hızlı mı? Hayır. Ancak iş ortaklarınız kullandıkları yığında okuyabilir.

Ancak sorun şu ki, insanlar - özellikle girişimci mimarlar olarak bilinen cins) kötülükler ve iyi şeyler alıp onları kötüleştiriyorlar. Xml durumunda, bu yüzyılın başlarında Xml, her BT sorunu için evrensel bir çekiç olarak görüldü. Komite tarafından küçük bir tasarım serpin ve SOAP ve OKSML gibi bazı korkunç canavarlıklar ile bitirin . Bunların hiçbiri düşmanlara dile getirilmemeli, arkadaş veya meslektaşlarına zarar vermemeliler.


15
+1 - EDI ile uğraşması gereken herhangi biri, XML'in keşfedilmeden önce icat edilmesini istiyor.
Scott Whitlock

12
+1 Düşüncelerime neredeyse tamamen uyuyor. Yalnızca hiyerarşik olsa bile (ama hiçbir şeyle iyi karışmaz ), hatta en iyisi JSON ve YAML gibi belirli biçimler olsa bile, basit ve basit verileri depolamak için eklerdim. İkincisi insan okunabilirliği açısından harika.

11
Jwz'den alıntı yapmak için: "Herhangi bir soruna bakacak ve" XML kullanacağımı biliyorum "diyecek belirli bir programcı var. Şimdi iki sorunu var. "
Adam Crossland

13
Lütfen bana oXML'nin Brainfuck veya Whitespace veya LOLCODE gibi bir şaka olarak tasarlandığını söyleyin.
dsimcha

9
@Shamim Hafiz, SOAP kesinlikle insanlığın yetiştirdiği en kötü canavarlardan biri.
SK-mantık

24

XML, pek çok lezzet ve kullanım içeren bir araçtır. XML bazı şeylerde üstündür ve bazılarında berbattır. Sanırım sorunlardan biri, insanların gereksiz yere karmaşık ve adlarını ve saçma sapan karmaşık "kurumsal" XML gördüklerini düşünüyorum (SOAP, herkes?). İnsanlar için XML formatları tasarlamanın püf noktası, verileri okumak için ezici hale getirmezken verilere gerçek anlam katmaktır.

İnsanların uğraştığı şeylerden biri, XML'in bazen bir karakterde ya da bazı parantezlerde boğulmasıdır. Bununla birlikte, bunun için hem ters hem de dezavantaj vardır. Bunun tersi, farklı yarı-geçersiz sözdizimi durumlarının farklı şekilde yorumlanabildiği HTML'de olduğu gibi belirsizliğin olmamasıdır.

Dezavantajı ise, yazarın yazması biraz zor, öğrenmesi daha zor. HTML kadar XML kadar katı olsaydı, web'in bu kadar hızlı olamayacağına dair bir argüman olduğunu kabul ediyorum, ancak bugün olsaydı da sevineceğimizi savunuyorum. :)

Ayrıca, onu her şey için kullanmayın, çünkü onu doğru şekilde uygulamak için gereken anlamı ve yargıya sahip olabilirsiniz. Sahip olduğunuz tek şey XML ise, her zaman istediğinizden uzakta bir XSLT dönüşümü olma eğilimindedir. :)

Biçimin yalnızca insanların kendisiyle etkileşime girmesi gerektiğinde gerçekten önemli olduğunu savunuyorum. Bir şeyi seri hale getiren ve başka programlarınız tarafından tüketilmesi gereken bir yere gönderen bir program yazıyorsanız, mümkün olduğu kadar verimli göründüğü kimin umurunda? Tek umursadığım her şey için bir ikili format, tavşanlar ve tek boynuzlu atları kullanın.

XML'in Artıları

  • YAML ve JSON’un bilmediği pek çok ileri durumu kapsar
  • Bir dizi farklı platform ve dilde XML'in ayrıştırılması ve doğrulanması için mükemmel araçlar vardır.
  • XML kolayca ve güçlü bir şekilde başka bir formata dönüştürülebilir (XSLT gibi şeyler aracılığıyla)
  • Makul XML belgeleri, insanların okuması ve düzenlemesi için basittir; Bana JSON'un daha kolay olduğunu söyleme, değil :)
  • XML bir dereceye kadar kendini tanımlamaktadır, yani doğrudan yapısı ve anlamı hakkında bilgi içerir (çoğu ikili formatın aksine)
  • Kodlama kolları
  • Platformlar arası agnostik, platformlar arası daha kolay kullanım sağlar
  • İyi biçimlendirilmemişse kırılır (Verilerin yapısal olarak doğru olmasını sağlar)
  • SGML değil

Eksileri

  • gereksiz sözlerle dolu
  • İkili olarak ayrıştırmak kadar hızlı değil
  • İyi biçimlendirilmemişse kırılır (başvurunuzu kilitler)

İyi kullanımlar

  • Yapılandırma dosyaları
  • Veri değişim formatları
  • Sürüm esnek dosya formatları
  • Belgeleri veritabanlarında saklamak

Çok iyi değil kullanımlar

  • Veri aktarma formatları
  • Nesnelerin Serileştirilmesi
  • İlişkisel verileri veritabanlarında saklamak
  • Yüksek performanslı I / O senaryoları için dosya formatı

13
"Yapılandırma dosyaları" nın "iyi kullanımlar" altında olması gerektiğinden şüpheliyim. Veri değil, talimat değil.
daknøk

3
Burada @ daknøk ile birlikteyim - Küçük bir yazım hatası temelli olan bağımlılık enjeksiyonunu belirten, uzun bir XML-file satırının hunderds'ında bir yapılandırma hatası bulmak için çok fazla zaman harcamak zorunda kalamam. bir XML niteliği.
Gjallar

3
Kötü veriler bir uygulamayı çökerse, sorunu olan veriler mi?
James Snell

4
Yanlış biçimlendirilmiş / bozuk herhangi bir dosya formatı, bozuk yazılımları çökme potansiyeline sahiptir. Yani XML burada suçlu değildir ... sadece uygulamanız. Aksi takdirde, iyi yazı.
Thomas Eding

3
"YAML ve JSON’un yapmadığı birçok büyük durumu kapsar".
Trevor Hickey

14

Jeff Atwood'un XML'de çok iyi bir blog yazısı var : Bir kaynak hakkında konuşmak istiyorsanız, bununla ilgili Açı Braketi Vergisi .

Sahip olduğum en yaygın kullanımlar:

  • Birbirinizle konuşmak hizmetleri. Örneğin, bir içerik yönetim sistemi kullanan bir web sitesinin bir müşteri ilişkileri yönetim sistemine bazı veriler göndermesi gerekir ve bu da XML ile yapılır.

  • Yapılandırma depolama. Web.config ve app.config ortak örneklerdir ancak nAnt komut dosyaları da bunlara bazı XML kullanabilir.

Bunun optimal olduğunu düşünmüyorum ama bu tek başına aklıma kötü gelmiyor.


11

İki sebep:

  1. Dışarıda çok fazla kötü programcı var. XML kötü olabilir, ancak aynı zamanda basit (en azından yüzeyde) ve kötü yazılım yazmayı çok kolaylaştırıyor. VB gibi sorta.
  2. Bu kararları veren kişilerin çoğu programcı değil, sadece “herkesin XML kullandığını” duyan iş türleridir ve bu nedenle ürünlerinin de XML kullanmasını istediklerine karar verirler.

Ne saçma ve tamamen işe yaramaz şeyler. 1) XML çok da kötü değildir ve insanların seçtikleri veya seçtikleri yazının kalitesiyle hiçbir ilgisi yoktur, VB kullanıyorsanız gerçekten kötü yazılım yazdığınızı ima ederek oldukça iyi bir VB programcısı gördüm. sadece aptalca çünkü yazılım yazma ile yazdıklarınız arasında tam bir kopukluk var. 2) Yine bir başka sahte varsayım, XML seçimi harika ve onu daha iyi ya da daha kötü için seçenlerin çoğu kesinlikle programcılar. XML gümüş kurşun değildir, ancak bazı şeyler için iyidir.
Eyal Solnik,

2
@EyalSolnik: Bazı insanlar, bir sorunla karşılaştığında, “Biliyorum, XML kullanacağım” diye düşünürler.<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription> </ProblemWorsening>
Mason Wheeler

3
İnsanların bir şeyi kötüye kullanması, teknolojinin kendisinin kötü olduğu anlamına gelmediğinden, aynı sendromu birçok yerde görebilirsiniz.
Eyal Solnik

8

Genelde "şişirilmiş" ve "yavaş" terimlerinin atıldığını duyuyorum.

En kompakt sözdizimi değil, ama kesinlikle en etkileyici olanı. İnsan okunabilir mi? dilinizi nasıl tasarladığınıza bağlıdır. Çoğu insan XML için bir dil tasarlamaz, sadece nesneleri XML olarak serileştirir.

… Neden bu kadar çok insan kullanıyor?

Her yerde var. XQuery ile bir XML veritabanını sorgulayabilir, XSLT ile XHTML veya Atom olarak sonuçları dönüştürebilir, Atom veya diğer XML formatlarını diğer web servislerinden alabilir, XForms kullanarak kullanıcılardan XML alabilir, XMLSchema, Relax NG veya Schematron ile doğrulayabilir, XProc, XQuery Update ile veritabanına geri kaydedin. Tüm bu araçlar XML'i anlar, bu nedenle farklı temsiller arasında haritalamaya gerek yoktur.

XML bir serileştirme teknolojisi değil, genel amaçlı bir bilgi setidir.


... ve yıllarca kendimize, SOAP'ın neden XML üzerine inşa edildiğini soruyoruz.
JensG

6

Burada, farklı satıcılar tarafından yapılan farklı sistemler ve farklı iç temsiller arasında veri değişimi için kullanıyoruz. Verileri ileri geri sarmak için bir XML dönüşüm / değişim sistemi inşa ediyoruz. Bunun için iyi çalışıyor.

XML doğal olarak kötü değil, ancak XML kullanarak "iyi" bir çözüm tasarlamanın önemsiz olmadığını kabul ediyorum.


5

"XML'in özü şudur: Çözdüğü sorun zor değildir ve sorunu iyi çözemez." - Phil Wadler, POPL 2003

Benim kişisel görüşüm, doğrulama, şemalar, XSLT'ler ve diğer çirkin şeyleri umursamadığınız sürece ve dosyaların boyutunu küçük tuttuğunuz sürece (aksi halde ayrıştırma yavaşlar), XML'in bazı iyi kullanımlarını bulabilirsiniz (bir örnek: INI dosyalarını kullanmak yerine uygulamanızı yapılandırmak içindir).


4

Tecrübelerime göre, insanlar çoğunlukla teknolojinin kendisi değil, kullanıldığı yöntemlerden şikayet ediyorlar.

İnsanların şikayet ettiği şişirilmiş ve yavaş bitler genellikle ondan bilgi almak için kullanılan kütüphaneler / yöntemlerdir.

Diskte saklamak istediğim küçük miktarda yapılandırılmış bilgiyi depolamak için kullanıyorum (bir veritabanı veya ikili serileştirme olmadan) veya başka bir uygulamaya (aslında SOAP'ı da tanımlayan) iletiyorum.


2

İyi çünkü:

Birden fazla heterojen sistemin iletişim kurmak için kullanabileceği standart bir "Arayüz" . Ve "İnsan" Okunabilir (5 MB XML'ye bakmayı deneyin)

Kötü çünkü:

Şişirilmiş, daha büyük boy = daha fazla bant genişliği = daha fazla $$

Başka sebepler var, herkesin farklı bir yakınması var ...


4
@Darknight: Size Xml Entity'ler attırarak okunabilir insanlara meydan okuyorum ... (kişisel peeve)
Matthieu M.

1
XML'in içsel olarak şişirilmiş olduğunu düşünmüyorum - ancak uygulamaları. Gereksiz şişkinlikte XML-RPC'yi özellikle iğrenç buluyorum.
HorusKol

3
@HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator>Veri / işaretleme oranı çok düşük ... Buna "şişirilmiş" diyorum. Json, örneğin, yarım kabartılan yalnızca olacaktır: advanceAcceptanceIndicator: "Y". Etiketler arasındaki metnin de geçerli olduğu gerçeği de vardır , bu nedenle Xml okurken, bu boşlukta ne yapılacağına karar vermeniz gerekir \n\t\t\tve çözüm genellikle onu görmezden gelmektir, çünkü bununla hiç ilgilenmediniz.
Matthieu M.

1
@HorusKol: Olurdu, ama hiçbir zaman boolean bir değer olduğunu söylemedim, sadece tek bir karakter olacaktı :) Buradaki özniteliğin ( value?) Kullanımı da muhtemelen üstün olurdu, çünkü insanlar aralarında iki boşluk bırakmaya özendirilmiş olabilirlerdi. etiketleri.
Matthieu M.

1
“Şişirilmiş, daha büyük beden = daha fazla bant genişliği = daha fazla $$” Sanırım henüz bulunduğunuz yerde sıkıştırma icat edilmedi.
Andy,

2

Diğer tüm teknolojilerde olduğu gibi: birçok mevcut araç ve kütüphane var.

XML'den hoşlanmıyorum, özellikle korkak olduğu için, insanlar insan tarafından okunaklı olduğunu söylediğinde, şakalaşır, sanırım ya da bir özniteliğe xml katıştırılmaya çalışıldığında xml okumadıklarını ... okunmaz. Ayrıca, gereksiz son etiketi ve boş metin ve verileri bir arada kullanabilme özelliği nedeniyle ne kadar boş alan harcanması şaşırtıcı ...

Fakat:

  • Xml belirtilebilir (xsd) ve Xml verilerinin uygunluğunu kontrol eden araçlar kullanılabilir
  • birçok araç (metin editörleri ve benzeri) Xml'i destekliyor
  • Çok sayıda kütüphane (yaklaşık her programlama dilinde) Xml desteği

Aynı zamanda, çoğu zaman, öncelik avantajına sahiptir. Zaten Xml'de web hizmetleri sağladığınızda ve biri yeni bir hizmet istediğinde ... muhtemelen Xml'de yapılacaktır, çünkü bunu biliyorsunuzdur.


5
XML, ikili veya konumsal veya virgülle ayrılmış verilerden daha okunaklıdır.
FrustratedWithFormsDesigner

Sadece saf bir kullanıcı için. Verileri eksik olan bir tane arayan bir kaç yüz kaydı görsel olarak taramak zorunda kalırsam, sabit uzunlukta bir kayıt bloğunda boş bir etiket arayan bir dizi öğeyi ve özniteliği beklemekten çok daha fazla boş sütunlar aramayı tercih ederim.
TMN

1
@FrustratedWithFormsDesigner: bu, eldeki verilere göre değişir. Xml, bilginin doğasını doğru bilginin yanına yerleştirir. İşlevsel programlama dillerine bakarsanız, (Haskell) gibi şeyler görürsünüz: data Person = Person { surname :: String, firstName :: String, age :: Int }o zaman ben Person "Doe" "John" 42de okunabilir olduğunu görürsem ve çok fazla kaba davranmaktan kaçının, yine de virgülle sınırlandırılmış.
Matthieu M.

1
Tamam, Örneğiniz işaretlemeden okunması daha kolaydı, ancak önemsiz (8 veya 9'dan az veri öğesi diyelim) tüm formları (belki de ikili hariç) desteklemek için örnekler verebilir. Ana bilgisayardan gelen veri beslemeleri, konum sınırlandırılmış dizeler olarak ortaya çıkar (ve çoğu yalnızca sayısal kodlardır) ve XML'e dönüştürüldükten sonra okunması ve hata ayıklaması ve yönetimi çok daha kolaydır. Dediğin gibi, o ... bağlı olabilir
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner: Evet, bu tam olarak benim açımdan :) Buna bağlı, ancak XML için çok zengin bir ekosistem olduğundan ve yalnızca bir araç / kitaplık kümesini korumak daha kolay olduğu için insanlar genellikle her şey için XML kullanır. Şahsen, JSon'u XML yerine tercih ediyorum, ancak bir kez daha girinti olmadan, bu biraz dağınık: p
Matthieu M.

-1

XML, insanlar tarafından tutulması gereken dosyalar için kötü bir seçimdir. İşaretleme ile içerik arasında görsel bir ayrım yoktur, bu da okumayı zorlaştırır. Özel amaçlı bir editör olmadan doğru yazmak sıkıcıdır. Bir XML belgesindeki herhangi bir hata ölümcüldür; Bir XML belgesi kısmen işlenemez. Bir XML dosyası geçersiz olduğunda, ortaya çıkan hata mesajı genellikle yararsızdır.

Bir insan tarafından tutulması gereken herhangi bir dosya için, herhangi bir JSON, YAML veya kaynak kodunu yorumlanmış bir dilde (Python, Ruby, Groovy, vb.) Kullanmayı tercih ederim. Eski kod için XML yapılandırması oluşturmanın harika bir yolunun Groovy MarkupBuilder'ı kullanmak olduğunu gördük. Başka bir iyi seçenek, alana özel bir dil oluşturmaktır; Bu Ruby, Groovy ve diğer birçok dil ile yapmak oldukça kolaydır.


8
Sana XML noktayı kaçırıyorsun, işaretleme düşünüyorum olduğu içeriği. XML'in amacı, verilerinizin anlamını tanımlamaktır. Örneğin, bir telefon numaranız varsa, bunu bir sabit hat numarası veya mobilenumber olarak etiketlemek, diğerlerinin kullanabileceği bağlamı ekler. Veya bu konuda metin etrafına bir telefon etiketi ekleyerek (bu numarayı cep telefonunda çağrılabilir yapabilir). Diğer noktalarına gelince ben de aynı fikirde değilim. Xml belgelerinin yazılması genellikle oldukça kolaydır. Hata mesajları her zaman iyi biçimlendirmeyle ilgilidir ve JSON üzerinden
xml'yi

@konrad telefonunuzun örneği HTML için geçerli olur.
Florian F

"Bir XML belgesindeki herhangi bir hata ölümcül; bir XML belgesi kısmen işlenemiyor." Evet, bu XML noktasının büyük bir parçası.
Andy,

@Andy XML insan tarafından yazılmış ve uygulama sadece "yanlış!" Diyorsa, oldukça işe yaramaz. Bir insan editörünün hatanın tespit edildiği satırı bilmesi gerekir.
kevin cline

Herhangi bir sayıda araç, hatanın tespit edildiği tam olarak hangi satırda ve hangi karakterde olduğunu söyler. Örneğin, NotePad ++ 'daki XML Araçları. .Net, .config dosyanızın nerede olduğunu da tam olarak söyleyecektir. Bir API hakkında konuşuyorsanız, XML'in yararlarından biri, API geliştiricisinin bir XSD sağlayabilmesidir; bu elemanlardan sadece biri, vb. olabilir. El yazısı json'u batırmak çok daha kolaydır.
Andy,

-2

Ayrıştırma, aynı anda insan tarafından okunabilirken nispeten kolaydır.

Ve bazı güzel ayrıştırıcılar (Eg Xerces {c ++}) hazır.


2
Belgeler küçük olduğu sürece kolaydır. Belgeleri makul bir şekilde belleğe sığmayacak kadar büyük olarak ayrıştırmanız gerekirse, işler ağırlaşır.
TMN

İnsanın okunabilirlik bölümünü sorgularım. Eşdeğer bir JSON okumaktan öte XML okumak için çok fazla çaba harcıyoruz.
cmaster
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.