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

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 .

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.

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.

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.

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.

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ć.

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

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.

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.

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.

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.

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.

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.