Jeśli XML jest taki zły… dlaczego tak wielu ludzi go używa? [Zamknięte]

37

Rozumiem cel XML, ale zawsze słyszę, jak ludzie narzekają na to, JAK ZŁEGO? Naprawdę nie rozumiem, co w tym złego? Zazwyczaj słyszę słowa „wzdęty” i „wolny”.

Ale myślę, że jako programiści, do czego go głównie używasz? I czy naprawdę uważasz to za „złe”… ponieważ tak jest, okropnie wiele osób używa go do przesyłania danych ...


źródło
1
Twoja odpowiedź jest w pytaniu. Ludzie nadal go używają, ponieważ ludzie go używali, a opcjami są (1) przepisanie całego kodu, który używał go przed JSON i YAML, lub (2) zassanie go i zrobienie głupoty. Wiele osób wciąż także podtrzymuje cykle przemocy. Nie świadczy to o wartości tej praktyki.
Parthian Shot
5
Wypróbuj JSON, aby uzyskać rzeczywisty dokument (strona podręcznika, Knuth, Hamlet itp.). Zrozumiesz, dlaczego XML jest niezbędny. Jest to przestrzeń, w której JSON jest do bani (śmiało, spróbuj). Korzystanie z jednego z nich w przestrzeni projektowej drugiego jest wątpliwe. Problemy z używaniem XML w przestrzeni JSON to głównie gadatliwość i szybkość, podczas gdy problemy z używaniem JSON w przestrzeni XML zwykle wiążą się z przenośnością (spróbuj współpracować z przyjacielem, który napisał książkę w JSON, ale na swój własny sposób), integralnością i problemy interpretacyjne, które wymagają dużego wysiłku ludzkiego do rozwiązania. Użyj odpowiedniego narzędzia do swojej pracy.
TextGeek,
XML jest zły tylko dlatego, że wiele osób go nadużywa, ponieważ rzeczy, do których nie został zaprojektowany. Jeśli nie potrzebujesz, aby twoje dane były łatwo rozszerzalne (tj. Schemat jest używany przez wiele stron, które muszą współpracować, a nie centralnie podyktowane przez jedną autorytatywną stronę), i jeśli twoje dane nie są dokumentem (tj. Jeśli DOM była słaba abstrakcja danych), więc XML nie jest odpowiedni dla tych aplikacji. Gdy domena problemowa mieści się w zakresie, dla którego przeznaczony jest XML, nic innego nie pasuje do XML. JSON, YAML itp. Są słabo dostosowane do przestrzeni, dla której XML jest naprawdę zaprojektowany.
Lie Ryan

Odpowiedzi:

90

Xml doskonale nadaje się do tego, czym został zaprojektowany - neutralny dla platformy, czytelny dla człowieka protokół przesyłania danych z pewnymi możliwościami wymuszania sprawdzania poprawności danych na niskich poziomach. Wątpię, czy ktoś, kto używa Xml w ten sposób, ma prawdziwą skargę. Czy jest to najbardziej drutowy format drutu? Nie. Ale są gorsze opcje. Czy to tak szybkie, jak czytanie niestandardowego formatu binarnego? Nie. Ale twoi partnerzy biznesowi mogą to odczytać na dowolnym stosie, którego używają.

Problem polega jednak na tym, że ludzie - szczególnie rasa znana jako architekci przedsiębiorczości - są źli i biorą dobre rzeczy i czynią je złymi. W przypadku Xml na początku tego wieku Xml był uniwersalnym młotem do każdego problemu informatycznego. Posyp trochę projektem komitetu, a skończysz z okropnymi potworami, takimi jak SOAP i oXML . Żaden z nich nie należy życzyć wrogom, nieistotnym przyjaciołom lub kolegom.

Wyatt Barnett
źródło
15
+1 - każdy, kto kiedykolwiek miał do czynienia z EDI, chciałby, aby XML został wynaleziony przed tym bałaganem.
Scott Whitlock,
12
+1 Prawie dokładnie pasuje do moich myśli. Dodałbym tylko, że do przechowywania prostych i prostych danych, nawet jeśli są to dane hierarchiczne (ale niezbyt głęboko, które nie pasują do niczego ), istnieją pewne formaty, które działają równie dobrze - zwłaszcza JSON i YAML. Ta ostatnia jest niesamowita pod względem czytelności dla ludzi.
11
Parafrazując jwz: „Jest pewien programista, który spojrzy na każdy problem i powie:„ Wiem, użyję XML ”. Teraz ma dwa problemy ”.
Adam Crossland
13
Powiedz mi, że oXML miał być żartem, na przykład Brainfuck, Whitespace lub LOLCODE.
dsimcha
9
@Shamim Hafiz, SOAP jest zdecydowanie jedną z najgorszych potworności, jakie kiedykolwiek wyhodowała ludzkość.
SK-logic
24

