Ankieta: XML vs JSON

0

Mam pytanie, dla kogo bardziej przejrzyste i łatwe do użytku są dane zapisane w formacie tekstowym XML czy JSON?
Chodzi mi głównie o zapis danych, głównie w backendie jak również w aplikacjach offline i frontendowych, tworzenie tekstowych interfejsów użytkownika, przenoszenie danych między komputerami a także zapisywanie informacji takich jak style tekstu, animacje (tu mamy HTML ale możliwości tego języka są ograniczone i czasem trzeba zapisać informacje o obiektach w aplikacji w inny sposób).
Proszę o uzasadnienie swoich odpowiedzi i nie pisanie odpowiedzi typu "a ja tam wolę formaty binarne" bo to zupełnie inna kategoria.

1

json

0

To zależy, w jednych sytuacjach lepiej sprawdzi się JSON, a w innych XML. Osobiście preferuję JSONa, bo dziecinnie łatwo się go parsuje w Pythonie i JSie, a poza tym jest bardziej przejrzysty z uwagi na małą ilość znaków specjalnych poza danymi i powoduje to też, że rozmiar pliku jest mniejszy. Z kolei jakbym miał projekt z dużym zagnieżdzeniem i skomplikowanymi danymi, rozważyłbym XML.

0

Jsona można dopasować do typów danych większości języków, więc nie ma żadnego overheadu (array/assotiative w php, list/dict w Pythonie, array/object w js, list/map w Javie, etc.). XML wymagałoby dodatkowego poziomu na zagniezdzenia i atrybuty.

XML jest bardziej odporny na syntax errory, bo w atrubytach nie trzeba encodować < ani >, za to w body nie trzeba encodować ' ani ".

Jsona (czy yamla, na dobrą sprawę) można łatwo napisać z palca, XML' ciężej.

XML jest odporny na błędy markupu, bo np widząc jasno że tutaj:

<a><b>1<c>2</b>3</a>

Że brakuje domkniecia <c>, i 3 jest w <a>. Z json'em:

[1, [2, [3]]

Juz tak łatwo nie zgadniesz który array jest niedomknięty.

Do plików XML dostępnych jest dużo rozwiązań które pozwalają szukać elementów np selectorami.

Do XML można napisać scheme (np w htmlu, elementy <li> mogą być tylko w <ul>/<ol>). W jsonie jest tylko array/object, więc takiej walidacji sobie już nie napiszesz i każdy obiekt może być w każdym innym.

Jak plik jest ogromny, to w XML łatwiej się połapać bo tagi mają swoje nazwy. W jsonie możesz się najwyżej sugerować kluczami m

To tylko takich kilka które mi przyszły do głowy. Jak widać mają swoje wady i zalety. Musisz wybrać format pod Twoje wymagania.

3

A do czego chcesz tego formatu używać?

  • Wymiana danych pomiędzy systemami, które kontrolujesz - ProtoBuff, Cap'n'Proto, ETF, MsgPack, inne binarne protokoły
  • Wymiana danych pomiędzy systemami, których nie kontrolujesz - JSON, XML
  • Standaryzacja protokołu - ASN.1
  • Pliki konfiguracyjne - TOML, YAML, HCL, UCL, JSON5, HSON
  • Pliki zapisane lokalnie - SQLite, Pickle, Ruby Marshal, DETS/ETF
0

Muszę przyznać, że czytelność dla człowieka to chyba jeden z tych aspektów, które rozważyłbym w ostatniej kolejności.

3
Charles_Ray napisał(a):

Muszę przyznać, że czytelność dla człowieka to chyba jeden z tych aspektów, które rozważyłbym w ostatniej kolejności.

A ja w pierwszej. :)

0

Jeśli to ma byc forma komunikacji np. w API Restowym to czytelność moim zdaniem jest mega istotna poniewaz ułatwia debugowanie pisanie testów itp

2

Ja wolę Jasona bo fajne filmiki o nim kręcą w Grudziądzu.

