Czy możemy całkowicie zastąpić XML JSON? [Zamknięte]

78

Jestem pewien, że wielu programistów zna XML i JSON i korzystali z nich obu. Dlatego nie ma sensu wyjaśniać, czym są i jaki jest ich cel, nawet w skrócie.

Jeśli spróbujemy zmapować ich koncepcje, możemy powiedzieć (popraw mnie, jeśli się mylę):

  1. Tagi XML są równoważne JSON {}
  2. Atrybuty XML są równoważne właściwościom JSON
  3. Kolekcja znaczników XML jest równoważna JSON []

Jedyną rzeczą, o której mogę myśleć, która nie istnieje w JSON, jest Przestrzenie nazw XML .

Pytanie, biorąc pod uwagę to mapowanie i biorąc pod uwagę, że JSON jest znacznie lżejszy w tym mapowaniu, czy możemy zobaczyć świat w przyszłości (lub przynajmniej teoretycznie myśleć o świecie) bez XML, ale przy JSON robiącym wszystko, co robi XML? Czy możemy używać JSON wszędzie tam, gdzie używany jest XML?

PS: Pamiętaj, że widziałem to pytanie. To coś zupełnie innego niż to, o co tutaj pytam. Dlatego proszę nie wspominać o duplikacie .

Saeed Neamati
źródło
14
Oczywiście możemy (i powinniśmy) zastąpić wszystkie te przesadnie źle zaprojektowane rzeczy wyrażeniami S. Świat bez XML byłby rzeczywiście o wiele lepszym miejscem, ale to niestety nic innego jak myślenie życzeniowe.
SK-logic
19
Ugh. Nienawidzę tych pytań. Myślę, że tak naprawdę jest to przypadek użycia odpowiedniego narzędzia do pracy, a nie tego, czy można całkowicie wymienić inne. Na świecie jest tak mało absolutów, nawet z komputerami. Nie mogłem sobie wyobrazić robienia rzeczy z JSON, przynajmniej w miejscu, w którym obecnie stoją odpowiednie technologie.
Philip Regan,
2
@ Filip, to nie jest pytanie o wyburzenie czegoś. Po prostu próbuje zobaczyć, czego brakuje JSON, abyśmy mogli to poprawić. :)
Saeed Neamati,
4
Dyskusja na temat różnic między dwiema technologiami, aby zobaczyć, gdzie można wprowadzić ulepszenia, różni się bardzo od pytania, czy jedną można zastąpić drugą. Ta pierwsza jest bardziej naukową recenzją niż druga, która wydaje się bardziej antagonistyczna z frustracji niż cokolwiek innego
Philip Regan
12
To nie jest hipotetyczne. Wydaje się, że w JSON brakuje funkcji, którą posiada XML.
S.Lott,

Odpowiedzi:

153

To, co daje XML swoją moc i dużą złożoność, to mieszana zawartość. Takie rzeczy:

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

Nawet nie próbuj tego robić w JSON, ani nie manipuluj nim w konwencjonalnych językach programowania. Nie zostały zaprojektowane do tego zadania.

Tego rodzaju pytanie zazwyczaj pochodzi od ludzi, którzy zapominają, że M w XML oznacza znaczniki. Jest to sposób pobierania zwykłego tekstu i dodawania znaczników w celu utworzenia tekstu strukturalnego. Jest to dość przydatne w przypadku danych staromodnych, ale nie do tego zostało przeznaczone ani do tego, gdzie leżą jego główne zalety. Istnieje wiele sposobów obsługi prostych danych, a JSON jest jednym z nich.

Michael Kay
źródło
33
+1: Jest to cecha wyróżniająca. Doskonały punkt
S.Lott,
7
@Michael, właśnie nauczyłeś mnie czegoś cennego. To świetna odpowiedź. +1.
Saeed Neamati,
9
.... Istnieją 3 węzły niezależne od P, A elementu B i „bałagan jesteśmy!”. Jest to tablica, którą można po prostu wyjaśnić w JSON.
Incognito,
5
@Rob Nie, ale wyjaśniam, że można zdefiniować rzeczy wyrażone przez HTML z większą jasnością i być może szybsze parsowanie za pomocą JSON (ponieważ mniej parsowania tekstu jest wymagane, aby znaleźć różne typy węzłów). Gdyby HTML był JSON-ML, moglibyśmy mieć więcej programistów, którzy faktycznie rozumieją DOM, węzły tekstowe i powiązania.
Incognito,
5
@ByrneReese: tak, to XML i tak, jest poprawny. To, że jest to również HTML, nie ma znaczenia; w rzeczywistości XHTML jest również poprawnym XML. :-)
Martijn
31

Główną różnicą, jak sądzę, jest fakt, że XML jest zaprojektowany tak, aby sam się wyjaśniał z jego dtd i wszystkim.

Z JSON musisz założyć dużo na temat danych, które otrzymujesz.