XML to tylko narzędzie, które występuje w wielu odmianach i zastosowaniach. XML wyróżnia się na niektórych rzeczach, a na innych jest do bani. Myślę, że jednym z problemów jest to, że ludzie widzieli „korporacyjny” XML, który jest niepotrzebnie złożony z przestrzeniami nazw i rozrzuconymi bzdurami (SOAP, ktoś?). Sztuką projektowania formatów XML dla ludzi jest nadawanie prawdziwego znaczenia danym, a nie przytłaczanie ich do czytania.

Jedną z rzeczy, z którymi ludzie mają problem, jest to, że XML czasami dusi jakiś znak lub brakujący nawias. Istnieje jednak zarówno wada, jak i wada. Zaletą jest to, że nie masz dwuznaczności, tak jak w przypadku HTML, gdzie różne przypadki półpoprawnej składni mogą być interpretowane inaczej.

Minusem jest to, że trudniej jest napisać i trudniej się nauczyć. Zgadzam się, że można wysunąć argument, że sieć nie byłaby tak duża, gdyby HTML był tak rygorystyczny jak XML, ale argumentowałbym również, że bylibyśmy zadowoleni, gdyby tak było dzisiaj. :)

Nie używaj go również do wszystkiego, ponieważ możesz, mieć rozsądek i rozsądek, aby odpowiednio go zastosować. Jeśli wszystko, co masz, to XML, zawsze jesteś transformacją XSLT od tego, co chcesz. :)

Twierdzę, że format ma znaczenie tylko wtedy, gdy ludzie muszą z nim współdziałać. Jeśli piszesz jakiś program, który serializuje coś i wysyła go gdzieś, gdzie ma być wykorzystany przez inny z twoich programów, kogo to obchodzi, jak to wygląda, o ile jest to tak wydajne, jak to możliwe? Używaj formatu binarnego lub królików i jednorożców.

Plusy XML

  • Obejmuje wiele przypadków krawędzi, których nie mają YAML i JSON
  • Istnieją doskonałe narzędzia do analizowania i sprawdzania poprawności XML w szeregu różnych platform i języków
  • XML można łatwo i skutecznie przekształcić w inny format (poprzez rzeczy takie jak XSLT)
  • Rozsądne dokumenty XML są łatwe do odczytania i edycji przez ludzi; nie mów mi, że JSON jest łatwiejszy, nie jest :)
  • XML w pewnym stopniu samoopisuje się, tzn. Zawiera bezpośrednio informacje o jego strukturze i znaczeniu (w przeciwieństwie do większości formatów binarnych)
  • Obsługuje kodowanie
  • Agnostyczny dla białych znaków, co ułatwia korzystanie z różnych platform
  • Łamie się, jeśli nie jest dobrze sformułowany (zapewnia, że ​​dane są strukturalnie poprawne)
  • To nie jest SGML

Cons

  • Gadatliwy
  • Parsowanie nie jest tak szybkie jak binarne
  • Zrywa się, jeśli nie jest dobrze uformowany (powoduje awarię aplikacji)

Dobre zastosowania

  • Pliki konfiguracyjne
  • Formaty wymiany danych
  • Formaty plików odporne na wersje
  • Przechowywanie dokumentów w bazach danych

Nie tak dobre zastosowania

  • Formaty przesyłania danych
  • Serializacja obiektów
  • Przechowywanie danych relacyjnych w bazach danych
  • Format pliku dla wysokowydajnych scenariuszy we / wy
Homde
źródło
13
Wątpię, aby „pliki konfiguracyjne” były w „dobrych zastosowaniach”. To nie są dane, a instrukcje.
daknøk
3
Jestem tutaj z @ daknøk - nie mogę policzyć, ile razy spędziłem mnóstwo czasu, zastanawiając się nad błędem konfiguracyjnym w pliku XML o długości wiersza, który określa wstrzyknięcie zależności, które było oparte na jednej małej literówce w atrybut XML.
Gjallar,
3
Jeśli złe dane powodują awarię aplikacji, to czy dane mają problem?
James Snell
4
Każdy źle sformatowany / uszkodzony format pliku może spowodować awarię uszkodzonego oprogramowania. Więc XML nie jest tutaj winowajcą ... tylko twoją aplikacją. W przeciwnym razie dobry post.
Thomas Eding,
3
Czy możesz rozwinąć temat „Obejmuje wiele przypadków krawędzi, których YAML i JSON nie mają”.
Trevor Hickey
14