1

JSON do serializacji obiektów. XML do rzeczy HTMLopodobnych (tam, gdzie jakieś Markdowny są zbyt prymitywne).

2

Josn, ponieważ nie jako sam siebie opisuję, każde pole jest nazwane, zero filozofi.
Natomiast formaty a'la xml można w sobie zagnieżdżać., co powoduje kilka problemów.
Zagnieżdżać można ale, tylko kierując się arbitralną logika którą miał w głowie autor, a która rzadko wynika z formatu samego z siebie. To co ustawiamy w zagnieżdżaniach nie jest w żaden sposób nazwane lub ma jaką generyczną nazwę. To tylko pogłębia problem, bo nie my żadnej podpowiedzi co tak naprawdę robimy, żadnej. Kulminacją obu wad jest to że raz ustawiamy tablice elementów, raz jeden element,raz jakiś atrybut np. text, a czasami zupełnie coś innego, bo czemu nie? Przecież do niczego się nie zobowiązaliśmy. W json problem nie występuje, bo jasno pokazujemy jaki atrybut ustawiamy, oraz czy to kolekcja czy nie.

4

Josn, ponieważ nie jako sam siebie opisuję

Co? Przecież JSON dalej nie ma ustandaryzowanego formatu do opisu danych z jakich się składa. Są próby jak JSON Schema do formatu czy JSON-LD do danych, ale dalej powszechnego użycia za bardzo nie widać. Natomiast XML od dawna ma DTD oraz XMLNS.

Natomiast formaty a'la xml można w sobie zagnieżdżać., co powoduje kilka problemów.

Nie wiem co rozumiesz, przez "formaty a'la xml można w sobie zagnieżdżać" ale dokładnie to samo można robić w JSONie.

W json problem nie występuje, bo jasno pokazujemy jaki atrybut ustawiamy, oraz czy to kolekcja czy nie.

No jakoś tego nie widzę, zwłaszcza w związku z rzeczami w pierwszym akapicie. Akurat to trzeba oddać XMLowi, że standard dot. specyfikacji zawartości dokumentu XML jest zdecydowanie częściej używany.


XML is almost always misused.

1

@hauleth

Co? Przecież JSON dalej nie ma ustandaryzowanego formatu do opisu danych z jakich się składa/

Chyba piszemy o 2 rożnych kwestiach taki xml like format, gubi informacje o tym co tak naprawdę ustawiamy, json gubi informacje o typie elementów

<UserControl>
    <TextBox/>
</UserControl>

Nie sposób zgadnąć co tak naprawdę ustawiliśmy, innerHTML?, Childrens, Content?

{
   ChildControl: "{}"
}

Tu z kolei widzimy jakie atrybuty ustawiamy, za to tracimy informacje, czym jest root, i co siedzi, w ChildControl.

Teoretycznie niby gorzej. W praktyce znamy jednak znamy kontekst i nie jest tak źle. Wiemy czym jest root, wiemy że child control może być tylko jedno i możemy się domyślić ze to dowolna kontrolka a nie tylko textbox. Przykład wyżej to najgorszy przypadek jaki umiem sobie wyobrazić Nie spotkałem sie z czym takim. Większość ludzi formatuje dane tak że można się domyślić co z czym jeść.

Natomiast problem podtytułem czy to niżej jest poprawne czy nie? nęka mnie regularnie i można to sprawdzić tylko dostając errora na twarz.

<UserControl>
    <TextBox/>
   <TextBox/>
</UserControl>

Ed. piszac ten post zmieniłem zdanie i myślę że przewaga jednego nad drugim zależy od zastosowania.

0

Dla szybkiego zapisania prostych danych jak punkty w grze on-line, ustawienia JSON (albo INI, w prypadku gry offline)
XML przydaje się do bardziej złożonych danych (np. mediów społecznościowych) z uwagi na możliwość wygodnego notowania bloków tekstu.
Ogółem jednak XML, chociaż trzeba wspomnieć o gotowcach do parsowania JSON.

