Interfejsy programowania XML

Wstęp

W tej części zostaną omówione interfejsy programistyczne XML, które umożliwiają spójną komunikację i możliwość pracy z dokumentami XML. Istnieje wiele dostępnych interfejsów opartych o technologię API (Application Programming Interface), ale omówione zostaną cztery najbardziej popularne i potencjalnie przydatne w działalności wydawnictwa: DOM (Document Object Model), prosty interfejs API dla XML (SAX), JDOM oraz Java API dla XML (JAXP).

Interfejsy te to nic innego jak metody oddziaływania na dokument XML bez bezpośredniej ingerencji w kod źródłowy. Problem może wydawać się na pierwszy rzut oka trudny do zrozumienia, ale wystarczy sobie wyobrazić, że interfejsy są językami, w których różne programy porozumiewają się z dokumentem XML.

 

Document Object Model (DOM)

Document Object Model (DOM), jest uniwersalnym interfejsem pozwalającym przerabiać sparsowane dokumenty XML. W pierwszej kolejności parser wczytuje cały dokument XML do pamięci, a następnie można się z nim komunikować za pośrednictwem DOM. Dokument XML zostaje zinterpretowany do postaci drzewa, a za pośrednictwem DOM można to drzewo wyświetlać, badać zarówno pod kątem budowy struktury jak i zawartości poszczególnych elementów oraz je zmieniać. Idealnym przykładem zastosowania tej technologii może być strona internetowa, w której kod HTML tworzy ramy strony (ułożenie okienek, menu itp.), a JavaScript za pośrednictwem DOM odpowiada za wszystkie dynamiczne elementy strony. W ten sposób można uniknąć wielokrotnego wczytywania kodu HTML i wyświetlać różną treść w zależności od tego, w który link kliknie użytkownik, przeładowując tylko zawartość elementów, a nie same elementy. DOM został stworzony przez W3C i był przez nią rozwijany do 2004, kiedy to przeszedł pod nadzór organizacji WHATWG.

 

Wady DOM

DOM udostępnia bogaty zestaw funkcji, które można wykorzystać do interpretowania i przetwarzania dokumentów XML, ale niestety ma swoje wady, niektóre bardzo istotne z punktu widzenia wydawcy, m.in.:

  • DOM tworzy drzewo całego dokumentu w pamięci komputera. Jeśli dokument jest bardzo duży, to takie działanie wymaga dużej ilości pamięci. Niestety publikacje, szczególnie takie, jak słowniki czy encyklopedie, są z reguły bardzo duże. Wczytanie pojedynczego dokumentu XML i praca nad nim za pośrednictwem DOM nie powinno stwarzać problemu dla żadnego nowoczesnego komputera. Natomiast działanie na całej bazie danych publikacji może po prostu przekroczyć możliwości obliczeniowe maszyny, na której działa baza danych.
  • DOM nie daje możliwości selektywnego wczytywania dokumentu – przy tworzeniu drzewa zawsze bierze pod uwagę cały dokument XML: elementy, tekst, atrybuty i treść. Każda najdrobniejsza zmiana pociąga za sobą konieczność ponownego wczytania i analizowania całego dokumentu.
  • Parser DOM musi wczytać do pamięci cały dokument XML, zanim DOM udostępni użytkownikowi kod. W przypadku dużych dokumentów oznacza to znaczne wydłużenie czasu pracy ze względu na konieczność najpierw wczytania całej bazy, a następnie analizowania dużej liczby danych. W dzisiejszych czasach nikt nie może sobie pozwolić na to, żeby kilka minut czekać na wczytanie pojedynczego pliku, a ten problem cechuje pracę z dokumentami XML za pośrednictwem DOM.

 

Proste API dla XML (SAX)

W odpowiedzi na problemy DOM grupa programistów stworzyła Proste API dla XML, czyli SAX (Simple API for XML). W przeciwieństwie do DOM, SAX analizuje dokument fragment po fragmencie, wysyłając informacje po każdym występującym „zdarzeniu”. Zdarzeniem będzie otwarcie dokumentu XML, otwarcie znacznika elementu, wystąpienie tekstu itp. Dokument jest więc przesyłany fragment po fragmencie według zadanych parametrów. Można więc wyszukać wszystkie wystąpienia danego znacznika i zamienić go na inny znacznik i nie trzeba w tym celu wczytywać całego dokumentu składającego się np. z miliona znaczników. Dzięki temu można pracować na dokumencie XML znacznie szybciej.

Analizator składni SAX, w przeciwieństwie do DOM, nie konwertuje dokumentu XML na obiekty, po prostu informuje aplikację, w której pracujesz, że wystąpiło dane zdarzenie – np. otwarcie znacznika czy wystąpienie danego elementu. Jeśli programista chce stworzyć taką funkcjonalność jak drzewo dokumentu, musi ją sam napisać.

 

Wady SAX

Niestety SAX również nie jest wolny od słabych punktów, wśród nich na przykład:

  • Wydarzenia przesyłane przez analizator SAX nie są niczym więcej niż tylko wydarzeniami. Z faktu, że analizator znalazł dany element, nie wynikają żadne wnioski. Program nie dostaje informacji o tym, gdzie dany element się znajduje czy co zawiera. Jeśli oprogramowanie działające z dokumentem XML za pośrednictwem SAX ma takie funkcje posiadać, to trzeba je stworzyć samodzielnie.
  • SAX nie jest kontrolowany przez żadną renomowaną organizację (np. W3C), co nie przymusza twórców oprogramowania do utrzymywania odpowiedniego standardu. Jak dotychczas nie powodowało to problemów, ale opieranie własnego oprogramowania na standardzie, który nie jest oficjalnie wspierany, wiąże się z ryzykiem, że np. zostaną nagle wprowadzone znaczące zmiany w tym standardzie lub zostanie wycofany z dalszych prac.

 