Jeff Atwood ma całkiem niezły wpis na blogu w XML: The Angle Bracket Tax na ten temat, jeśli chcesz, aby źródło o tym mówiło.

Najczęstsze zastosowania, które mam do tego, to:

  • Usługi rozmawiają ze sobą. Na przykład strona internetowa korzystająca z systemu zarządzania treścią musi wysyłać niektóre dane do systemu zarządzania relacjami z klientem i odbywa się to za pomocą XML.

  • Pamięć konfiguracji. Web.config i app.config są typowymi przykładami, ale skrypty nAnt również mogą do nich używać XML.

Nie wydaje mi się, żeby było optymalne, ale samo to nie szkodzi mi.

JB King
źródło
11

Dwa powody:

  1. Istnieje okropnie dużo złych programistów. XML może być zły, ale jest również prosty (przynajmniej na powierzchni) i bardzo ułatwia pisanie złego oprogramowania. Trochę jak VB.
  2. Wiele osób podejmujących takie decyzje nie jest programistami, ale typami firm, które słyszały tylko, że „wszyscy używają XML”, dlatego zdecydowali, że chcą, aby ich produkt również używał XML.
Mason Wheeler
źródło
Co za absurdalne i całkowicie bezużyteczne punkty. 1) XML jest daleki od złego i nie ma absolutnie nic wspólnego z jakością oprogramowania, które ludzie piszą, czy go wybierają, czy nie. Widziałem całkiem dobrych programistów VB, co sugeruje, że jeśli używasz VB, naprawdę piszesz złe oprogramowanie. po prostu głupie, ponieważ istnieje całkowite rozróżnienie między tym, jak piszesz oprogramowanie, a tym, czego używasz do pisania. 2) Kolejne fałszywe założenie, wybór XML jest świetny i większość ludzi, którzy wybierają go na lepsze lub gorsze, to z pewnością programiści. XML nie jest srebrną kulą, ale nadaje się do pewnych rzeczy.
Eyal Solnik
2
@EyalSolnik: Niektórzy ludzie, gdy pojawia się problem, myślą „Wiem, użyję XML”.<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
Tylko dlatego, że ludzie nadużywają czegoś, nie oznacza, że ​​sama technologia jest zła, możesz zobaczyć ten sam syndrom w wielu miejscach.
Eyal Solnik
8

Zazwyczaj słyszę słowa „wzdęty” i „wolny”.

To nie jest najbardziej zwarta składnia, ale jest to najwyraźniej najbardziej ekspresyjna. Czytelny dla człowieka? zależy od tego, jak zaprojektujesz swój język. Większość ludzi nie projektuje języka dla XML, po prostu serializuje obiekty jako XML.

… Dlaczego tak wielu ludzi z niego korzysta?

Jest wszechobecny. Możesz przeszukiwać bazę danych XML za pomocą XQuery, przekształcać wyniki za pomocą XSLT jako XHTML lub Atom, uzyskiwać Atom lub inny format XML z innych usług internetowych, uzyskiwać XML od użytkowników korzystających z XForms, sprawdzać poprawność za pomocą XMLSchema, Relax NG lub Schematron, przetwarzać za pomocą XProc, zapisz go z powrotem w bazie danych za pomocą XQuery Update. Wszystkie te narzędzia rozumieją XML, więc nie ma potrzeby mapowania między różnymi reprezentacjami.

XML nie jest technologią serializacji, to zestaw informacji ogólnego przeznaczenia.

Max Toro
źródło
... i od lat zadajemy sobie pytanie, dlaczego dla chrissakes SOAP został zbudowany na bazie XML.
JensG
6

Tutaj używamy go do wymiany danych między różnymi systemami wykonanymi przez różnych dostawców o różnych wewnętrznych reprezentacjach. Budujemy system transformacji / wymiany XML, aby przesyłać dane tam iz powrotem. Działa to dobrze.

XML nie jest z natury zły, ale potwierdzam, że zaprojektowanie „dobrego” rozwiązania przy użyciu XML nie jest trywialne.

FrustratedWithFormsDesigner
źródło
5

„Istota XML jest taka: problem, który rozwiązuje, nie jest trudny i nie rozwiązuje dobrze problemu”. - Phil Wadler, POPL 2003

Moim osobistym zdaniem jest to, że dopóki nie przejmujesz się sprawdzaniem poprawności, schematami, XSLT i innymi brzydkimi rzeczami, a rozmiar plików jest mały (inaczej parsowanie staje się wolne), możesz znaleźć dobre zastosowania XML (przykład służy do konfigurowania aplikacji zamiast używania plików INI).