0
_flamingAccount napisał(a):

Chyba piszemy o 2 rożnych kwestiach taki xml like format, gubi informacje o tym co tak naprawdę ustawiamy, json gubi informacje o typie elementów

<UserControl>
    <TextBox/>
</UserControl>

Nie sposób zgadnąć co tak naprawdę ustawiliśmy, innerHTML?, Childrens, Content?

{
   ChildControl: "{}"
}

Nie widzę sensu w takim porównaniu. Jedyny powód jaki mogę znaleźć, to gdybyś chciał znaleźć "boski format" który działa wszędzie, i próbujesz wymyślić czy to jest XML czy JSON. Co oczywiście jest bzdurą (każdy ma swoje zastosowanie).

Teoretycznie niby gorzej. W praktyce znamy jednak znamy kontekst i nie jest tak źle. Wiemy czym jest root, wiemy że child control może być tylko jedno i możemy się domyślić ze to dowolna kontrolka a nie tylko textbox. Przykład wyżej to najgorszy przypadek jaki umiem sobie wyobrazić Nie spotkałem sie z czym takim. Większość ludzi formatuje dane tak że można się domyślić co z czym jeść.

Przecież program, który dostaje takiego JSON'a/XML'a nie musi "czytać" tego co tam jest. Program jest zaprogramowany rozpoznawać np. wartość w ChildControl jako jedną z tych które wymieniłeś.

A jeśli chodzi Ci o to że ludzie, którzy go czytają (nie zaznajomieni z tym jak ten program działa) nie będą w stanie się domyślić czym są dane, po pustym obiekcie - no to fakt, ale co z tego? Nie dla ludzi są te formaty.

Ed. piszac ten post zmieniłem zdanie i myślę że przewaga jednego nad drugim zależy od zastosowania.

No way.

0
_flamingAccount napisał(a):

Nie sposób zgadnąć co tak naprawdę ustawiliśmy, innerHTML?, Childrens, Content?

Na początek zacznijmy od rozróżnienia API do pracy z danym formatem od formatu. w podanym przykładzie ustawiały dzieci UserControl. To jak się potem będziesz do nich odnosił, to zupełnie inna sprawa, zupełnie nie związana z samym formatem (bo oprócz DOM mamy jeszcze np. SAX gdzie to wygląda jeszcze inaczej).

Ed. piszac ten post zmieniłem zdanie i myślę że przewaga jednego nad drugim zależy od zastosowania.

Dokładnie, jak we wszystkim.

0

@hauleth

Na początek zacznijmy od rozróżnienia API do pracy z danym formatem od formatu.

Dlaczego? Temat jest xml vs json uważam że xml jest słaby bo słabo sie z nim pracuje i są to kwestię nie rozłączne.

To jak się potem będziesz do nich odnosił, to zupełnie inna sprawa, zupełnie nie związana z samym formatem

To że jest to nie związane z formatem uważam za wadę. Skoro format tego nie określa to zostawia to kwestie do interpretacji. która następuję jak ktoś pisze kod wykorzystujący xml. Czasem masz kod który ustawia, tablice, czasem pojedynczy element, czasem atrybuty. Nie da się zgadnąć implementacji patrząc na xml.

Jeśli problem da sie rozwiązać logicznie, stosujac json'a to wybrał by go zamiast xml'a bo nie ma takich problemów.

w podanym przykładzie ustawiały dzieci UserControl

Tu złośliwie sie przyczepie nie ustawiamy dzieci, w liczbie mnogiej, tylko jedno dziecko, co widać w json'ie.

@TomRiddle

Nie widzę sensu w takim porównaniu. Jedyny powód jaki mogę znaleźć, to gdybyś chciał znaleźć "boski format" który działa wszędzie, i próbujesz wymyślić czy to jest XML czy JSON. Co oczywiście jest bzdurą (każdy ma swoje zastosowanie).

