Język XML został wynaleziony w 1996 roku. Ledwo się pojawił, a już zaczęto go niewłaściwie wykorzystywać, a dla celów, do których go próbowano dostosować, nie był najlepszym wyborem.
Nie będzie przesadą powiedzieć, że przeważająca większość schematów XML, które miałem okazję zobaczyć, była niecelowym lub błędnym wykorzystaniem XML. Co więcej, takie zastosowanie XML świadczyło o fundamentalnym braku zrozumienia, czym przede wszystkim jest XML.
XML to język znaczników. To nie jest format danych.. W większości schematów XML to rozgraniczenie nie było wyraźnie uwzględniane, myląc XML z formatem danych, co w efekcie oznaczało błąd w wyborze XML, ponieważ w rzeczywistości potrzebny był format danych.
Nie zagłębiając się w szczegóły, XML najlepiej nadaje się do annotowania bloków tekstu ze strukturą i metadanymi. Jeśli twoim głównym celem nie jest praca z blokiem tekstu, wybór XML raczej nie będzie uzasadniony.
Z tej perspektywy istnieje prosty sposób, aby sprawdzić, jak dobrze zbudowany jest schemat XML. Weźmy na przykład dokument w założonym schemacie i usuńmy z niego wszystkie znaczniki i atrybuty. Jeśli w tym, co pozostało, nie ma sensu (lub jeśli pozostała pusta linia), to albo twój schemat jest źle skonstruowany, albo po prostu nie powinieneś był używać XML.
Następnie przedstawię kilka najczęściej spotykanych przykładów błędnie skonstruowanych schematów.
Tutaj widzimy przykład niewłaściwej i dziwnej (choć bardzo powszechnej) próby wyrażenia językiem XML prostego słownika „klucz-wartość”. Jeśli usuniemy wszystkie znaczniki i atrybuty, pozostanie pusta linia. W zasadzie ten dokument przedstawia, jak absurdalnie by to nie brzmiało, semantyczną adnotację pustej linii.
<root name="John" city="London" />Co gorsza, nie mamy tutaj po prostu semantycznej adnotacji pustego wiersza jako ekstrawaganckiego sposobu wyrażania słownika – tym razem „słownik” jest bezpośrednio zakodowany w postaci atrybutów elementu głównego. W związku z tym ustalony zestaw nazw atrybutów na elemencie staje się nieokreślony i dynamiczny. Co więcej, stąd widać, że wszystko, co tak naprawdę chciał wyrazić autor, to prosty składnik „klucz-wartość”, ale zamiast tego podjął całkowicie dziwną decyzję, by zastosować XML, wymuszając wykorzystanie pojedynczego pustego elementu tylko jako prefiksu do użycia składni atrybutów. I takie schematy zdarzają mi się bardzo często.
John
LondonTo już trochę lepiej, ale teraz klucze są z jakiegoś powodu metadanymi, a wartości nie. Dość dziwny sposób patrzenia na słowniki. Jeśli usuniemy wszystkie tagi i atrybuty, połowa informacji zostanie utracona.
Poprawne wyrażenie słownika w XML powinno wyglądać mniej więcej tak:
Nazwa
John
Miasto
LondonAle jeśli ludzie podjęli dziwną decyzję, by stosować XML jako format danych, a następnie za jego pomocą porządkować słownik, to muszą rozumieć, że to, co robią, jest niewłaściwe i niewygodne. Jeszcze częściej projektanci błędnie wybierają XML do budowy swoich aplikacji. Ale jeszcze częściej pogarszają sytuację bezsensownym stosowaniem XML w jednym z opisanych powyżej form, ignorując fakt, że XML do tego po prostu się nie nadaje.
Najgorszy schemat XML? Przy okazji, nagroda za najgorszy schemat XML, jaki kiedykolwiek widziałem, przypadł formatowi pliku konfiguracyjnego automatycznego przydzielania zasobów dla telefonów VoIP Polycom. Takie pliki wymagają pobierania plików XML żądania przez TFTP, które… 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ś nieudany żart. I to nie jest moja wymyślona historia:
- Elementy są po prostu używane jako prefiksy do dołączania atrybutów, które same w sobie mają hierarchiczne nazwy.
- Jeśli trzeba przypisać wartości kilku instancjom rekordu określonego typu, należy użyć nazw atrybutów, które mają indeksy..
- Ponadto atrybuty, które zaczynają się od
softkey., należy umieszczać na elementach<softkey/>, atrybuty, które zaczynają się odfeature., należy umieszczać na elementach<feature/>itd., mimo że wygląda to zupełnie na zbyteczne i na pierwszy rzut oka absurdalne. - Wreszcie, jeśli mieliście nadzieję, że pierwszy komponent nazwy atrybutu zawsze będzie odpowiadał nazwie elementu — nic z tego! Na przykład atrybuty
up.powinny być dołączane do<userpreferences/>. Kolejność dołączania nazw atrybutów do elementów jest dowolna i praktycznie całkowicie chaotyczna.
Dokumenty lub dane. Co jakiś czas ktoś robi całkowicie dziwne rzeczy, próbując porównywać XML i JSON, — i tym samym pokazując, że nie rozumie ani jednego, ani drugiego. XML to język znaczników dokumentów. JSON to z kolei format danych strukturalnych, więc porównywanie ich ze sobą jest jak próba porównania ciepłego z miękkim.
Zrozumienie tego pomoże pojęcie różnicy między dokumentami a danymi.Jako analogię XML można umownie wziąć maszynowo czytelny dokument. Chociaż jest on przeznaczony do odczytu przez maszynę, metaforycznie odnosi się do dokumentów i z tej perspektywy jest właściwie porównywalny z dokumentami formatu PDF, które najczęściej nie są maszynowo czytelne.
Na przykład w XML kolejność elementów ma znaczenie. A w JSON kolejność par 'klucz-wartość' wewnątrz obiektów nie ma sensu i nie jest określona. Jeśli chcesz uzyskać nieuporządkowany słownik par 'klucz-wartość', faktyczna kolejność, w której elementy występują w tym pliku, nie ma znaczenia. Możesz jednak stworzyć z tych danych wiele różnych dokumentów,ponieważ w dokumencie istnieje określona kolejność. Metaforycznie jest to analogia dokumentu na papierze, chociaż nie ma on fizycznych rozmiarów w przeciwieństwie do druku lub pliku PDF.
W moim przykładzie właściwego przedstawienia słownika w języku XML pokazano kolejność elementów w słowniku, w przeciwieństwie do przedstawienia w języku JSON. Nie mogę zignorować tej kolejności: taka linearność jest pierwotnie charakterystyczna dla modelu dokumentów i formatu XML. Ktoś przy interpretacji tego dokumentu XML może postanowić zignorować tę kolejność, ale dyskusja na ten temat jest bezcelowa, ponieważ ten temat wychodzi poza ramy dyskusji o samym formacie. Co więcej, jeśli przekształcimy dokument w formie przeglądarki, dołączając do niego kaskadową tabelę stylów, można zobaczyć, że elementy słownika układają się w określonej kolejności, a nie w żadnej innej.
Innymi słowy, słownik (fragment ustrukturyzowanych danych) może być przekształcony w n różne możliwe dokumenty (w formacie XML, PDF, na papierze itp.), gdzie n — liczba możliwych kombinacji elementów w słowniku, nie uwzględniamy jeszcze innych możliwych zmiennych.
Jednocześnie wynika z tego, że jeśli chcesz przekazać jedynie dane, używanie dokumentu do odczytu maszynowego będzie nieskuteczne. Wykorzystuje model, który w tym przypadku jest zbędny, jedynie przeszkadza. Co więcej, aby wydobyć dane źródłowe, trzeba będzie napisać program. Raczej nie ma sensu używać XML do czegoś, co na pewnym etapie nie będzie formatowane jako dokument (powiedzmy, za pomocą CSS lub XSLT, lub obu), ponieważ to jest główny (jeśli nie jedyny) powód, aby pozostać przy modelu dokumentu.
Co więcej, ponieważ w XML nie ma pojęcia liczb (ani wyrażeń logicznych, ani innych typów danych), wszystkie liczby przedstawione w tym formacie są traktowane wyłącznie jako tekst dodatkowy. Aby wydobyć dane, należy znać strukturę oraz jej powiązanie z odpowiednimi danymi. Należy także wiedzieć, kiedy w kontekście dany element tekstu przedstawia liczbę, którą należy przekształcić w liczbę, itd.
Proces wyciągania danych z dokumentów XML nie różni się zbytnio od rozpoznawania zeskanowanych dokumentów, które zawierają na przykład tabelki, składające się z wielu stron danych liczbowych. Tak, technicznie jest to możliwe, ale nie jest to najbardziej optymalna droga – chyba że w skrajnych sytuacjach, gdy nie ma żadnych innych opcji. Rozsądniejszym rozwiązaniem jest po prostu znalezienie cyfrowej kopii oryginalnych danych, które nie są osadzone w modelu dokumentu, w którym dane są połączone z ich konkretnym tekstowym przedstawieniem.
Nie dziwi mnie, że XML jest popularny w biznesie. Powodem tego jest fakt, że format dokumentów (papierowych) jest zrozumiały i znany dla biznesu, który chce dalej korzystać z dobrze znanego i wygodnego modelu. Z tego samego powodu w biznesie zbyt często korzysta się z dokumentów w formacie PDF zamiast z bardziej odpowiednich do przetwarzania maszynowego formatów – ponieważ wciąż są one związane z koncepcją wydrukowanej strony o określonym fizycznym rozmiarze. Dotyczy to nawet tych dokumentów, które z pewnością nigdy nie będą drukowane (na przykład plik PDF dokumentacji rejestru liczący 8000 stron). Z tej perspektywy użycie XML w biznesie jest zasadniczo wyrazem skevomorfizmu. Ludzie rozumieją metaforyczną ideę wydrukowanej strony o ograniczonym rozmiarze i wiedzą, jak tworzyć procesy biznesowe na podstawie papierowych dokumentów. Jeśli to jest twoim punktem odniesienia, dokumenty bez ograniczonego fizycznego rozmiaru, które są maszynowo czytelne – dokumenty XML – stanowią innowację, będąc jednocześnie znajomym i komfortowym odpowiednikiem dokumentu. Co nie zmienia faktu, że pozostają one błędnym i nadmiernie skevomorficznym sposobem przedstawiania danych.
Do tej pory jedynymi schematami XML, które mogę rzeczywiście uznać za poprawne zastosowanie tego formatu, są XHTML oraz DocBook.
Źródło: habr.com