sakisk
źródło
4

Z mojego doświadczenia wynika, że ​​ludzie w większości narzekają na sposób, w jaki się go wykorzystuje, a nie na samą technologię.

Nadęty i powolny fragment, na który narzekają ludzie, to zwykle biblioteki / metody służące do pobierania z niego informacji.

Używam go do przechowywania niewielkich ilości ustrukturyzowanych informacji, które chcę zapisać na dysku (bez bazy danych lub serializacji binarnej), lub przekazać do innej aplikacji (która zasadniczo opisuje również SOAP).

Steven Evers
źródło
2

Jest dobry, ponieważ:

Jest to standardowy „interfejs”, z którym wiele heterogenicznych systemów może się komunikować. I jest „czytelny” dla człowieka (niejako spróbuj spojrzeć na 5 MB XML)

Jest źle, ponieważ:

Jego wzdęty, większy rozmiar = większa przepustowość = więcej $$

Są inne powody, każdy ma inny problem ...

Ciemna noc
źródło
4
@Darknight: Rzucam wyzwanie czytelnemu człowiekowi , rzucając w ciebie Xml Entities ... (wkurza)
Matthieu M.
1
Nie sądzę, że XML jest z natury nadęty - ale jego implementacje są. Uważam, że XML-RPC jest szczególnie skandaliczny w przypadku niepotrzebnego wzdęcia.
HorusKol,
3
@HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator>Stosunek danych / znaczników jest tak niski ... Nazywam to „rozdętym”. JSON, na przykład, byłoby tylko pół nadęty: advanceAcceptanceIndicator: "Y". Istnieje również fakt, że tekst między znacznikami jest prawidłowy, więc podczas czytania Xml musisz zdecydować, co zrobić z tym cruftem \n\t\t\t, a rozwiązaniem jest na ogół po prostu zignorowanie go, ponieważ tak naprawdę nigdy nie byłeś tym zainteresowany.
Matthieu M.
1
@HorusKol: Byłoby, ale nigdy nie powiedziałem, że jest to wartość boolowska, po prostu zdarza się, że jest to pojedynczy znak :) Zastosowanie atrybutu tutaj ( value?) Prawdopodobnie również byłoby lepsze, ponieważ ludzie mogliby ulec pokusie, aby wstawić spacje między dwoma tagi.
Matthieu M.,
1
„Jego wzdęty, większy rozmiar = większa przepustowość = więcej $$” Myślę, że kompresja nie została wymyślona tam, gdzie jesteś.
Andy,
2

Jak w przypadku każdej innej technologii: istnieje wiele dostępnych narzędzi i bibliotek.

Nie podoba mi się XML, szczególnie dlatego, że jest funky, kiedy ludzie mówią, że jest czytelny dla ludzi, żartują, tak myślę, lub nigdy tak naprawdę nie czytali xml, gdy ktoś próbował osadzić xml w atrybucie ... encje xml to naprawdę nieczytelne. Co więcej, niesamowite jest to, ile miejsca marnuje się z powodu zbędnego tagu końcowego oraz możliwości mieszania dowolnego tekstu i danych ...

Ale:

  • Xml można określić (xsd) i dostępne są narzędzia, które sprawdzają zgodność danych Xml
  • wiele narzędzi (edytory tekstu i tym podobne) obsługuje Xml
  • wiele bibliotek (w prawie każdym języku programowania) obsługuje Xml

Ma także tę przewagę, że w większości przypadków ma pierwszeństwo. Kiedy już udostępniasz usługi sieciowe w Xml, a ktoś prosi o nową usługę ... prawdopodobnie będzie to zrobione w Xml, ponieważ o tym wiesz.

