XML'i tamamen JSON ile değiştirebilir miyiz? [kapalı]


78

Eminim birçok geliştirici XML ve JSON'a aşinadır ve ikisini de kullanmıştır. Bu nedenle, kısaca bile, onların ne olduğunu ve amaçlarının ne olduğunu açıklamanın bir anlamı yoktur.

Kavramlarını haritalamaya çalışırsak, şunu söyleyebiliriz (yanılıyorsam düzelt beni):

  1. XML etiketleri JSON'a eşdeğerdir {}
  2. XML nitelikleri JSON özelliklerine eşdeğerdir
  3. XML etiketi koleksiyonu JSON'a eşdeğerdir []

JSON'da olmayan, düşünebildiğim tek şey, XML Ad Alanları .

Sorun şu ki bu haritayı göz önünde bulundurarak ve JSON'un bu haritalamada çok daha hafif olduğunu göz önüne alarak, XML olmadan gelecekte (ya da en azından teorik olarak bir dünya düşünür) dünyasını görebilir miyiz, ama JSON XML'in yaptığı her şeyi yapıyor mu? JSON'u XML'in kullanıldığı her yerde kullanabilir miyiz?

Not: Lütfen bu soruyu gördüğümü unutmayın . Burada sorduğumdan tamamen farklı bir şey. Böylece söz etmeyiniz yinelenen .


14
Öyle ki, aşırı kabarık, kötü tasarlanmış her şeyi S ifadeleriyle değiştirebiliriz (ve etmeliyiz). XML'siz dünya gerçekten çok daha iyi bir yer olurdu, ama bu ne yazık ki, dilek dolu bir düşünceden başka bir şey değil.
SK-mantık

19
Ugh. Bu sorulardan nefret ediyorum. Bunun gerçekten de iş için doğru aracı kullanmak olduğunu ve birinin diğerini tamamen değiştirip değiştiremeyeceğini düşünüyorum. Dünyada, hatta bilgisayarlarla bile, çok az sayıda mutlak var. JSON ile yaptığım hiçbir şeyi, en azından ilgili teknolojilerin bulunduğu yerde yapmayı hayal bile edemezdim.
Philip Regan

2
@Philip, bu bir şeyi yıkmak için bir soru değil. Sadece JSON'un eksikliğini görmeye çalışır, böylece onu iyileştirebiliriz. :)
Saeed Neamati 16:11

4
İyileştirmelerin nerede yapılabileceğini görmek için iki teknoloji arasındaki farklar hakkındaki tartışma, birinin diğeriyle değiştirilip değiştirilemeyeceğini sormaktan çok farklı. İlki, hayal kırıklığından her şeyden daha düşmanca gelen şeyden daha bilimsel bir incelemedir
Philip Regan,

12
Bu varsayımsal değil. JSON, XML'in sahip olduğu bir özelliğe sahip değil gibi görünüyor.
S.Lott,

Yanıtlar:


153

XML'e gücünü ve karmaşıklığını çok veren şey karışık içeriktir. Bunun gibi şeyler:

<p>A <b>fine</b> mess we're in!</p>

Bunu JSON'da yapmayı denemeyin ya da geleneksel programlama dillerinde işlem yapmayın. İş için tasarlanmadılar.

Bu tür bir soru genellikle, XML'deki M'nin işaretleme anlamına geldiğini unutan insanlardan gelir. Düzgün metin almak ve yapılandırılmış metin oluşturmak için işaretleme eklemek için bir yol. Eski moda veriler için de oldukça kullanışlıdır, ancak bunun için tasarlandığı veya ana güçlerinin bulunduğu yer bu değildir. Basit verileri işlemenin birçok yolu vardır ve JSON bunlardan biridir.


33
+1: Bu ayırt edici özellik. Mükemmel nokta
S.Lott

7
@Michael, bana sadece değerli bir şey öğrettin. Bu harika bir cevap. +1.
Saeed Neamati 16:11