Maarten van Leunen
źródło
7
„XML został zaprojektowany tak, aby sam się wyjaśniał”. Czy możesz podać link lub odniesienie do tego? Nie widzę tego w standardach W3C dla XML i zastanawiam się, skąd się to bierze. Wydaje mi się, że miejska legenda jest czymś więcej niż wyznaczonym celem projektowym.
S.Lott,
6
@ S.Lott: Myślę, że przez to rozumie naturę znaczników XML, które same w sobie pozwalają na to, aby oznakowane treści były zrozumiałe, tzn. DTD są opcjonalne, więc dobrze sformułowany XML może zostać przeanalizowany bez niego. Ale zgadzam się z twoim podejściem do tej kwestii, ponieważ technicznie JSON ma takie same możliwości, więc nie widzę, że główna wyjaśnienie jest w ogóle główną różnicą (nie jestem pewien, dlaczego to wciąż się głosuje), ale raczej Michael Kay jest bardziej naznaczony.
Philip Regan,
5
@ S.Lott zgodził się. Muszę powiedzieć, że JSON tutaj json.org/example.html jest łatwiejszy do zrozumienia i lepiej udokumentowany niż związany z nim XML ze względu na brak szczegółowości.
Doug T.
4
@Michael Borgwardt: Bez pełnego XSD (w tym wsparcia ontologii) nazwy znaczników nic mi nie mówią. „znaczący” jest ogólnie trudny do osiągnięcia. To nie wyjaśnia, co w odpowiedzi powinno oznaczać „samo wyjaśnianie się”. I nie mam dowodów, że był to nawet cel projektowy dla XML.
S.Lott,
4
@Philip Regan: Podobnie jak w przypadku „kodu wyjaśniającego”, wydaje się, że nie jest to cecha XML. Jeśli jest to tylko uniwersalny cel implementacji, który dotyczy wszystkich języków oprogramowania (kodu, dostępu do danych, znaczników, cokolwiek), być może ludzie nie powinni wspominać o XML.
S.Lott,
21

Dosłowne tłumaczenie na JSON jest często mniej zwięzłe i mniej jasne. Rozważać:

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

Najbardziej efektywna reprezentacja JSON, jaką widziałem:

{"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"}
         ]
     }
 ]}

Teraz wyobraź sobie to dla całego pliku XML. Nie twierdzę, że JSON nie ma swojego miejsca, ale XML nie powinien być wykluczony.

cwallenpoole
źródło
8
Rozważmy teraz SXML:(foo (x:bar (@ (x:prop1 "g")) (quuz)))
SK-logic
2
@ SK-Logic: To świetne na trywialny przykład, ale nie wyobrażam sobie wykonywania głęboko zagnieżdżonych, mieszanych treści - takich jak książka - z tym. Myślę, że SXML jest tak samo akademickim ćwiczeniem jak cokolwiek innego.
Philip Regan,
3
@Philip Regan: Jak pisać S-Exp trudniej niż przy użyciu chevronitis, skoro jest to trywialna transformacja 1: 1 w mniej pełną formę?
maaartinus
@maartinus: Moją specjalizacją jest publikowanie książek: wszelkiego rodzaju podręczniki to głębokie, złożone bestie z szeroką gamą treści, które wymagają wyraźnego zarządzania. DocBook i DITA są znacznie bardziej czytelne niż przykład podany powyżej.
Philip Regan,
1
@Philip Regan, SXML jest bardzo łatwy do edycji, zupełnie inaczej niż XML. I oczywiście jest to znacznie lepszy wybór dla protokołów, nie trzeba wspominać o wyższości dostępnych narzędzi.
SK-logic
14

JSON i XML to oba sposoby formatowania danych. Oba są w stanie zrobić to doskonale, więc czy JSON może zrobić wszystko, co robi XML? Tak.

Ale ... Bardziej trafnym pytaniem może nie być to, co może zrobić XML / JSON , ale raczej, co możesz zrobić z XML / JSON.

Jest kilka rzeczy, które możesz zrobić za pomocą XML, ale nie sądzę, że możesz to zrobić za pomocą JSON, takie jak tłumaczenie za pomocą XLST, wyszukiwanie za pomocą XPath i sprawdzanie poprawności za pomocą schematów. Wszystko bardzo, bardzo przydatne.

Qwerky
źródło
5
Z wyjątkiem treści mieszanych, w których dane zawierają tagi. JSON wcale nie radzi sobie tak dobrze.
S.Lott,
11

Przy użyciu XSLT istnieje wiele funkcji, które mogą nie być możliwe w JSON. Jeśli więc nie są funkcjonalnie równoważne, nie mogą się zastąpić.

StuperUser
źródło
3
To powiedziawszy, możesz użyć innego języka do deserializacji, manipulowania i serializacji JSON, a XSLT nie jest XML, więc ten punkt jest naprawdę dyskusyjny.
StuperUser
3
XSLT to XML - zobacz schemat tutaj
treecoder
Dzięki @greengit, miałem tylko krótki opis, zaktualizowałem odpowiedź.
StuperUser
2
@StuperUser: Jak to może być „niemożliwe” z JSON? To tylko transformacja, być może brakuje narzędzi. Czy problem związany jest z brakiem atrybutów w JSON?
maaartinus,
1
@StuperUser: XSLT jest językiem (podzbiorem XML), dla którego niektórzy tłumacze napisani byli w co najmniej jednym innym języku (prawdopodobnie w C, Java, ...). To samo można zrobić dla JSON (zdefiniować JSON-T, napisać interpreter), prawda?
maaartinus,
8

