14-08, Programowanie, ! Java, Java i XML

XML Schema

XML Schema jest przedmiotem gorących dyskusji programistów korzystających z języka XML. Ostatnie rozdziały dotyczyły głównie sposobów manipulowania danymi XML za pomocą Javy; teraz zostanie przedstawiona XML Schema. Schematy XML to temat względnie nowy, a obsługa tej technologii ze strony klas i interfejsów Javy powstawała powoli.

Mimo trudności związanych z korzystaniem z XML Schema bezpośrednio z poziomu Javy, specyfikacja ta jest na tyle ważna, że zostanie jej poświęcony cały rozdział. Najpierw zastanowimy się, czy jest to technologia stabilna i czy stanowi dobry wybór w porównaniu z definicjami DTD. Potem przyjrzymy się, jak XML Schema odwzorowuje się na język Java oraz jak relacja ta może wpłynąć na sposób składowania zawartości XML.

Definicje DTD — --> stosować [Author:RG] czy nie?

Niemal każdy programista lub twórca zawartości XML słyszał o schematach XML; wciąż jednak niewiele osób jest do końca przekonanych, że „nadszedł już czas” tej technologii. Wątpliwości wynikają po części ze zmian i z małej „dojrzałości” specyfikacji XML; w większym stopniu są jednak związane z faktem, że definicje DTD są już dobrze znane. Wielu programistów XML wciąż zawęża dokumenty wyłącznie za pomocą DTD, nie bacząc na wzrastającą popularność XML Schema. Przed podjęciem decyzji o zaadaptowaniu nowej technologii trzeba rozważyć wszelkie za i przeciw.

Stabilność specyfikacji XML Schema