9
.... 3 tane P, indie A , B elemanı ve içinde bulunduğumuz karışıklık var! JSON'da açıklayabileceğiniz bir dizi.
Gizli

5
@Rob Hayır, ancak HTML tarafından ifade edilen şeyleri daha net bir şekilde tanımlayabileceğinizi ve belki de JSON aracılığıyla daha hızlı ayrıştırmayı açıklayabileceğimi açıklıyorum (farklı düğüm türlerini bulmak için metnin daha az ayrıştırılması gerektiğinden). Eğer HTML, JSON-ML olsaydı, aslında DOM, metin düğümleri ve ciltlemeleri anlayan daha fazla geliştiricimiz olabilirdi.
Gizli

5
@ByrneReese: evet, XML ve evet geçerli. Bunun da HTML olduğu konunun yanında; Aslında, XHTML de geçerli bir XML'dir. :-)
Martijn

31

Bence asıl fark, XML'in dtd's ve her şeyiyle kendi kendini açıklamak için tasarlandığı gerçeğidir.

JSON ile, aldığınız veriler hakkında çok fazla varsayımda bulunmalısınız.


7
"XML kendini açıklayacak şekilde tasarlandı". Bunun için bir bağlantı veya referans verebilir misiniz? XML için W3C standartlarında görmüyorum ve bu fikrin nereden geldiğini merak ediyorum. Belirlenmiş bir tasarım hedefinden daha fazla bir şehir efsanesi gibi gözüküyorum.
S.Lott

6
@ S.Lott: Bunun anlamı ne anlama geliyor, XML etiketlerinin niteliği, kendi içinde, etiketlenmiş içeriğin kendi kendini açıklayıcı olmasına izin veriyor, yani DTD'ler isteğe bağlı olduğundan, iyi biçimlendirilmiş XML bir olmadan ayrıştırılabilir. Ancak, bu konuyu ele almanıza katılıyorum çünkü, teknik olarak JSON aynı kabiliyete sahip, bu yüzden kendi kendini açıklamanın asıl fark olduğunu görmüyorum (bunun neden oylanmaya devam edeceğinden emin değilim), ama daha doğrusu Michael Kay daha fazlası için işarette.
Philip Regan

5
@ S.Lott kabul etti. Buradaki JSON'u söylemek zorundayım, json.org/example.html , ayrıntı vermemesi nedeniyle ilişkili XML'den daha kolay anlaşılır ve daha iyi belgelenir.
Doug T.

4
@Michael Borgwardt: Tam bir XSD olmadan (bir tür ontoloji desteği dahil) etiket adları bana hiçbir şey söylemez. "anlamlı" genel olarak başarmak zordur. Bu beni cevapta ne anlama geldiği konusunda "kendi kendini açıklamanın" ne olduğu konusunda net değil. Ve bunun XML için bile bir tasarım hedefi olduğuna dair kanıtım yok.
S.Lott,

4
@Philip Regan: "Kendini açıklayan kod" ile olduğu gibi , bir XML özelliği gibi görünmüyor . Tüm yazılım dilleri (kod, veri erişimi, biçimlendirme, ne olursa olsun) için geçerli olan evrensel bir uygulama hedefi ise, belki de halk bunu özellikle XML etrafında söylememelidir.
S.Lott,

21

JSON'un değişmez çevirisi genellikle daha az özlü ve daha az açıktır. Düşünmek:

<foo>
   <x:bar x:prop1="g">
      <quuz />
   </bar>
</foo>

Bu gördüğüm en etkili JSON gösterimi:

{"localName":"foo",
 "children": // you need to have a special array to hold all children
 [
    {"localName": "bar",
     "namespace": "x"
        // once again, to ensure that there are no collisions,
        // attributes should be brought out into their own JSON structure 
        "attributes":[
            {"localName":"prop1",
             "namespace":"x",
             "value":"g"}
        ],
         "children":[
             {"name":"quux"}
         ]
     }
 ]}

Şimdi, bunu bütün bir XML dosyası için düşünün. JSON'un yeri olmadığını söylemiyorum, ancak XML dışlanmamalı.


