01.pdf

Wprowadzenie

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

Ŝ 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 operuj ą 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-

temó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-

tokołu aplikacji bezprzewodowych (WAP) czy asystenty osobiste („organizery”) obsługuj ą ce

zupeł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 towarzyszy

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, dlacze-

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 narz ę -

dzie, a nie jako slogan reklamowy czy kolejn ą „zabawk ę ”. Pami ę taj ą c o tym, spróbujmy odpo-

wiedzie ć na pytanie, czym jest XML.

CotojestXML?

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-

cyzowano ani zestawu znaczników, ani gramatyki j ę zyka. Zestaw znaczników (ang. tag set ) w j ę zyku

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

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

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

imiona naszych dzieci! Mo Ŝ liwo ś ci te zostały przedstawione w przykładzie 1.1.

Przykład1.1.PrzykładowyplikXML

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

<pokoj-jadalny>

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

</table>

<jakosc>doskonała</jakosc>

<kolor>niebieski</kolor>

</poduszka>

</krzeslo>

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

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

rodzaju ograniczenia, ale na razie wystarczy pami ę ta ć , Ŝ e XML został stworzony po to, by zapew-

ni ć elastyczno ść 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łumaczenie

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 pami ę -

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

rozszyfrowania najbardziej popularnych skrótów zwi ą zanych z XML-em. Skróty te s ą niezwykle

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

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

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 polecał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. Pierwsza

mówi, Ŝ e dokument XML, aby był w jakikolwiek sposób przydatny i mógł zosta ć przetworzony,

musi by ć poprawnie uformowany . Poprawnie uformowany dokument to taki, w którym ka Ŝ demu

znacznikowi otwieraj ą cemu odpowiada znacznik zamykaj ą cy, w którym znaczniki nie s ą zagnie Ŝ -

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

niki 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 znacz-

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-

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

jednak musimy pozna ć kilka skrótów i specyfikacji u Ŝ ywanych wewn ą trz dokumentu XML.

PI to instrukcja przetwarzania (ang. processing instruction ) w dokumencie XML. Instrukcja prze-

twarzania 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 przekazy-

wane parserowi XML lub innemu programowi korzystaj ą cemu z dokumentu. W naszym przykł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-

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

winny 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 „zapotrzebo-

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-

kumentu 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 ć

skonstruowany dokument XML. Ponownie spójrzmy na przykład 1.1. Cho ć stworzyli ś my grup ę

własnych znaczników, to dokument taki jest bezu Ŝ yteczny dla innej aplikacji, a nawet dla innego

u Ŝ ytkownika, 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 znaczniku <krzeslo> ? Je ś li dokument ma zosta ć poprawnie przetworzony przez parser, na te

wszystkie 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 zawrze ć j ą w samym pliku XML — w ka Ŝ dym razie definicja nie ingeruje w Ŝ aden sposób w do-

kument 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 „maho ń ”. Dzi ę ki temu parser potrafi okre ś li ć , czy zawarto ść dokumentu jest do przyj ę cia,

i zapobiec 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

przykładowy plik XML, wie, jak przetworzy ć i przeszukiwa ć otrzymane dane. Definicja DTD nie tylko

przyczynia si ę do wysokiej elastyczno ś ci formatowania danych w XML-u, ale tak Ŝ e umo Ŝ liwia

przetwarzanie i sprawdzanie poprawno ś ci danych w dowolnym systemie potrafi ą cym odnale źć t ę

definicj ę .

Przestrzeńnazw

Przestrze ń nazw to jedno z niewielu poj ęć zwi ą zanych z XML-em, dla których nie wymy ś lono

akronimu. Nie ma takiej potrzeby — w tym przypadku nazwa dobrze odpowiada funkcji tego elementu.

Przestrze ń nazw (ang. namespace ) to odwzorowanie pomi ę dzy przedrostkiem elementu a identyfikato-

rem URI. Odwzorowanie to umo Ŝ liwia zapobie Ŝ enie kolizjom przestrzeni nazw oraz okre ś lenie struktur

danych, które pozwalaj ą parserom zapobiec takim kolizjom. Przeanalizujmy przykład kolizji przestrze-

ni nazw. Załó Ŝ my, Ŝ e w dokumencie pomi ę dzy znacznikami <krzeslo> i </krzeslo> znajduje

si ę znacznik <cena> . Ale w ramach definicji krzesła jest te Ŝ znacznik <poduszka> , który przecie Ŝ

tak Ŝ e mo Ŝ e posiada ć własny znacznik <cena> . Zauwa Ŝ my równie Ŝ , Ŝ e dokument mo Ŝ e odwoływa ć

si ę do innego dokumentu XML w celu pobrania informacji o prawach autorskich. W obu dokumentach

powinny pojawi ć si ę znaczniki <data> lub np. <firma> , ale jak rozpozna ć , który znacznik

odwołuje si ę do czego? Taka dwuznaczno ść to problem dla parsera XML. Czy znacznik <cena> ma

by ć interpretowany w ró Ŝ ny sposób zale Ŝ nie od tego, w którym elemencie jest zagnie Ŝ d Ŝ ony? Czy

mo Ŝ e autor zawarto ś ci pomyłkowo u Ŝ ył go w dwóch kontekstach? Bez informacji o przestrzeni nazw

nie jest mo Ŝ liwe okre ś lenie, czy był to bł ą d w konstrukcji dokumentu XML, a je ś li było to działanie

celowe — jak rozporz ą dzi ć danymi koliduj ą cych znaczników.

Zalecenie opisuj ą ce przestrzenie nazw w XML-u definiuje mechanizm do kwalifikowania nazw.

Mechanizm ten wykonuje swoje zadanie z u Ŝ yciem identyfikatora URI, ale tego na razie nie mu-

simy wiedzie ć . Poprawne stosowanie znaczników w rodzaju opisywanego <cena> nie wymaga

wpisywania niezbyt m ą drych nazw w rodzaju <cena-krzesla> czy <cena-poduszki> .

Zamiast tego przestrze ń nazw tworzona jest z wykorzystaniem przedrostka w postaci elementu

XML — a wi ę c na przykład: <krzeslo:cena> czy <poduszka:cena> . Parser XML umie

potem rozró Ŝ ni ć te przestrzenie i wcale nie trzeba tworzy ć nowych nazw. Przestrzenie nazw s ą

najcz ęś ciej u Ŝ ywane w dokumentach XML, ale pojawiaj ą si ę tak Ŝ e w schematach i arkuszach sty-

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: