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

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

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.

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

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.

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.

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.

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.

„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).

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

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

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.

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.

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

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