8
Şimdi SXML'yi düşünün:(foo (x:bar (@ (x:prop1 "g")) (quuz)))
SK-logic

2
@ SK-Logic: Önemsiz bir örnek için harika, ancak bunun gibi derinlemesine iç içe, karışık bir içerik (bir kitap gibi) yapmayı hayal edemiyorum. SXML'in her şey kadar akademik bir alıştırma olduğunu düşünüyorum.
Philip Regan

3
@Philip Regan: S-Exp'i, daha az ayrıntılı bir forma dönüştüren önemsiz bir 1: 1 dönüşümü olduğunda, chevronitis kullanarak daha zor nasıl yazabilir?
maaartinus 16:11

@maartinus: Uzmanlık alanım kitap yayıncılığı konusunda: her türlü ders kitabı, açık bir yönetim gerektiren çok çeşitli içeriğe sahip derin, karmaşık canavarlar. DocBook ve DITA, yukarıda verilen örnekten çok daha okunur.
Philip Regan

1
@Philip Regan, SXML'nin XML'den farklı olarak düzenlenmesi çok kolaydır. Ve tabii ki, mevcut takımın üstünlüğünden bahsetmek zorunda kalmadan, protokoller için çok daha iyi bir seçimdir.
SK-mantık

14

JSON ve XML, verileri biçimlendirmenin her iki yoludur. Her ikisi de mükemmel bir şekilde yapabiliyor, JSON XML'in yaptığı her şeyi yapabilir mi? Evet.

Fakat ..... Daha alakalı bir soru, XML / JSON'un yapabilecekleri olmayabilir, aksine XML / JSON ile neler yapabilirsiniz .

Yapabileceğiniz birçok şey vardır ile böyle, XLST ile tercüme XPath ile arama ve şemalar ile doğrulamak gibi ben JSON ile yapabilirsiniz sanmıyorum XML,. Hepsi çok, çok kullanışlı.


5
Verilerin etiket içerdiği karışık içerik hariç. JSON bunu pek iyi yapmaz.
S.Lott

11

JSON ile mümkün olmayabilir XSLT kullanarak bir çok işlevsellik vardır . Dolayısıyla, eğer işlevsel olarak eşdeğer değilse, birbirlerinin yerini alamazlar.


3
Bununla birlikte, JSON'u seri hale getirmek, işlemek ve seri hale getirmek için başka bir dil kullanabileceğinizi ve XSLT'nin XML olmadığını, bu yüzden bu noktanın çok fazla olduğunu söyledi.
StuperUser

3
XSLT olan XML - şemasını görmek burada
treecoder

Teşekkürler @greengit, sadece kısa bir maruz kaldım, yanıtı güncelledim.
StuperUser

2
@StuperUser: JSON ile nasıl "imkansız" olabilir ? Bu sadece bir dönüşüm, belki araçlar henüz yok. Yoksa sorun JSON'daki niteliklerin eksikliğinden mi kaynaklanıyor?
maaartinus 20:11

1
@StuperUser: XSLT, bazı tercümanların en az bir başka dilde (muhtemelen C, Java, ...) yazılmış olduğu bir dildir (XML alt kümesi). Aynı şey JSON için de yapılabilir (bazı JSON-T tanımlayın, tercümanı yazın), değil mi?
maaartinus 20:11

8

Gerçek şu ki, her ikisiyle de uzun süre yaşamak zorunda kalacağız ve bir JSON bigotu olmak “zararlı” olarak kabul ediliyor.


7

JSON oldukça yeni ve eski sistemler onu desteklemeyecek. Yükseltme miras sistemleri açıktır ve hataları ortaya çıkarır. JSON yakın gelecekte herhangi bir zamanda XML'in yerini almayacaktır.


2
cevabın için teşekkürler. Aklımda olan şey, bir uygulama stratejisinden ziyade teknik bir inceleme. Sadece bilmek istiyorum, örneğin bu eski sistemlerin yeni sürümleri için, XML'i tamamen bırakıp JSON kullanabilir miyiz? Değilse, JSON'da neyi özlüyoruz?
Saeed Neamati 16:11