Matthieu M.
źródło
5
XML jest bardziej czytelny niż dane binarne lub dane rozdzielane pozycjami lub przecinkami.
FrustratedWithFormsDesigner
Tylko dla naiwnego użytkownika. Gdybym musiał zeskanować wizualnie kilkaset rekordów w poszukiwaniu jednego, w którym brakuje niektórych danych, wolałbym raczej szukać pustych kolumn w bloku rekordów o stałej długości, niż przedzierać się przez szereg elementów i atrybutów w poszukiwaniu pustego znacznika.
TMN
1
@FrustratedWithFormsDesigner: to naprawdę zależy od dostępnych danych. Xml osadza charakter informacji w pobliżu odpowiednich informacji. Jeśli spojrzysz na funkcjonalne języki programowania, zobaczysz takie rzeczy jak (Haskell): data Person = Person { surname :: String, firstName :: String, age :: Int }jeśli zobaczę, Person "Doe" "John" 42że jest to również czytelne i unikniesz wielu cruft, ale jest bliżej rozdzielania przecinkami.
Matthieu M.
1
Ok, twój przykład był łatwiejszy do odczytania bez znaczników, ale trywialne (powiedziałbym, że mniej niż 8 lub 9 elementów danych) można zrobić przykłady do obsługi wszystkich formularzy (z wyjątkiem może binarnych). Źródła danych z komputera mainframe powstają jako ciągi rozdzielane pozycjami (a większość z nich to tylko kody numeryczne), a po przekształceniu do formatu XML są znacznie łatwiejsze do odczytania, debugowania i zarządzania. Jak powiedziałeś, może to zależeć ...
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner: Tak, właśnie o to mi chodzi :) To zależy, ale ponieważ istnieje tak bogaty ekosystem dla XML i ponieważ łatwiej jest utrzymać tylko jeden zestaw narzędzi / bibliotek, ludzie zwykle używają XML do wszystkiego. Osobiście wolę JSon niż XML, ale jeszcze raz bez wcięcia, jest bałagan: p
Matthieu M.
-1

XML jest złym wyborem dla plików, które muszą być utrzymywane przez ludzi. Nie ma wizualnej separacji między znacznikiem a treścią, co utrudnia czytanie. Pisanie poprawnie bez specjalnego edytora jest żmudne. Każdy błąd w dokumencie XML jest krytyczny; dokumentu XML nie można częściowo przetworzyć. Gdy plik XML jest nieprawidłowy, wynikowy komunikat o błędzie jest często nieprzydatny.

W przypadku każdego pliku, który musi obsługiwać człowiek, wolałbym używać dowolnego JSON, YAML lub kodu źródłowego w jakimś interpretowanym języku (Python, Ruby, Groovy itp.). Odkryliśmy, że doskonałym sposobem na utworzenie konfiguracji XML dla starszego kodu jest użycie Groovy MarkupBuilder. Innym dobrym wyborem jest stworzenie języka specyficznego dla domeny; jest to dość łatwe w przypadku Ruby, Groovy i wielu innych języków.

Kevin Cline
źródło
8
Myślę, że nie rozumiesz sedna XML, znacznikiem jest treść. Celem XML jest opisanie znaczenia twoich danych. Na przykład, jeśli masz numer telefonu, oznaczenie go jako numer telefonu stacjonarnego lub numeru telefonu komórkowego dodaje kontekst, którego mogą używać inni. Lub dodanie tagu telefonu dookoła tekstu w tym celu (może sprawić, że ten numer będzie możliwy do wywołania na telefonie komórkowym). Co do twoich innych punktów również się nie zgadzam. Tworzenie dokumentów XML jest zazwyczaj bardzo proste. Komunikaty o błędach są zawsze związane z poprawnością, a edytowanie XML-a zajmie się JSON
em
@konrad Twój przykład telefonu będzie ważny dla HTML.
Florian F
„Każdy błąd w dokumencie XML jest śmiertelny; dokumentu XML nie można częściowo przetworzyć”. Tak, to duża różnica w stosunku do XML.
Andy,
@Andy To całkiem bezużyteczne, jeśli XML został napisany przez człowieka, a aplikacja po prostu mówi „źle!”. Ludzki redaktor musi znać linię, w której wykryto błąd.
kevin cline
Dowolna liczba narzędzi mówi dokładnie, w której linii i często w jakim znaku wykryto błąd. Na przykład narzędzia XML w NotePad ++. .Net powie ci dokładnie, gdzie twój plik .config jest nieprawidłowy. Jeśli mówisz o interfejsie API, jedną z zalet XML jest to, że deweloper API może również dostarczyć XSD, który oprócz zapewnienia prawidłowej składni XML może również powiedzieć, czy masz jakieś elementy, które nie należą, jeśli powinny być tylko jednym z tych elementów itp. Odręcznie napisany Json jest znacznie łatwiejszy do zepsucia.
Andy
-2

Analiza jest stosunkowo łatwa, a jednocześnie czytelna dla człowieka.

A niektóre ładne parsery (np. Xerces {c ++}) są łatwo dostępne.

Szymon, Szymek
źródło
2
Cóż, to proste, o ile dokumenty są małe. Jeśli musisz przeanalizować dokumenty zbyt duże, aby w rozsądny sposób zmieściły się w pamięci, sytuacja staje się ponura.
TMN
Kwestionowałbym część dotyczącą czytelności dla ludzi. Po prostu wymaga o wiele za dużo wysiłku, aby odczytać XML niż odczytanie odpowiedniego JSON.
cmaster