JDOM

Problemy DOM oraz SAX natchnęły Jasona Huntera i Bretta McLaughlina do stworzenia pakietu JDOM (Java DOM). Jest to projekt oparty o technologię JAVA w standardzie OpenSource (kod zródłowy jest powszechnie dostępny). Został napisany według założeń zasady Pareto, czyli dostarcza 80% zapotrzebowania odbiorców za pomocą 20% funkcji dostępnych w SAX i DOM. Co ciekawe standard działa z parserami SAX oraz DOM.

Największą zaletą JDOM są znacznie mniejsze nakłady informatyczne niezbędne do napisania odpowiedniej aplikacji ingerującej w kod XML. Aplikacje napisane w standardzie JDOM stanowią zwykle ledwie jedną trzecią tożsamej aplikacji napisanej w DOM. Niestety kosztem tego rozwiązania są ograniczone możliwości standardu JDOM (pozostałe 20%), ale ponieważ można zastosować parsery zarówno DOM jak i SAX, brakujące elementy można stworzyć w jednym z tych formatów.

 

Java API dla XML (JAXP)

Pomimo tego, że standardy DOM, SAX i JDOM zaspokajają większość potrzeb, nadal pozostaje kilka nie rozwiązanych problemów trapiących użytkowników wszystkich trzech standardów. Istnieją np. rozbieżności w deklarowaniu obiektu w parserach DOM (każdy z nich robi to w inny sposób, w związku z czym zmiana parsera wiąże się z rozległymi zmianami oprogramowania, które z niego korzysta). Z powodu tych problemów Sun stworzył Java API do parsowania XML, który zawiera standardowe metody przetwarzania dokumentów XML przy użyciu DOM, SAX i XSLT. Jest to nic innego jak zestaw typowych procedur takich, jak DocumentBuilderFactory czy DocumentBuilder, które ujednolicają komunikację programów z różnymi parserami składni.

 

Który standard wybrać?

Ustalenie najlepszego standardu jest skomplikowaną operacją, której skutki trudno jest przecenić. Wybór złego standardu może znacząco ograniczyć możliwości projektowanego oprogramowania i bazy danych albo wręcz sprawić, że praca, zamiast szybsza i bardziej zautomatyzowana, stanie się powolna i uciążliwa. Odpowiedz na poniższe pytania powinna wspomóc proces podejmowania decyzji:

  • Czy twoja aplikacja będzie napisana w języku Java? JAXP działa zarówno z DOM, SAX jak też JDOM. Jeśli zamierzasz tworzyć swoje oprogramowanie w Javie, to powinieneś wykorzystać JAXP, żeby odizolować swoją indywidualną aplikację od różnych metod stosowanych przez parsery.
  • W jaki sposób zamierzasz wdrożyć swoją aplikację? Jeśli aplikacja będzie apletem Javy, a objętość ściąganego przez użytkownika końcowego kodu gra rolę, to warto zastosować parsery SAX zamiast DOM, ponieważ są po prostu mniejsze. Zastosowanie JDOM przyniesie podobny skutek.
  • Czy zamierzasz wielokrotnie analizować poszczególne dokumenty? Jeśli wymogiem w pracy z dokumentem będzie wielokrotne analizowanie każdego dokumentu, to DOM będzie najprawdopodobniej lepszym wyborem niż SAX, ponieważ raz wczytany dokument pozostaje w pamięci i każda kolejna operacja nie wymaga ponownego wczytywania dokumentu.
  • Czy moc obliczeniowa komputera użytkownika będzie mocno ograniczona? Jeśli tak, to SAX będzie lepszym wyborem niż DOM, zwłaszcza jeśli przetwarzasz duże dokumenty. Wczytanie ich w całości na słabym komputerze, co jest niezbędne w przypadku standardu DOM, może zwyczajnie go przeciążyć i utrudnić albo wręcz uniemożliwić użytkownikowi pracę z danym dokumentem.

Warto pamiętać, że w tej części zostały omówione tylko przykładowe interfejsy. Interfejsy API XML istnieją też w innych językach oprogramowania, na przykład w Perlu i Pythonie.

Perl jest bardzo trudnym i mało popularnym językiem, który jednak zasługuje na uwagę ze względu na niewyobrażalną wręcz wydajność pracy z tekstem. Oprogramowanie PTC Arbortext, z którego korzysta m.in. autor niniejszego opracowania, obsługuje wszystkie operacje zamian na tekście za pośrednictwem języka perl. Dla porównania zamiana 300 tysięcy elementów w tekście w Wordzie zajmie kilka minut (zakładając, że komputer w ogóle to wytrzyma). Taka sama zamiana w Arbortext trwa mniej niż jedną dziesiątą sekundy.

Python jest bardzo popularnym i wydajnym językiem programowania wykorzystywanym w projektach internetowych, zwłaszcza platformach typu SaaS. Daje ciekawe możliwości integrowania projektowanych rozwiązań XML z posiadanymi systemami online (stronami internetowymi, sklepami itp.).

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *