Co dalej?              41

XML. W ciągu ostatnich dwóch lat chyba każdy programista w którymś momencie poczuł ciarki na plecach związane z tym skrótem. Ciarki na plecach, choć z różnych powodów: konieczność wyuczenia się kolejnego skrótu, ekscytacja nową technologią, zagubienie. I, co ciekawe, każda z tych reakcji na XML jest uzasadniona. Tak, trzeba zapamiętać nowy skrót, a także skróty jemu towarzyszące: XSL, XSLT, PI, DTD, XHTML i inne. Tak, XML oferuje nowe możliwości: to, co Java wniosła w przenośność kodu, XML ma wnieść w przenośność danych. W ostatnich mie­siącach Sun promuje nawet to rozwiązanie następującym sloganem: „Java + XML = przenośny kod + przenośne dane”. I wreszcie — tak, XML powoduje pewne zagubienie. Spróbujemy przy­bli­żyć i rozgryźć XML — będziemy omawiać go tylko na tyle ogólnie i abstrakcyjnie, żeby nie po­paść w bezużyteczność, i tylko na tyle szczegółowo, żeby nie tworzyć kolejnej suchej specyfikacji. To książka dla programisty Javy, który chce poznać i nauczyć się korzystać z narzędzi ope­rują­cych na tej technologii.

Przed programistą współczesnej aplikacji WWW stoi wiele problemów, których dziesięć lat temu nie było nawet w prognozach. Pojawiła się konieczność uruchamiania szybkich i bezawaryjnych systemów rozproszonych na przestrzeni tysięcy kilometrów, konieczność pobierania danych z sys­te­mów heterogenicznych, baz danych, usług katalogowych i aplikacji bez utraty choćby jednej cyfry po przecinku. Aplikacje muszą porozumiewać się nie tylko z innymi komponentami danej firmy, ale także z innymi systemami biznesowymi — często znajdującymi się w innych firmach i zbudowanymi w oparciu o inne technologie. Klienty to już nie tylko klienty uproszczone (ang. thin client), ale całe przeglądarki WWW obsługujące HTML, telefony komórkowe z obsługą pro­to­kołu aplikacji bezprzewodowych (WAP) czy asystenty osobiste („organizery”) obsługujące zu­peł­nie inne języki znaczników. Oreganizacja danych i ich przetwarzanie — oto podstawowe za­dania współczesnych aplikacji.

XML pozwala programiście sprostać wszystkim tym wyzwaniom. Programiści Javy mają zaś je­szcze do dyspozycji arsenał interfejsów umożliwiających korzystanie z XML-a i jego to­warzy­szy bez konieczności opuszczania zintegrowanego środowiska programistycznego Javy (Integrated Development Environment — IDE). Jeśli to wszystko wydaje się zbyt piękne, by było prawdziwe — warto czytać dalej. Poznamy zalety i wady interfejsów API Javy służących do przeprowadzania operacji na XML-u, a także korzyści płynące z zastosowania najnowszych specyfikacji XML-a. Cały czas będziemy przyjmować punkt widzenia programisty. Ta książka nie mówi o tym, dla­cze­go powinno się korzystać z XML-a, ale jak to robić. Jeśli w specyfikacji znajdą się elementy niezbyt przydatne, to powiemy, dlaczego tak jest, i przejdziemy dalej; jeśli jakieś zagadnienie jest szczególnie godne uwagi, poświęcimy mu więcej czasu. Będziemy traktować XML jako na­rzę­dzie, a nie jako slogan reklamowy czy kolejną „zabawkę”. Pamiętając o tym, spróbujmy od­po­wiedzieć na pytanie, czym jest XML.

Co to jest XML?

XML to Extensible Markup Language, czyli rozszerzalny język znaczników. Podobnie jak jego przodek, SGML, XML jest metajęzykiem służącym do definiowania innych języków. Jest jednak o wiele prostszy i bardziej praktyczny niż SGML. XML to język znaczników, w którym nie spre­cy­zowano ani zestawu znaczników, ani gramatyki języka. Zestaw znaczników (ang. tag set) w ję­zy­ku znaczników określa, jakie znaczniki mają znaczenie dla parsera języka. Na przykład, w HTML-u można używać znaczników ze ściśle określonego zestawu. Możemy wstawić znacznik <TABLE>, ale nie możemy użyć <KRZESLO> (angielskie słowo table oznacza nie tylko tabelę, ale także stół). Pierwszy ze znaczników ma dla aplikacji wykorzystującej dane HTML specyficzne zna­cze­nie, a drugi nie — większość przeglądarek po prostu go zignoruje, ale niektóre mogą zachować się nieprzewidywalnie. Wszystko to dlatego, że kiedy definiowano standard HTML, określono w nim konkretny zestaw znaczników. W każdej kolejnej wersji HTML-a dodawane są nowe znaczniki. Jeśli jednak znacznik nie jest zdefiniowany, to przetwarzanie dokumentu zawierającego taki znacznik może spowodować błąd. Gramatyka języka definiuje poprawne użycie jego znaczników. I znów weźmy HTML jako przykład. Do znacznika <TABLE> można dodać szereg atrybutów, określających szerokość tabeli, kolor tła, wyrównanie itd. Nie możemy jednak wstawić np. atry­butu TYPE, bo nie pozwala na to właśnie gramatyka języka.

XML nie definiuje ani znaczników, ani gramatyki. Ma więc nieograniczone możliwości rozbu­do­wy, jest rozszerzalny — i stąd jego nazwa. Jeśli postanowimy korzystać ze znacznika <TABLE>, a potem jeszcze w danych objętych tym znacznikiem zagnieździć kilka znaczników <KRZESLO>, to bez trudności możemy to zrobić. Jeśli chcielibyśmy zdefiniować atrybut określający typ krzesła, np. TYPE, też mamy taką możliwość. Możemy nawet wstawiać znaczniki o nazwach takich jak imio­na naszych dzieci! Możliwości te zostały przedstawione w przykładzie 1.1.

Przykład 1.1. Przykładowy plik XML

<?xml version="1.0" encoding="ISO-8859-2"?>

<pokoj-jadalny>

  <table typ="okragly" drewno="klon">

    <producent>Drewnosklep S.A.</producent>

  </table>

  <krzeslo drewno="klon">

    <ilosc>2</ilosc>

    <jakosc>doskonała</jakosc>

    <poduszka zawarta="true">

      <kolor>niebieski</kolor>

    </poduszka>

  </krzeslo>

  <krzeslo drewno="dab">

    <ilosc>3</ilosc>

    <jakosc>średnia</jakosc>

  </krzeslo>

</pokoj-jadalny>

Jeśli Czytelnik nigdy nie widział pliku XML, a miał do czynienia tylko z HTML-em lub innymi językami znaczników, to przykład może się wydawać dość osobliwy. To dlatego, że znaczniki i gra­matyka opisująca dane zostały w całości zmyślone. Żadna strona WWW ani specyfikacja nie definiuje znaczników <table>, <krzeslo> czy poduszka (ale mogłoby tak być — w po­do­bny sposób specyfikacja XHTML definiuje znaczniki HTML wewnątrz XML-a). Tu właśnie drze­mie siła XML-a — umożliwia on definiowanie zawartości danych na różne sposoby i wymaga jedynie zgodności z ogólną strukturą języka. W dalszej części książki są przedstawione różnego ro­dzaju ograniczenia, ale na razie wystarczy pamiętać, że XML został stworzony po to, by za­pew­nić ela­sty­czność formatowania danych.

Ta elastyczność jest jedną z największych zalet XML-a, a jednocześnie jedną z jego największych wad. Dokumenty XML można przetwarzać na tak wiele różnych sposobów i w tak wielu różnych celach, że powstała bardzo duża liczba związanych z XML-em standardów opisujących tłuma­cze­nie formatów danych i same formaty. Te dodatkowe skróty i ich nieustanne pojawianie się „w oko­licach” XML-a często powoduje błędne rozumienie idei tego standardu. Kiedy ktoś mówi „XML”, to jest niemal pewne, że nie ma na myśli samego języka XML, tylko jedno z towarzyszących mu narzędzi. Niejednokrotnie zajmować się będziemy właśnie tymi narzędziami; trzeba jednak pa­mię­tać, że najczęściej „XML” nie oznacza samego języka, lecz „XML i towarzyszące mu wspaniałe metody manipulowania danymi”. Skoro to rozróżnienie mamy już za sobą, możemy przejść do roz­szyfrowania najbardziej popularnych skrótów związanych z XML-em. Skróty te są nie­zwy­kle istotne dla całej książki, a więc warto zostawić w tym miejscu zakładkę, aby móc w każdej chwili zajrzeć na te strony. Poniższe opisy powinny przybliżyć Czytelnikowi wzajemne związki między narzędziami związanymi z XML-em oraz wyjaśnić, czym jest XML. Nie będziemy tutaj omawiać mechanizmów publikacyjnych, aplikacji i narzędzi dla XML-a, bo są one przedstawione w dalszej części książki. Poniżej Czytelnik znajdzie informacje jedynie o specyfikacjach i zale­ce­niach. Większość z nich powstała z inicjatywy W3C (World Wide Web Consortium). Organizacja ta zajmuje się definiowaniem standardów XML i spełnia rolę podstawowej bazy informacji o tym standardzie — podobnie jak firma Sun jest podstawowym źródłem informacji o Javie i związanych z nią interfejsach API. Więcej informacji o W3C można znaleźć pod adresem http://www.w3.org.