Öte yandan, son birkaç yıldır hiçbir JS, sadece JSON kullanmadım. Ve iyi kurtuluş. Tabii ki, XML daha girişimcidir. Bu, iş güvenliği için mükemmel, verimlilik için çok iyi değil.
gnasher729

6

Cwallenpoole'un mükemmel bir noktaya geldiğini söyleyebilirim. En XML iken edebilir JSON çevrilemez, bunu yaparken bunun için daha iyi olup olmadığı ayrı bir noktadır.

JSON, kendisini en az XML kadar veri yapılarına borçludur, ancak daha iyi, ancak XML, hiyerarşiyi sınırlandırmanın bir yolu olarak değil, daha büyük bir metin akışında kullanılan metin belgelerini işaretlerken, JSON'dan çok daha doğal bir şekilde okunur. Alanların

Her ne kadar HTML 5 kendi ayrıştırıcısına sahip olsa da, yine de DocBook gibi uygulamaları bırakır.


JSON, açıkça HTML içerebilen dizeler içerebilir.
gnasher729

6

Etki alanına göre değişir. Web servisleri açısından? Kesinlikle. Tedarikçilerin hala SOAP'ı müşterileri için zorluyor olması utanç verici. REST + JSON sonuna kadar.

Şimdi, Docbook veya başka bir uygulama gibi stil bilgisine sahip karmaşık, yapılandırılmış verilerden bahseder misiniz? XML için uygun bir alan.


4

YAML süper bir set ve çok daha anlamlı ve bu nedenle XML veya JSON'dan daha güçlü olduğunda neden kendinizi JSON ile sınırlandırın.

Bununla birlikte, doğru serileştirme çerçevelerini kullanırsanız, yukarıda bahsedilen tüm biçimleri birkaç basit kod satırıyla seri hale getirip serileştirmeniz gerekir.


3

Bu iki nesneyi JSON'da modellemeye çalıştığınızda çirkinleşir:

<customer><name>John Doe</name></customer>
<employee><name>John Doe</name</employee>

JSON'u, kullanıldığı gibi% 99 durumlarda kullandığı gibi kullanmak:

{ name: "John Doe" } 

Ve şimdi bazı meta yapılar eklemelisiniz ve siz dezavantajlı olduğunuzda JSON'un tüm güzelliği ortadan kalktı.


11
Sağladığınız XML'ine eşdeğer JSON { customer: { name: 'John Doe' }, employee : { name: 'John Doe' } }. Yani teknik olarak, cevabınız doğru değil. :)
Saeed Neamati 20:11

Tabii ki, JSON'da eksik olan tek şey özelliklerdir ve nesnelerin modellenmesinde yararsızlık vardır (işaretlemenin aksine). Bazen nitelikler, iç içe geçmiş veriler kullanılarak ifade edilebilecekler için kısayol olarak kullanılır (örneğin, Hazırda Bekletme yapılandırma dosyalarında), ancak kullanışlı olan, ancak seçimin varlığı onu zorlaştırır. Config dosyaları ve modelleme nesneleri, JSON'un açıkça üstün olduğu iki yerdir.
maaartinus

2
@SaeedNeamati, JSON'da nasıl model olur <customer><name>John Doe</name></customer><customer><name>John Doe</name></customer>?
svick,

6
{müşteriler: [{isim: 'John Doe'}, {isim: 'John Doe'}]}?
scrwtp

2
@Stijn - doğru ve bu işe yarıyor, ancak orijinal yanıttan gelen, XML'de daha doğal olarak ortaya çıkan bazı şeyleri modellemek için "bazı meta yapılar eklemelisiniz" yorumunu doğrular.
Matt R,

3

JSON için böyle bir tesis olup olmadığını bilmiyorum, ancak .NET'te en azından XML'i verilen bir şemaya göre doğrulayabilirsiniz. Bu benim gözlerimdeki XML'in değerli bir avantajı.


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.