A po co mi "boski format"?
Ja uważam że xml gubi informacje o ustawianym atrybucie/atrybutach, a json o typie ustawianych elementów. I że między inny mi z tych cech wynika który działa w danych okolicznościach lepiej. xml

A jeśli chodzi Ci o to że ludzie, którzy go czytają (nie zaznajomieni z tym jak ten program działa) nie będą w stanie się domyślić czym są dane, po pustym obiekcie - no to fakt, ale co z tego? Nie dla ludzi są te formaty.

Nie. Te formaty sa dedykowane dla ludzi. Binarni, bloby, i skompresowane są lżejsze, routery i inne powszechnie używane urządzenia świetlenie sobie z nimi radzą. Za to w api nie są wykorzystywane prawie nigdy. Dlaczego? bo nie da się ich czytać i praca z nimi to katorga.

ed.

A jeśli chodzi Ci o to że ludzie, którzy go czytają (nie zaznajomieni z tym jak ten program działa)

Z reguły jak musze czytać json'a ma to miejsce wtedy gdy nie wiem jak program działa, bo albo używam api dostarczone przez kogoś innego albo pisze swój program który jeszcze nie wiem jak działa bo go nie skończyłem, albo hakuje coś ad hoc. Wiec to dość popularny przypadek.

2
_flamingAccount napisał(a):

To że jest to nie związane z formatem uważam za wadę. Skoro format tego nie określa to zostawia to kwestie do interpretacji. która następuję jak ktoś pisze kod wykorzystujący xml. Czasem masz kod który ustawia, tablice, czasem pojedynczy element, czasem atrybuty. Nie da się zgadnąć implementacji patrząc na xml.

Nie trzeba zgadywać, można wiedzieć. Słyszałeś o XSD?

Nie. Te formaty sa dedykowane dla ludzi.

Też się złośliwie przyczepię - przeznaczane, jeżeli już. :)

1

To że jest to nie związane z formatem uważam za wadę.

Pomijając, że Ty właśnie dałeś niepoprawnego JSONa, gdzie ustawiasz stringa a nie strukturę

{
   ChildControl: "{}"
}

zapewne miało być:

{
   "ChildControl": {}
}

To czy Ty widziałeś kiedyś np. API do JSONa w takich językach silnie typowanych?