XML

XML to oczywiście punkt wyjścia wszystkich tych trzy- i czteroliterowych skrótów. Definiuje sam język i określa strukturę metadanych. XML sam w sobie ma niewielką wartość — to tylko stru­k­tura. Ale rozmaite technologie bazujące na tej strukturze dają programistom i administratorom zawartości niespotykaną do tej pory elastyczność w zarządzaniu i przesyłaniu danych. XML ma już status ukończonego zalecenia W3C, co oznacza, że nic się nie zmieni aż do opublikowania nowej wersji standardu. Pełna specyfikacja XML 1.0 znajduje się pod adresem http://www.­w3.­org/ TR/REC-xml/. Specyfikacja ta jest trudną lekturą nawet dla programistów dobrze znających XML, więc po­le­cał­bym raczej zapoznanie się z jej doskonałą wersją opatrzoną komentarzami, dostępną pod adresem http://www.xml.com.

Temat ten będzie w dalszych rozdziałach omawiany szczegółowo, więc teraz wystarczy pamiętać o dwóch podstawowych koncepcjach koniecznych do zrozumienia istoty dokumentu XML. Pierw­sza mówi, że dokument XML, aby był w jakikolwiek sposób przydatny i mógł zostać przetwo­rzo­ny, musi być poprawnie uformowany. Poprawnie uformowany dokument to taki, w którym każ­de­mu znacznikowi otwierającemu odpowiada znacznik zamykający, w którym znaczniki nie są za­gnież­dżone niezgodnie z regułami oraz którego składnia jest zgodna ze specyfikacją. Ale zaraz — czyż nie powiedzieliśmy wcześniej, że XML nie posiada żadnych reguł składniowych? Niezupełnie. Powiedzieliśmy, że nie ma reguł gramatycznych. Dany dokument może definiować własne zna­cz­ni­ki i atrybuty, ale wciąż musi być zgodny z regułami ogólnymi. Reguły te wykorzystywane są następnie przez aplikacje i parsery znające XML w celu odczytania danych z dokumentu i wy­konania na nich pewnych czynności — np. znalezienia ceny krzesła czy utworzenia z danych dokumentu PDF. Zagadnienie to jest dokładniej omówione w rozdziale 2., Pisanie w XML-u.

Druga istotna koncepcja związana z dokumentami XML mówi, że mogą one — ale nie muszą — być poprawne. Poprawny dokument to taki, który spełnia wymagania odpowiadającej mu definicji typu dokumentu DTD (o niej za chwilę). Mówiąc krótko, DTD definiuje gramatykę i zestaw zna­cz­ników na potrzeby określonego formatowania XML. Jeśli w dokumencie określono konkretną de­finicję DTD i jeśli jest on zgodny z tą definicją, to dokument taki określa się jako poprawny. Dokumenty XML mogą zostać także zawężone w ramach schematu — jest to nowy sposób narzu­ca­nia formatu XML, który wyprze DTD. Dokument może być więc także zgodny ze schematem. W dalszej części książki zajmiemy się dokładniej przedstawionymi wyżej zagadnieniami. Naj­pierw jednak musimy poznać kilka skrótów i specyfikacji używanych wewnątrz dokumentu XML.

PI