Faktem jest, że będziemy musieli z nimi długo żyć, a bycie bigotem JSON jest „uważane za szkodliwe”.

Scott C. Wilson
źródło
7

JSON jest dość nowy, a starsze systemy go nie obsługują. Uaktualnianie starszych systemów jest czasochłonne i wprowadza błędy. JSON w najbliższej przyszłości nie zastąpi XML.

Tom Squires
źródło
2
dzięki za odpowiedź. Mam na myśli przegląd techniczny, a nie strategię wdrażania. Chcę tylko wiedzieć, na przykład, czy w przypadku nowych wersji starszych systemów możemy całkowicie upuścić XML i użyć JSON? Jeśli nie, czego brakuje nam w JSON?
Saeed Neamati,
Z drugiej strony w ciągu ostatnich kilku lat nie korzystałem z XML-a, tylko JSON. I dobra gra. Oczywiście XML jest bardziej przedsiębiorczy. Co jest świetne dla bezpieczeństwa pracy, a nie dla wydajności.
gnasher729
6

Powiedziałbym, że cwallenpoole stanowi doskonały punkt. Podczas gdy większość XML może przetłumaczyć na JSON, to czy jest to lepsze, ponieważ jest to osobny punkt.

JSON nadaje się do struktur danych przynajmniej tak dobrze jak XML i prawdopodobnie lepiej, ale XML odczytuje znacznie bardziej naturalnie niż JSON podczas oznaczania dokumentów tekstowych, w których znaczniki są używane w większym przepływie tekstu, a nie po prostu jako sposób na ograniczenie hierarchii pól.

Chociaż HTML 5 może mieć własny analizator składni, nadal pozostawia aplikacje takie jak DocBook.

ssokolow
źródło
JSON może oczywiście zawierać ciągi znaków, które mogą zawierać HTML.
gnasher729
6

To zależy od domeny. W zakresie usług sieciowych? Absolutnie. To absolutnie wstyd, że dostawcy wciąż naciskają SOAP na swoich klientów. REST + JSON do końca.

Teraz, kiedy mówisz o złożonych, ustrukturyzowanych danych z informacjami o stylu, takimi jak Docbook lub inna implementacja? To jest właściwa domena dla XML.

Jason Lewis
źródło
4

Po co ograniczać się do JSON, gdy YAML jest super zestawem i jest o wiele bardziej ekspresyjny, a zatem potężniejszy niż XML lub JSON.

To powiedziawszy, jeśli użyjesz poprawnych ram serializacji, powinieneś być w stanie serializować i usuń serializację wszystkich wyżej wymienionych formatów za pomocą kilku prostych linii kodu.


źródło
3

Robi się brzydko, gdy próbujesz modelować te dwa obiekty w JSON:

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

Używając JSON, jak to jest przyzwyczajone w 99% przypadkach, gubisz się z:

{ name: "John Doe" } 

A teraz musisz dodać meta-struktury, a całe piękno JSON zniknęło, gdy pozostaniesz z wadami.

Michał Till
źródło
11
odpowiednikiem JSON do dostarczonego pliku XML jest { customer: { name: 'John Doe' }, employee : { name: 'John Doe' } }. Więc technicznie twoja odpowiedź jest nieprawidłowa. :)
Saeed Neamati,
Jasne, jedyne, czego brakuje w JSON, to atrybuty i są one bezużyteczne do modelowania obiektów (w przeciwieństwie do znaczników). Czasami atrybuty są używane jako skrót do tego, co można wyrazić za pomocą zagnieżdżonych danych (np. W plikach konfiguracyjnych Hibernacja), co jest przydatne, ale w rzeczywistości istnienie wyboru utrudnia. Pliki konfiguracyjne i obiekty modelujące to dwa miejsca, w których JSON jest wyraźnie lepszy.
maaartinus,
2
@ SaeedNeamati, więc jak byś modelował <customer><name>John Doe</name></customer><customer><name>John Doe</name></customer>w JSON?
svick,
6
{klienci: [{nazwa: „John Doe”}, {nazwa: „John Doe"}]}?
scrwtp
2
@Stijn - prawda, i to działa, ale potwierdza komentarz z oryginalnej odpowiedzi, że „musisz dodać jakieś meta-struktury”, aby modelować pewne rzeczy, które wypadają bardziej naturalnie w XML.
Matt R
3

Nie wiem, czy takie narzędzie istnieje dla JSON, ale w .NET przynajmniej możesz sprawdzić poprawność XML pod danym schematem. To cenna zaleta XML w moich oczach.

Grant Palin
źródło
2
json ma również schematy: json-schema.org
lordvlad