Jednym z największych problemów schematów XML są ciągłe zmiany wprowadzane w ich specyfikacji (patrz http://www.w3.org/TR/xmlschema-1/ oraz http://www.w3.org/TR/xmlschema-2/). W ciągu sześciu miesięcy (od sierpnia 1999 do marca 2000 r.) opublikowano trzy wersje specyfikacji; fakt ten sam w sobie nie jest niczym dziwnym, ale tutaj liczy się jeszcze coś innego — poczynione zmiany były bardzo istotne. Po wprowadzeniu kolejnej wersji schematy zgodne z poprzednimi stawały się praktycznie bezużyteczne — to nie mogło się podobać. Co więcej, w miarę upływu czasu specyfikacja XML Schema wydawała się coraz bardziej złożona, co jeszcze bardziej pogarszało nastroje programistów.

Ale mimo całej tej „nieprzychylnej prasy”, specyfikacja XML Schema wydaje się obecnie przynajmniej tak ważna, jak sam XML. Konsorcjum W3C zawsze zresztą ostrzegało, że dopóki nie zostanie opublikowana finalna wersja specyfikacji, zmiany będą nieuniknione. Co ciekawe, osoby narzekające na częste zmiany to często ci sami, którzy domagają się wprowadzenia pewnych zmian! Innymi słowy, częste zmiany w specyfikacji nie usprawiedliwiają jeszcze zaniechania korzystania z XML Schema. Niemal wszystkie zmiany, również te mniej istotne, przyczyniają się do zwiększenia przejrzystości i użyteczności specyfikacji.

Lepsze sposoby zawężenia dokumentu

Chyba nie byłoby możliwe opisywanie schematów bez podkreślenia (już nie po raz pierwszy w tej książce) prostoty zawężania za pomocą XML Schema. Trudno znaleźć kogokolwiek (nawet wśród tych zatwardziałych zwolenników DTD), kto odmówiłby tej specyfikacji elastyczności i prostoty, z jaką określa się zawężenia danych. Co więcej, ta właśnie cecha usuwa w cień ważniejsze pod względem merytorycznym aspekty schematów! Prawda jest taka, że twórca dowolnej aplikacji, w której konieczne jest określenie ścisłych typów danych i zakresów, musi korzystać z XML Schema. To pozwoli oszczędzić całe dni, jeśli nie tygodnie, wytężonej pracy.

Oprócz tradycyjnych zawężeń, XML Schema umożliwia budowanie zawężeń modelu zawartości dla ogólnych formatów danych. Zawężenia takie mogą być potem współużytkowane i wykorzystywane przez inne schematy poprzez XLink lub XPointer. Definicje DTD, same w sobie nie będące dokumentami XML, mają w tym zakresie bardzo ograniczone możliwości. W przypadku dużych aplikacji definicje DTD rozrośnięte do tysięcy wierszy to nic nadzwyczajnego. Takie podejście do --> danych trudno nazwać obiektowym, nie mówiąc już o trudnościach w sprawdzaniu poprawności danych[Author:RG] .

Definicje DTD — problemy z przestrzeniami nazw

Czytelnik wie już, że przetwarzanie dokumentu XML wykorzystującego przestrzenie nazw i wymagającego sprawdzenia poprawności może sprawić poważne kłopoty, jeśli wybrane zostały definicje DTD. Przypomnijmy sobie ten kod:

DOMParser parser = new DOMParser();

// Włączamy obsługę przestrzeni nazw.

parser.setFeature("http://xml.org/sax/features/namespaces", true);

// Włączamy sprawdzanie poprawności.

parser.setFeature("http://xml.org/sax/features/validation", true);

// Przetwarzamy.

parser.parse();

// Pobieramy wyniki.

Document doc = parser.getDocument();

Po kompilacji tego kodu (wewnątrz jakiejś aplikacji) wykonanie spowoduje następujący błąd krytyczny (przykład z Apache Xerces; inne parsery powinny zwrócić podobne komunikaty):

org.xml.sax.SAXParseException: Document root element "JavaXML:Ksiazka", must

match DOCTYPE root "JavaXML:Ksiazka".

at org.apache.xerces.framework.XMLParser.reportError

(XMLParser.java:1318)

at org.apache.xerces.validators.dtd.DTDValidator

.reportRecoverableXMLError(DTDValidator.java:1602)

at org.apache.xerces.validators.dtd

.DTDValidator.footElementSpecified(DTDValidator.java:576)

at org.apache.xerces.framework.XMLParser

.scanAttributeName(XMLParser.java:2076)

at org.apache.xerces.framework.XMLDocumentScanner

.scanElement(XMLDocumentScanner.java, Compiled Code)

at org.apache.xerces.framework

.XMLDocumentScanner$ContentDispatcher.dispatch

(XMLDocumentScanner.java, Compiled Code)

at org.apache.xerces.framework.XMLDocumentScanner

.parseSome(XMLDocumentScanner.java, Compiled Code)

at org.apache.xerces.framework

.XMLParser.parse(XMLParser.java:1208)

at org.apache.xerces.framework

.XMLParser.parse(XMLParser.java:1247)

Błąd wynika z faktu, że definicje DTD ignorują przestrzenie nazw; nie ignoruje ich natomiast mechanizm obsługujący element główny i konstrukcje znajdujące się wewnątrz niego. Ta rozbieżność powoduje konflikty pomiędzy sprawdzaniem poprawności i przetwarzaniem przestrzeni nazw. Dokumenty XML często wymagają wykonania i jednego, i drugiego — co jeszcze bardziej zwiększa atrakcyjność schematów. Co więcej, XML Schema łatwo „przekłada się” na język Java i możliwości przyszłej integracji są bardzo interesujące.

Podobieństwo do Javy

W miarę stabilizacji specyfikacji XML Schema zwiększyło się podobieństwo schematów do definicji klas i interfejsów Javy. XML Schema — choć to przecież tylko ścisły zestaw zawężeń — bardzo przypomina kod, jaki piszemy w Javie, definiując klasę lub interfejs. Schemat określa zestaw danych, jakie dozwolone są w danym dokumencie XML; klasa lub interfejs określają metody i zmienne reprezentowane przez dany egzemplarz klasy. Podobnie jak program w Javie musi tylko „znać” definicję, aby korzystać z egzemplarza (bez znajomości detali implementacyjnych, takich jak adres w pamięci czy zawartość), aplikacja w XML-u musi tylko „znać” zawężenia dokumentu (zdefiniowane w XML Schema), aby móc z takiego dokumentu korzystać.

Być może to podobieństwo nie wydaje się Czytelnikowi zbyt istotne; jednak to właśnie ta cecha może w ogromnym stopniu przyczynić się do powszechnego stosowania XML-a w nowych aplikacjach oraz w nowych implementacjach starych technologii. Tutaj zostaną opisane tylko niektóre z tych ważnych zastosowań; Czytelnik sam będzie potrafił „dopowiedzieć” sobie pozostałe i przełożyć tę wiedzę na własne aplikacje.

Równoważność

Istotną cechą XML Schema jest równoważność elementów. W XML 1.0 oraz w definicjach DTD jeden typ elementu musiał być odwzorowany na jeden element. Innymi słowy, jeśli dwa elementy współużytkowały identyczną zawartość, oba musiały zostać jawnie zdefiniowane:

<!ELEMENT element1 (element2, element3*)>

<!ATTLIST element1

atrybut1 CDATA #REQUIRED

atrybut2 (cos|tam) "cos"

<!ELEMENT takiJakElement1 (element2, element3*)>

<!ATTLIST takiJakElement1

atrybut1 CDATA #REQUIRED

atrybut2 (cos|tam) "cos"

Widać, że jest tutaj dużo nadmiarowości; ponadto taki zapis podatny jest na błędy — jeśli definicja jednego elementu zostanie zmieniona, a drugiego nie. XML Schema, wprowadzając typy, rozwiązuje ten problem:

</simpleType>

</attribute>

</complexType>

Dzięki temu mechanizmowi wystarczy zdefiniować typ elementu i potem stosować go dla różnych elementów. Jest to podobne do języka Java, w którym definiuje się klasę, a następnie tworzy różne jej egzemplarze. Ale XML Schema ma jeszcze inne ciekawe cechy. Oto fragment dokumentu XML reprezentującego fakturę transportową:

<nazwa>Waza ceramiczna</nazwa>

<jakosc>doskonała</jakosc>

</produkt>

<nazwa>Naczynie z kryształu</nazwa>

<jakosc>dobra</jakosc>

</produkt>

</faktura>

Zarówno dostawca, jak i producent może chcieć dopisać dodatkowe informacje dotyczące produktów w fakturze, np. może chcieć poinformować o pochodzeniu kryształowych naczyń albo o tym, że dwie wazy się stłukły:

<nazwa>Waza ceramiczna</nazwa>

<jakosc>doskonała</jakosc>

<komentarz>2 wazy stłuczone w czasie transportu</komentarz>

</produkt>

<nazwa>Naczynie z kryształu</nazwa>

<jakosc>dobra</jakosc>

<komentarz>Naczynia zakupione w Wenecji, Włochy</komentarz>

</produkt>

</faktura>

Problem polega na tym, że źródło komentarzy nie jest jednoznaczne — mógł je dołączyć dostawca, producent lub pośrednik. Sprawę rozwiązuje zmiana nazw elementów:

<nazwa>Waza ceramiczna</nazwa>

<jakosc>doskonała</jakosc>

<komentarzDostawcy>2 wazy stłuczone w czasie transportu</komentarzDostawcy>

</produkt>

<nazwa>Naczynie z kryształu</nazwa>

<jakosc>dobra</jakosc>

<komentarzPosrednika>Naczynia zakupione w Wenecji, Włochy</komentarzPosrednika>

</produkt>

</faktura>

To zwiększa przejrzystość dokumentu, ale powoduje pewne zagmatwanie schematu:

</complexType>

</element>

</complexType>

</element>

Zdefiniowano tutaj trzy różne elementy opisujące komentarze. Każdy z nich może wystąpić zero lub więcej razy w elemencie produkt. Nie ma w tym nic błędnego, ale nieco niemądre wydaje się pozwalanie na wystąpienie każdego z tych trzech elementów, bo przecież każdy z nich zawiera taki sam typ danych; komentarz obsługiwany jest zawsze jako dane tekstowe. W Javie problem można byłoby rozwiązać definiując klasę Komentarz, a następnie rozszerzając ją na KomentarzPosrednika, KomentarzDostawcy i KomentarzProducenta. To pozwoliłoby na wystąpienie w elemencie produkt jednego lub więcej typów Komentarz (w XML-u komentarz). Na szczęście twórcy XML Schema myśleli podobnie i dzięki temu w schematach mamy słowo kluczowe equivClass. Definiuje się pewien element, a potem inne elementy jako równoważne z tym pierwszym. Te równoważne elementy mogą potem zostać podstawione w miejsce elementu bazowego, określanego mianem wzoru (ang. exemplar). Takie rozwiązanie bardzo upraszcza schemat:

<element ref="komentarz" minOccurs="0" />

</complexType>

</element>

</complexType>

</element>

Ten nowy schemat precyzyjniej odzwierciedla zamiar autora i bardziej przypomina składnię Javy. W elemencie produkt może wystąpić dowolny element równoważny z elementem komentarz, a relacjami równoważności „zajmie się” już sam proces sprawdzania zgodności z zawężeniami. Można pójść jeszcze o krok dalej i zastosować takie konstrukcje na danych w aplikacjach w Javie — to rozwiązanie zostanie przedstawione w następnym podrozdziale.

Uzupełnianie kodu Javy schematem

Spróbujmy spojrzeć na klasę Javy jak na zestaw zawężeń, a na egzemplarz klasy jak na dane zgodne z tymi zawężeniami. W tym przypadku dane mają postać binarną (kod bajtowy). Zawężenia definiują zmienne, które można wypełnić danymi, metody, które można zaimplementować, oraz dozwolone dane wejściowe i wyjściowe. Jednakże same wartości zmiennych i metod nie są znane i pozostają nieokreślone aż do momentu uruchomienia programu. Podobnie jak autor zawartości „wypełnia” dokument XML danymi zgodnymi ze schematem, aplikacja „wypełnia” egzemplarz wartościami odpowiednimi dla wykonywanego właśnie zadania. Cała ta konstrukcja może zostać „powielona” w kolejnych warstwach, jeśli jako kolejny zestaw zawężeń uznamy interfejs Javy; tym razem „elementami” są definicje klas. W interfejsie definiowane są sygnatury metod, dozwolone obiekty wejściowe i wyjściowe, zdefiniowane jest także, czego muszą przestrzegać klasy implementujące interfejs. Interfejs zawęża definicje klas, które z kolei zawężają egzemplarze.

Taki łańcuch zawężeń umożliwia wysoce efektywne modelowanie i projektowanie obiektowe; jednak dane, którymi „wypełniane” są wartości w egzemplarzu klasy, nie są zawężane w inny sposób niż poprzez podanie ich typu. Na przykład, dopuszczalne są dowolne wartości, o ile są typu int. Dalsze zawężanie wymaga stworzenia odpowiedniego kodu wewnątrz implementacji klasy lub metody. Podobnie nieograniczone są wartości zwracane. Jeśli więc wartość wywoływanej metody musi mieścić się w pewnym ściśle określonym przedziale, klient aplikacji musi sam wykonać sprawdzanie poprawności. To wymaga dodatkowego kodowania oraz może sprawiać wrażenie dwuznaczności z punktu widzenia osób, które będą w przyszłości korzystały ze stworzonych przez nas klas. Zwracane wartości mogą nie mieścić się w zakresie wartości dozwolonych przez klienta; jeśli jawnie nie zostanie wykonane sprawdzanie poprawności, może to doprowadzić do nieoczekiwanych — i poważnych — błędów.

W takich przypadkach Javę doskonale uzupełnia XML Schema. Ponieważ schemat zawęża dane dozwolone przez zmienne przynależne do egzemplarza klasy, umożliwia o wiele precyzyjniejsze kontrolowanie danych zwracanych klientom z wywołań metod. XML Schema może również służyć do definiowania wartości dozwolonych w egzemplarzu klasy. Jako przykład niech posłużą niektóre zmienne przynależne stworzonej w poprzednich rozdziałach klasy procedury obsługi XmlRpcConfiguration:

private String uri;

private String hostname;

private int portNumber = 0;

private Hashtable handlers;

Problem polega na tym, że nazwa hosta może mieć ograniczoną długość; numer portu powinien być zawsze dodatnią liczbą całkowitą mniejszą od 64000; a procedury obsługi mogą mieć jeszcze inne ograniczenia. Klient XML-RPC może jednak wysłać dowolny typ wartości, a więc procedura obsługi musi wykonać sprawdzanie poprawności. Jednak do definicji klasy w Javie można byłoby przecież dodać następujący schemat (tutaj fragment), definiujący dozwolone parametry danych:

</simpleType>

</attribute>

</simpleType>

</attribute>

Każda zmienna przynależna traktowana jest jako atrybut samej klasy. Jeśli naszemu kodowi w Javie towarzyszy schemat taki jak powyższy, sprawdzanie poprawności może odbyć się poza kodem, za pomocą standardowego mechanizmu. Oprócz tego klient może działać bardziej inteligentnie — rozumie, jakie wartości są dozwolone, i zna wszystkie zawężenia.

Integracja takiego mechanizmu na poziomie wirtualnej maszyny Javy (JVM) to jeszcze odległa przyszłość, ale już teraz warto zacząć zastanawiać się nad tym, w jaki sposób przeprowadzamy sprawdzanie poprawności. Jeśli konwertujemy zawężenia danych z DTD na XML Schema, to już samo to działanie jest dobrym treningiem przed wprowadzeniem nowych rozwiązań. Są również sposoby na zintegrowanie zawężeń XML Schema z logiką aplikacji poprzez konwersję zawężeń.

Dopasowanie wzorca

Teraz zostaną omówione możliwości dopasowania wzorca w XML Schema. Czytelnik wie już, że zastosowanie XML Schema pozwala uniknąć skomplikowanego sprawdzania poprawności w kodzie Javy. Takie rozwiązanie ma jednak zastosowanie tylko wtedy, gdy schemat potrafi więcej, niż tylko definiować proste zakresy numeryczne i długości zmiennych String. Bardziej skomplikowane jest na przykład zdefiniowanie, że w danej zmiennej może znaleźć się wartość typu „waluta”, i to o określonym formatowaniu. W takim przypadku konieczne jest zastosowanie dopasowania wzorca — bo przecież choćby samą walutę dolarową można zapisać na bardzo wiele sposobów (tutaj zapis amerykański):

$4.50

$45.96

$54

$45.6

Aby schematy nadawały się do przeprowadzania sprawdzania poprawności, „obsługa” takich wartości jak powyższe musi być możliwa. XML Schema umożliwia wykonanie dopasowania wzorca poprzez atrybut pattern powiązany z elementem lub atrybutem. Typ „walutowy” można przedstawić jako następującą definicję; wymagamy w niej wystąpienia wartości w jednym z powyższych formatów (i zaczynających się od znaku dolara):

</simpleType>

Znak dolara jest wymagany. Dalej występuje sekwencja dowolnej liczby cyfr ([0-9]+), a następnie — na co wskazuje znak zapytania „otaczający” całą grupę w nawiasach — opcjonalna końcówka oznaczająca centy (np. $4.50). I znów mogą tutaj wystąpić cyfry, ale tylko jedna lub dwie ({1,2}); na dodatek muszą one być poprzedzone kropką dziesiętną (.).

Jak zauważy niejeden znawca Perla i wyrażeń regularnych, to bardzo prosty przykład. Ukazuje on jednak sposób, w jaki można określić zawężenia w schematach, przy użyciu wyrażeń regularnych. Więcej informacji o obsługiwanych konstrukcjach wyrażeń regularnych można znaleźć w specyfikacji XML. Dzięki wyrażeniom regularnym można przeprowadzić bardzo złożone sprawdzanie poprawności, a tym samym odciążyć kod napisany w Javie.

XML-RPC i systemy rozproszone

Zawężanie jako uzupełnienie kodu w Javie ma szczególne znaczenie w przypadku technologii XML-RPC, która została już wcześniej opisana. Obecnie biblioteki XML-RPC oferują wstępnie zdefiniowany zestaw typów zmiennych, jakie można przekazywać pomiędzy serwerem a klientem. Dzięki wprowadzeniu zawężeń --> dotyczących [Author:RG] tego, co może zostać przesłane w sieci, klient może mieć tylko ogólne pojęcie o procedurach obsługi dostępnych na serwerze, a jednak nie przeszkadza to w osiągnięciu udanego „porozumienia”. Jednakże wciąż nie wiemy, jakie zakresy wartości są dopuszczalne na wejściu, a jakie zwracane na wyjściu. To — mogłoby się wydawać — niewielki problem; a jednak umiejętność nakreślenia przez procedurę obsługi takich zawężeń i umiejętność rozpoznania ich przez klienta może potem oszczędzić wiele czasu przy przetwarzaniu
i bardzo zwiększyć użyteczność aplikacji.

Kiedy w schemacie zdefiniujemy zakresy i właściwości danych wejściowych i wyjściowych procedur obsługi XML-RPC, klient uzyskuje pełną „instrukcję obsługi” takiej procedury. Ma to również duże znaczenie w przypadkach, gdy jeden programista zamierza korzystać z klas innego programisty. Wiemy nie tylko o tym, że trzeba dostarczyć jakieś dane wejściowe, ale również o tym, jak powinny one być skonstruowane, aby dało się z nich skorzystać. Możliwe jest więc niemal całkowite wyeliminowanie wyjątków zgłaszanych w wyniku dostarczenia niepoprawnych danych. Takie bardziej kompletne odwzorowanie procedur obsługi XML-RPC można potem rozszerzyć na inne systemy rozproszone; głównym kandydatem byłby tutaj system EJB. Przecież XML Schema może zawężać nie tylko sposób komunikacji ze zdalnym interfejsem, ale również dane, jakie są dozwolone na wejściu i wyjściu interfejsu zdalnego. Te dodatkowe informacje bardzo zwiększyłyby użyteczność i niezawodność systemów rozproszonych, szczególnie wtedy, gdy programiści obiektów typu „bean” czy procedur obsługi nie mogą bezpośrednio komunikować się z programistami klientów.

Bazy danych i XML

Z dodatkowym zawężaniem danych i odwzorowaniami dostępnymi w XML Schema może się wiązać przewrót w jeszcze jednej dziedzinie — wszędzie tam, gdzie język XML jest wykorzystywany w bazach danych. I nie chodzi tutaj o bazy danych w postaci „czystego XML-a”. Owszem, i takie są tworzone, ale to technologie bardzo młode i na pewno napotkają na duży opór tradycjonalistów. Na razie nie istnieje zresztą wystarczający powód do przekształcania istniejących relacyjnych baz danych na nowy format. Warto jednak zwrócić uwagę na to, w jaki sposób język XML jest wykorzystywany do odwzorowania danych z programu w Javie (lub innym języku) na relacyjną lub obiektową bazę danych.

I znów — odwzorowania takie robi się już teraz, ale nie odzwierciedlają one ograniczeń fizycznych, jakie w bazie mogą występować. Jeszcze przed wstawieniem lub aktualizacją danych w bazie, w kodzie aplikacji musi więc zostać przeprowadzone sprawdzanie poprawności danych; nawet wtedy jednak dokonuje się jeszcze rygorystycznej kontroli błędów, tak aby nie naruszyć formatu pól w bazie danych. Poniżej przykładowa tablica bazy danych, wraz z fizycznymi ograniczeniami poszczególnych pól (tabela 14.1).

Tabela 14.1. Tablica bazy danych z określonymi ograniczeniami fizycznymi

Kolumna	Typ	Rozmiar	Może przyjmować wartość NULL
nazwaUzytkownika	VARCHAR	12	nie
imie	VARCHAR	20	nie
nazwisko	VARCHAR	30	nie
wynagrodzenie	NUMBER	8,2	tak

Zapis w języku SQL dla powyższej tablicy wyglądałby następująco:

CREATE TABLE uzytkownicy

{

nazwaUzytkownika VARCHAR(12) NOT NULL,

imie VARCHAR(20) NOT NULL,

nazwisko VARCHAR(30) NOT NULL,

wynagrodzenie NUMBER(8,2)

}

Teraz załóżmy, że chcemy wstawić lub zaktualizować dane w takiej tablicy z poziomu aplikacji EJB lub JDBC. Kod takiej aplikacji musi być precyzyjnie „zgrany” z tablicą i konieczne jest zagwarantowanie, że długość pól nie przekroczy możliwości określonych w tablicy oraz że kolumna wynagrodzenie zawiera poprawną wartość typu „waluta”. Zmiany w bazie danych wymagałyby wprowadzenia zmian w kodzie aplikacji; taki mechanizm nie jest ani łatwy w zarządzaniu, ani wydajny.

To kolejna sytuacja, w której kod w Javie można uzupełnić schematami XML, tworząc bardziej kompletny obraz odwzorowań danych. A oto schemat definiujący dozwolone dla takiej tablicy wartości. W tym przykładzie jeden element odpowiada jednej tablicy, zaś jeden atrybut — jednemu rekordowi:

</simpleType>

</attribute>

</simpleType>

</attribute>

</simpleType>

</attribute>

</simpleType>

</attribute>

</complexType>

</element>

</schema>

Kiedy mamy już taki schemat, kod aplikacji można „odchudzić”, a sprzężenie z bazą danych nie jest już tak silne. Zmiany w bazie wymagają tylko zmian w schemacie, a nie zmian i ponownej kompilacji kodu. Jeśli dodamy do tego wbudowane lub pochodzące od niezależnych firm narzędzia generujące taki schemat z istniejących tablic, to kompletne odwzorowanie danych można uzyskać nawet nie ruszając kodu w Javie!

To tylko niektóre z sytuacji, w jakich można wykorzystać połączenie technologii XML Schema i Javy. Tylko przyszłość może --> pokazać[Author:RG] , jak bardzo użyteczne będzie to rozwiązanie; w przyszłości XML Schema niemal na pewno zajmie równie ważne miejsce w warsztacie programisty Javy, co sam XML. Warto już teraz zacząć korzystać ze schematów przy sprawdzaniu poprawności
i zawężaniu danych, w przyszłości na pewno nie pójdzie to na marne; ponadto każdy programista może przyczynić się do rozwoju tej specyfikacji.

Co dalej?

Dodatki. I indeks. I jeszcze trochę informacji o autorze. A dalej pewnie jeszcze oferta innych, świetnych książek wydawnictwa O'Reilly.

Mówiąc poważnie, niniejsza książka stanowi potężną porcję wiedzy. Poznaną tutaj teorię należy przekładać na praktykę zawodową. Wkrótce Czytelnik stanie się jednym z ekspertów w dziedzinie języka XML i będzie wiedział, jak zwiększyć elastyczność, prostotę konfiguracji i wydajność posiadanych aplikacji. A potem zobaczy, że także inni (szef, a może nowi szefowie...) doceniają ten nowy zasób wiedzy. Życzę powodzenia!

360 Rozdział 14. XML Schema

Podobieństwo do Javy 359

H:\Książki\!Kudlaty\Java i XML\92 po poprawkach korektora\14-08.doc — strona 360

H:\Książki\!Kudlaty\Java i XML\92 po poprawkach korektora\14-08.doc — strona 359

H:\Książki\!Kudlaty\Java i XML\92 po poprawkach korektora\14-08.doc — strona 351

Zmiana w spisie treści - "korzystać" na "stosować"

Zagęściłam - może być?