PI to instrukcja przetwarzania (ang. processing instruction) w dokumencie XML. Instrukcja prze­twa­rzania nakazuje aplikacji wykonanie określonego zadania. Instrukcje PI, choć zajmują niewiele miejsca w specyfikacji XML, są na tyle ważne, że znalazły się wśród omawianych akronimów. PI wyróżnia się spośród innych danych w dokumencie XML tym, że oznacza polecenie prze­ka­zy­wa­ne parserowi XML lub innemu programowi korzystającemu z dokumentu. W naszym przy­kła­dowym dokumencie 1.1 pierwszy wiersz, wskazujący wersję standardu XML, stanowi instrukcję przetwarzania. Informuje parsery, z której wersji standardu będziemy korzystać. Instrukcje prze­twa­rzania mają postać <?cel instrukcje?>. Wszystkie instrukcje PI, w których jako cel okreś­lono XML, należą do standardowego zestawu instrukcji określonego w ramach XML-a i po­win­ny być rozpoznawane przez parsery. Nazywa się je często instrukcjami XML. Ale instrukcje PI mogą także zawierać informacje, które mają zostać wykorzystane przez aplikacje przechwytujące czynności parsera; w takim przypadku jako cel instrukcji przetwarzania można określić słowo klu­czowe odpowiadające danej aplikacji (np. „cocoon”).

Instrukcje przetwarzania nabierają dużego znaczenia, gdy dane XML wykorzystywane są w apli­kacjach znających ten standard. Rozważmy aplikację, która przetwarza nasz przykładowy plik XML, a następnie tworzy reklamę mebli opartą na produktach wymienionych w dokumencie. Instrukcja przetwarzania może poinformować aplikację, że dany mebel jest na liście „za­po­trze­bo­wania” i że ma zostać przekazany do innej aplikacji, np. takiej, która wysyła zamówienia — zatem taki mebel ma nie pojawiać się w reklamie. Parser XML rozpozna instrukcje PI odwołujące się do celów zewnętrznych i przekaże je w niezmienionej postaci zewnętrznym aplikacjom.

DTD

DTD to document type definition, czyli definicja typu dokumentu. DTD narzuca szereg ograniczeń na dokument (lub grupę dokumentów) XML. Definicja DTD sama w sobie nie jest specyfikacją, ale została zdefiniowana jako część specyfikacji XML. Deklaracja typu dokumentu wewnątrz do­ku­mentu XML może sama zawierać ograniczenia odnośnie znaczników, ale może także odwo­ły­wać się do zewnętrznego dokumentu opisującego takie ograniczenia. Definicją typu dokumentu jest suma tych dwóch powyższych zestawów ograniczeń. DTD definiuje sposób, w jaki ma być skon­­struo­wa­ny dokument XML. Ponownie spójrzmy na przykład 1.1. Choć stworzyliśmy grupę włas­nych znaczników, to dokument taki jest bezużyteczny dla innej aplikacji, a nawet dla innego użyt­­kow­ni­ka, który nie potrafi zinterpretować naszych znaczników. Powstają wątpliwości — czy znacznik <ilosc> mówi nam, ile krzeseł jest na stanie? Czy atrybut drewno może zostać użyty w zna­cz­niku <krzeslo>? Jeśli dokument ma zostać poprawnie przetworzony przez parser, na te wszy­stkie pytania trzeba znaleźć odpowiedzi. Dokument uważa się za poprawny, jeśli jest zgodny z ograniczeniami narzucanymi przez DTD odnośnie formatowania danych XML. Jest to szcze­gólnie istotne, gdy zamierzamy przenosić dane pomiędzy aplikacjami — wymaga to uzgodnienia formatu i składni, aby dwa różne systemy mogły się porozumieć.

Jak już wcześniej wspomniano, definicja DTD definiuje ograniczenia, mówiąc inaczej — zawęża konkretny dokument lub zestaw dokumentów XML. Programista lub autor zawartości tworzy także definicję DTD w postaci dodatkowego dokumentu, do którego odwołuje się z plików XML; może także za­wrzeć ją w samym pliku XML — w każdym razie definicja nie ingeruje w żaden sposób w do­ku­ment XML. Tak naprawdę to właśnie DTD przyczynia się do przenośności danych XML. Może ona na przykład określać, że jedynymi poprawnymi wartościami atrybutu drewno są „klon”, „sosna”, „dąb” i „ma­hoń”. Dzięki temu parser potrafi określić, czy zawartość dokumentu jest do przy­jęcia, i za­pobiec ewentualnym błędom formatowania danych. Definicja DTD określa także kolejność za­gnież­dżania znaczników. Może na przykład stanowić, że znacznik <poduszka> ma prawo być zagnieżdżany jedynie w znacznikach <krzeslo>. Dzięki temu inna aplikacja, która otrzymuje nasz przy­kładowy plik XML, wie, jak przetworzyć i przeszukiwać otrzymane dane. Defi...