Język XML został wynaleziony w 1996 roku. Ledwie się pojawił, możliwości jego zastosowania już zaczęto źle rozumieć, a do celów, do jakich próbowano je dostosować, nie był to najlepszy wybór.
Nie będzie przesadą stwierdzenie, że zdecydowana większość schematów XML, jakie widziałem, stanowiła niewłaściwe lub niepoprawne użycie XML. Co więcej, takie użycie XML pokazało fundamentalne niezrozumienie tego, o co chodzi w XML.
XML jest językiem znaczników. To nie jest format danych. Większość schematów XML wyraźnie pominęła to rozróżnienie, myląc XML z formatem danych, co ostatecznie skutkuje błędem w wyborze XML, ponieważ jest to format danych, który jest faktycznie potrzebny.
Bez wchodzenia w szczegóły, XML najlepiej nadaje się do opisywania bloków tekstu strukturą i metadanymi. Jeśli Twoim głównym celem nie jest praca z blokiem tekstu, wybór XML raczej nie będzie uzasadniony.
Z tego punktu widzenia istnieje prosty sposób sprawdzenia, jak dobrze jest wykonany schemat XML. Weźmy jako przykład dokument w zamierzonym schemacie i usuń z niego wszystkie tagi i atrybuty. Jeśli to, co pozostało, nie ma sensu (lub jeśli pozostała pusta linia), oznacza to, że albo twój schemat nie jest poprawnie zbudowany, albo po prostu nie powinieneś używać XML.
Poniżej podam kilka najczęstszych przykładów niepoprawnie skonstruowanych obwodów.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Tutaj widzimy przykład bezpodstawnej i dziwnej (choć bardzo częstej) próby wyrażenia prostego słownika klucz-wartość w formacie XML. Jeśli usuniesz wszystkie tagi i atrybuty, pozostanie pusty wiersz. Zasadniczo dokument ten jest, jakkolwiek absurdalnie by to nie zabrzmiało, semantyczną adnotacją pustej linijki.
<root name="John" city="London" />Co gorsza, nie mamy tutaj jedynie semantycznej adnotacji pustego ciągu znaków jako ekstrawaganckiego sposobu wyrażania słownika - tym razem „słownik” jest bezpośrednio zakodowany jako atrybuty elementu głównego. To sprawia, że dany zestaw nazw atrybutów elementu jest niezdefiniowany i dynamiczny. Co więcej, pokazuje, że tak naprawdę wszystko, co autor chciał wyrazić, to prosta składnia klucz-wartość, ale zamiast tego podjął zupełnie dziwną decyzję o zastosowaniu XML, wymuszając użycie pojedynczego pustego elementu po prostu jako przedrostka, aby użyć składni atrybutów. A bardzo często spotykam się z takimi schematami.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>To jest coś lepszego, ale teraz z jakiegoś powodu klucze są metadanymi, a wartościami nie. Bardzo dziwne spojrzenie na słowniki. Jeśli usuniesz wszystkie tagi i atrybuty, połowa informacji zostanie utracona.
Prawidłowe wyrażenie słownikowe w formacie XML wyglądałoby mniej więcej tak:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Jeśli jednak ludzie podjęli dziwną decyzję o użyciu XML jako formatu danych, a następnie wykorzystali go do uporządkowania słownictwa, powinni zrozumieć, że to, co robią, jest niewłaściwe i niewygodne. Projektanci często błędnie wybierają XML do tworzenia swoich aplikacji. Ale jeszcze częściej pogarszają sytuację, bezsensownie używając XML w jednej z opisanych powyżej form, ignorując fakt, że XML po prostu się do tego nie nadaje.
Najgorszy schemat XML? Swoją drogą nagroda za najgorszy schemat XML jaki kiedykolwiek widziałem, Pobiera format pliku konfiguracyjnego automatycznego udostępniania dla telefonów telefonii IP Polycom. Takie pliki wymagają pobrania plików żądań XML za pośrednictwem protokołu TFTP, który... Ogólnie rzecz biorąc, oto fragment jednego z takich plików:
<softkey
softkey.feature.directories="0"
softkey.feature.buddies="0"
softkey.feature.forward="0"
softkey.feature.meetnow="0"
softkey.feature.redial="1"
softkey.feature.search="1"
softkey.1.enable="1"
softkey.1.use.idle="1"
softkey.1.label="Foo"
softkey.1.insert="1"
softkey.1.action="..."
softkey.2.enable="1"
softkey.2.use.idle="1"
softkey.2.label="Bar"
softkey.2.insert="2"
softkey.2.action="..." />To nie jest czyjś kiepski żart. I to nie jest mój wynalazek:
- elementy są po prostu używane jako przedrostek do dołączania atrybutów, które same w sobie mają nazwy hierarchiczne.
- Jeśli chcesz przypisać wartości do wielu instancji określonego typu rekordu, musisz w tym celu użyć nazw atrybutów. które mają indeksy.
- Ponadto atrybuty zaczynające się od
softkey., należy umieścić na elementach<softkey/>, atrybuty zaczynające się odfeature., należy umieścić na elementach<feature/>itp., mimo że wygląda to zupełnie niepotrzebnie i na pierwszy rzut oka bez znaczenia. - I na koniec, jeśli miałeś nadzieję, że pierwszy składnik nazwy atrybutu będzie zawsze taki sam jak nazwa elementu – nic takiego! Na przykład atrybuty
up.należy dołączyć<userpreferences/>. Kolejność dołączania nazw atrybutów do elementów jest dowolna, niemal całkowicie.
Dokumenty lub dane. Co jakiś czas ktoś robi coś zupełnie dziwnego, próbując porównać XML i JSON, pokazując w ten sposób, że też nie rozumie. XML to język znaczników dokumentów. JSON to ustrukturyzowany format danych, więc porównywanie ich ze sobą przypomina porównywanie ciepłych i miękkich.
Pojęcie różnicy między dokumenty i dane. Jako analog XML możemy warunkowo przyjąć dokument nadający się do odczytu maszynowego. Choć w założeniu ma być czytelny maszynowo, metaforycznie odnosi się do dokumentów i pod tym względem jest porównywalny z dokumentami PDF, których najczęściej nie da się odczytać maszynowo.
Na przykład w XML-u kolejność elementów ma znaczenie. Ale w JSON kolejność par klucz-wartość w obiektach jest bez znaczenia i niezdefiniowana. Jeśli chcesz uzyskać nieuporządkowany słownik par klucz-wartość, rzeczywista kolejność elementów w tym pliku nie ma znaczenia. Na podstawie tych danych można jednak utworzyć wiele różnych typów danych. dokumentów, ponieważ w dokumencie panuje określona kolejność. Metaforycznie jest to analogiczne do dokumentu na papierze, chociaż nie ma fizycznych wymiarów, w przeciwieństwie do wydruku czy pliku PDF.
Mój przykład prawidłowej reprezentacji słownika XML pokazuje kolejność elementów w słowniku, w przeciwieństwie do reprezentacji JSON. Nie mogę zignorować tej kolejności: ta liniowość jest nieodłączną częścią modelu dokumentu i formatu XML. Niektórzy mogą zignorować kolejność podczas interpretacji tego dokumentu XML, ale nie ma sensu się na ten temat spierać, ponieważ kwestia ta wykracza poza zakres dyskusji na temat samego formatu. Co więcej, jeśli umożliwisz przeglądanie dokumentu w przeglądarce poprzez dołączenie do niego kaskadowego arkusza stylów, zobaczysz, że elementy słownika pojawiają się w określonej kolejności, a nie w innej.
Innymi słowy, można przekształcić słownik (fragment danych strukturalnych). n różne możliwe dokumenty (w formacie XML, PDF, papierze itp.), gdzie n - liczba możliwych kombinacji elementów w słowniku, a innych możliwych zmiennych nie uwzględniliśmy jeszcze.
Wynika jednak również z tego, że jeśli chcesz przenieść tylko dane, to użycie w tym celu dokumentu nadającego się do odczytu maszynowego nie będzie skuteczne. Posługuje się modelem, który w tym przypadku jest zbędny, tylko będzie przeszkadzał. Ponadto, aby wyodrębnić dane źródłowe, konieczne będzie napisanie programu. Nie ma prawie sensu używać XML w przypadku czegoś, co w pewnym momencie nie zostanie sformatowane jako dokument (powiedzmy przy użyciu CSS, XSLT lub obu), ponieważ jest to główny (jeśli nie jedyny) powód, aby to zrobić. do wzoru dokumentu.
Co więcej, ponieważ w języku XML nie ma pojęcia liczb (ani wyrażeń boolowskich, ani innych typów danych), wszystkie liczby reprezentowane w tym formacie są traktowane jako dodatkowy tekst. Aby wyodrębnić dane, należy znać schemat i jego związek z odpowiednimi wyrażanymi danymi. Trzeba także wiedzieć, kiedy, biorąc pod uwagę kontekst, dany element tekstowy reprezentuje liczbę i należy go przekonwertować na liczbę itp.
Tym samym proces wydobywania danych z dokumentów XML nie różni się tak bardzo od procesu rozpoznawania zeskanowanych dokumentów zawierających np. tabele tworzące wielostronicowe dane liczbowe. Tak, w zasadzie można to zrobić, ale nie jest to najbardziej optymalny sposób, chyba że w ostateczności, gdy nie ma absolutnie żadnych innych opcji. Rozsądnym rozwiązaniem jest po prostu znalezienie cyfrowej kopii oryginalnych danych, która nie jest osadzona w modelu dokumentu łączącym dane z ich specyficzną reprezentacją tekstową.
To powiedziawszy, wcale mnie nie dziwi, że XML jest popularny w biznesie. Powodem tego jest właśnie to, że format dokumentu (na papierze) jest zrozumiały i znany biznesowi, a oni chcą nadal korzystać ze znanego i zrozumiałego modelu. Z tego samego powodu firmy zbyt często korzystają z dokumentów PDF zamiast formatów bardziej nadających się do odczytu maszynowego – ponieważ nadal są one przywiązane do koncepcji drukowanej strony o określonym rozmiarze fizycznym. Dotyczy to nawet dokumentów, które prawdopodobnie nigdy nie zostaną wydrukowane (na przykład 8000-stronicowy plik PDF z dokumentacją rejestrową). Z tego punktu widzenia wykorzystanie XML w biznesie jest w istocie przejawem skeuomorfizmu. Ludzie rozumieją metaforyczną ideę drukowanej strony o ograniczonym rozmiarze i rozumieją, jak tworzyć procesy biznesowe w oparciu o drukowane dokumenty. Jeśli to Twój przewodnik, dokumenty bez ograniczeń rozmiaru fizycznego, które można odczytać maszynowo – dokumenty XML – stanowią innowację, a jednocześnie są znajomym i wygodnym odpowiednikiem dokumentu. Nie przeszkadza to jednak w pozostawaniu błędnego i nadmiernie skeuomorficznego sposobu prezentacji danych.
Jak dotąd jedyne znane mi schematy XML, które mogę naprawdę nazwać prawidłowym użyciem formatu, to XHTML i DocBook.
Źródło: www.habr.com