let document = json::parse(r#"{"ChildControl": {}}"#);

let child_control = 
  document
    .get("ChildControl").ok_or(Err(InvalidField))
    .as::<HashMap<String, String>>().or_else(|_| Err(InvalidField));

Skoro format tego nie określa to zostawia to kwestie do interpretacji.

Nie, format konkretnie definiuje jak to ma wyglądać. Każdy element to krotka:

{elem_name, [elem_attr], [elem_children]}

Co wyraźnie pokazuje, że zawsze masz listę. To jak to API potem Tobie przedstawi to już Twój wybór API oraz jak z nieko korzystasz. To jak są dane przedstawione wewnątrz dokumentu również możesz zdefiniować przy pomocy DTD, spójrz na XHTML na przykład. Spójrz na artykuł, który wstawiłem wyżej nt. XMLa.

Jeśli problem da sie rozwiązać logicznie, stosujac json'a to wybrał by go zamiast xml'a bo nie ma takich problemów.

Za to ma całe mnóstwo innych problemów, o których też mówiłem wyżej. Np.

{
  "time": "2020-01-12T18:23:54+01:00"
}

Dla człowieka coś znaczy, dla maszyny nic a nic. Natomiast jeśli weźmiemy sobie XMLa:

<post vocab="http://schema.org/" typeof="Event">
  <time property="startTime">2020-01-12T18:23:54+01:00</time>
</post>

To maszyna również może to odczytać, jeśli umie w https://schema.org.

Oczywiście w JSONie też można coś takiego ogarnąć, ale obecnie mamy 2 standardy, które ze sobą walczą:

  • JSON-LD, które jest rekomendacją W3C
  • JSON HAL, które zostało zgłoszone jako RFC

A jak się przyjrzysz, to JSON-LD się opiera na FOAF, które jest zdefiniowane głównie w XMLu.


Więc jeśli chcemy się kłócić o API a nie o format, to jestem w stanie zrobić Ci tak koszmarne API do JSONa, że nikt nie będzie w stanie się nim posługiwać. W tym samym czasie mamy XPath, które jest stosunkowo przyjemne (dla JSONa również istnieje coś podobnego, ale ponownie, nie ma jednego standardu tylko przynajmniej 2-3).

JSON jest przyjemniejszy i zwięźlejszy, to trzeba mu w 100% oddać, ale nie szerz herezji, że jest w jakiś sposób "lepiej opisujący" dane, bo to kłamstwo.

I jeszcze raz powtórzę - oddziel API do obsługi od samego standardu dokumentu, bo JS to nie jedyny język jaki istnieje a DOM to nie jedyny sposób na przetwarzanie danych zapisanych w XMLu.

0

Nie trzeba zgadywać, można wiedzieć. Słyszałeś o XSD?

A jak nie jest w tym formacie? albo jak ktoś zagnieździ svg w html (2 dni temu wciągiem dane z czegoś takiego) albo zbuduje mini-framework xml do ustawiania UI(takie coś też widziałem), albo xaml od microsotu, lub zrobi cokolwiek dziwnego, to czar pryska. O wszem można dobrze rozwiązać wszystko tak żeby działało sprawnie i bez problemu oraz nie jest to trudne. Zgadzam się. Ale jak z jakichkolwiek przyczyn się to nie uda, to trzeba zgadywać co autor miał na myśli.

to jestem w stanie zrobić Ci tak koszmarne API do JSONa,

To żaden argument, nawet hello word, w consoli mozna wyświetlic ksozmarnie.

Skoro format tego nie określa to zostawia to kwestie do interpretacji.
Nie, format konkretnie definiuje jak to ma wyglądać. Każdy element to krotka:{elem_name, [elem_attr], [elem_children]}
Co wyraźnie pokazuje, że zawsze masz listę. To jak to API potem Tobie przedstawi

Zgoda. W formacie zawsze masz krotkę i format nie nie się w sobie informacji o implementacji. Zgoda. Czyli mówimy o tym samym, bo właśnie ta właściwość że teoretycznie można dodać kilka elementów a w praktyce niekoniecznie mnie denerwuje.

Za to ma całe mnóstwo innych problemów, o których też mówiłem wyżej. Np.

{
"time": "2020-01-12T1854+01:00"
}

Dla człowieka coś znaczy, dla maszyny nic a nic. Natomiast jeśli weźmiemy sobie XMLa:>

 <time property="startTime">2020-01-12T18:23:54+01:00</time>
</post>

Manipulujesz w swoim przykładzie, bo nie przekazujesz tej samej ilości informacji w przykładach, json powinien wygladać tak, by był równoważny.

{
     "vocab":"http://schema.org/",
     "typeof":"Event",
      "time":{
                   "property":"startTime",
                   "value":"2020-01-12T18:23:54+01:00"
                 }
}

W json zgubiona została informacja że to jest post, w xml nazwa atrybutu przechowującego czas. Wynika to wprost ze sposobu zapisu i tak będzie zawsze niezależnie od standardu. Oczywiście do jedno i drugie można zapisać tak by przekazać wszystko, ale to inna kwestia.

JSON jest przyjemniejszy i zwięźlejszy, to trzeba mu w 100% oddać, ale nie szerz herezji, że jest w jakiś sposób "lepiej opisujący" dane, bo to kłamstwo.

Chyba nigdzie nie napisałem lepiej opisujący pisałem ze preferuje go jeśli można wybrać, i że to zależy od zastosowania.
Na poczatku pisałem że xml like, wymaga wiedzy co autor miał na myśli. I dalej myślę ze to prawda, glupie <button></button> nie się okropnie dużo treści. Button ma domyślny kolor, rozmiar, styl, reakcje na myszkę nad, na klikniecie. Json'ie musiałbyś opisać wszytko wprost. Możesz powiedzieć ze to nie kwestia formaty tylko jego wykorzystania, ale xml często się wykorzystuje właśnie dlatego ze format ma taka właściwość.

2

A jak nie jest w tym formacie?

To jest format do opisu formatów. Więc raczej się nie spotkasz za często z tym, że ktoś bezpośrednio będzie pisał XSD.

jak ktoś zagnieździ svg w html (2 dni temu wciągiem dane z czegoś takiego) albo zbuduje mini-framework xml do ustawiania UI(takie coś też widziałem), albo xaml od microsotu, lub zrobi cokolwiek dziwnego

Do tego jest właśnie XMLNS i XSD. W ten sposób możesz opisać i program może rozpoznać "w jakim formacie" obecnie są dane. Większość tego co wymieniłeś używa XMLNS i zapewne XSD również do opisania swojego formatu.

Ale jak z jakichkolwiek przyczyn się to nie uda, to trzeba zgadywać co autor miał na myśli.

Dokładnie tak samo jak w JSONie, gdzie nie ma absolutnie żadnych metadanych, które pozwolą Ci automatycznie rozpoznać kontekst. A HATEOAS w JSONie cały czas kuleje i rzadko kiedy możesz spotkać dokumenty poprawnie opisane. A JSON Schema dalej nie ma finalnego standardu przez co OpenAPI i JSON Schema dalej się rozjeżdżają przy definicji zwracanych danych.

json powinien wygladać tak, by był równoważny

Niestety pudło. By był równoważny powinien wyglądać tak (zakładając JSON-LD):

{
  "@context": [
    "https://schema.org",
    {"time": "https://schema.org/startDate"}
  ],
  "@type": "Event",
  "time": "2020-01-12T18:23:54+01:00"
}

Ale dalej masz tylko informacje o kontekście (co dana wartość znaczy), ale nie masz informacji o strukturze (jak powinien wyglądać dokument). Do tego drugiego, jak wcześniej wspomniałem, nie ma standardu, najbliżej jest JSON-Schema, ale to dalej jest "w produkcji" i potrafi się znacznie zmieniać pomiędzy szkicami. Do XMLa masz od dawna XSD, np. tutaj masz definicję OpenDocument XML czyli formatu używanego przez LibreOffice.

glupie <button></button> nie się okropnie dużo treści. Button ma domyślny kolor, rozmiar, styl, reakcje na myszkę nad, na klikniecie. Json'ie musiałbyś opisać wszytko wprost

Skąd Ci się wzięło, że "musiałbyś wszystko wprost" w JSONie? Przecież to zupełnie z czapy argument, że XML jakoś "magicznie" zdobywa wiedzę na podstawie czegoś. Dorabiasz jakąś teorię bazując na tym jakie użycia XMLa widziałeś a jak sam wspominałeś, dyskusja jest XML vs JSON, a te formaty jako forma zapisu danych nie mają jakichś specjalnych zdolności. XML jest bardziej rozlazły, ale ma zdecydowanie więcje standardów, które są przyjęte i używane, JSON jest prostszy i bardziej zwięzły, ale większość struktur wokół niego jest ad-hoc lub w trakcie prac.

1
Charles_Ray napisał(a):

Muszę przyznać, że czytelność dla człowieka to chyba jeden z tych aspektów, które rozważyłbym w ostatniej kolejności.

Pytanie jeszcze co to znaczy "czytelny dla człowieka". YAML reklamowano jako pierwszy forma przy projektowaniu którego czytelność dla człowieka była najważniejsza, a ostatnio słyszałem od architekta "W projekcie nie będziemy używać YAML, te wcięcia są totalnie nieczytelne".
IHMO HOCON i TOML są o wiele bardziej czytelne do konfiguracji, ale ja zawsze wolałem nawiasy niż wcięcia

1 użytkowników online, w tym zalogowanych: 0, gości: 1