r02-01.doc

(361 KB) Pobierz
Helion









Rozdział 1 ¨ Pierwsze kroki (Nagłówek strony)

Rozdział 2.
Tworzenie poprawnie sformułowanych dokumentów XML

W poprzednim rozdziale naszą znajomość z XML zaczęliśmy od dowiedzenia się, na czym polega strukturyzacja dokumentów w XML, czym ten język w ogóle jest i jak się go używa. Teraz czas przyjrzeć się XML dokładniej – na tyle dokładnie, aby stać się specjalistą.

W HTML mamy około 100 predefiniowanych elementów. Przeglądarka może odczytać HTML z witryny i wyświetlić go zgodnie ze swoją interpretacją. W XML autor ma więcej swobody, wobec czego większa jest też jego odpowiedzialność. Definiuje się samemu elementy i autor musi zdecydować, jak mają być używane. Jednak dokumenty – mimo że tak ogólne – podlegają szeregowi ścisłych ograniczeń, które sprawiają, że dokumenty te są proste w użyciu dzięki ich jednolitej postaci.

Tak naprawdę wymagania względem dokumentów XML są znacznie większe niż względem dokumentów HTML. Jak wspomniano w rozdziale 1, jeśli procesor nie jest w stanie w pełni zrozumieć dokumentu XML, nie ma on niczego się domyślać o dokumencie – ma po prostu zakończyć swoje działanie i ewentualnie zwrócić kod błędu.

Wspomniano też, że dokumenty XML podlegają dwóm rodzajom ograniczeń: poprawności sformułowania oraz walidacji. Zgodnie z wykładnią W3C poprawność jest wymaganiem bardziej elementarnym. W specyfikacji XML określono, że dokumentu nie można nawet nazwać dokumentem XML, jeśli nie jest on poprawnie sformułowany.

Obiekt z danymi jest dokumentem XML, jeśli jest poprawnie sformułowany, jak to zdefiniowano w niniejszej specyfikacji. Jeśli dokument spełnia pewne dodatkowe warunki, może być walidowany.

Czemu poprawność sformułowania jest tak ważna? Czemu W3C zabrania procesorom XML próbować naprawiać źle sformułowane dokumenty?

Chodzi o to, aby procesory XML uniknęły pułapki, w którą wpadły przeglądarki HTML: usiłują możliwie dużo poprawiać, ale kosztem tego jest faktycznie istnienie różnych wersji HTML, z których każda jest obsługiwana w innym narzędziu.

W tym rozdziale zastanowimy się, co stanowi o poprawności sformułowania dokumentu XML, czyli minimum wymagań. Drugim wymaganiem względem dokumentu XML może być walidacja, czyli zgodność dokumentu z definicją typu dokumentu (DTD) lub schematem, czyli zachowanie wymaganej składni. W tym rozdziale skupimy się na opisaniu poprawności sformułowania.

Teraz mówimy o tworzeniu dokumentów formalnie, więc zaczniemy od samego początku, aby dać dobre podstawy – tak więc zaczniemy od W3C.

World Wide Web Consortium

Wiemy już, że to W3C jest odpowiedzialne za dokładne określenie, czym jest XML, ale czym właściwie jest W3C? Nie jest to agenda rządowa, jest to grupa organizacji członkowskich (obecnie jest ich ponad 400) zainteresowanych WWW. W3C ma siedziby w Laboratorium nauk komputerowych na Politechnice Massachusetts (MIT/LCS) w Stanach Zjednoczonych, w Narodowym Instytucie Informatyki i Automatyki (INRIA) w Europie oraz na Uniwersytecie Keio Sonan Fujisawa Campus w Japonii. Obecnie W3C zatrudnia ponad 50 pełnoetatowych pracowników.

Jak W3C określa specyfikacje dla Sieci? Otóż są one publikowane w postaci HTML (a ostatnio XHTML) w Sieci, w witrynie www.w3.org. Specyfikacje te mogą mieć trzech różnych rodzajów:

·         Powiadomienia. Są to specyfikacje przysłane do W3C przez organizację członkowską, które organizacja zdecydowała się opublikować, choć niekoniecznie W3C musi je popierać. Na przykład powiadomienie o specyfikacji Microsoftu Wektorowego języka znaczników (VML) dostępne jest pod adresem www.w3.org/TR/NOTE-VML.

·         Szkice robocze. Szkic roboczy to specyfikacja, która cały czas jest opracowywana i można do niej zgłaszać swoje uwagi. Takich specyfikacji nie należy traktować jako standardów czy czegokolwiek innego – są to szkice robocze. Przykładem szkicu roboczego jest specyfikacja XHTML 1.1 dostępna pod adresem www.w3.org/TR/xhtml11/.

·         Rekomendacje. Szkice robocze, które zostały w W3C zaakceptowane, stają się rekomendacjami. W3C używa właśnie terminu rekomendacja, a nie standard, gdyż W3C nie jest organizacją rządową i nie ma uprawnień do publikowania standardów. Przykładem rekomendacji jest XML 1.0 dostępna pod adresem www.w3.org/TR/REC-xml.

Niezależnie od owych oficjalnych typów specyfikacji istnieje jeszcze w W3C pojęcie rekomendacji proponowanej, która jest szkicem roboczym, który został zaproponowany już jako rekomendacja, ale nie został jeszcze zaakceptowany. Istnieją też rekomendacje towarzyszące, które uzupełniają normalne rekomendacje. Istnieje mnóstwo rekomendacji towarzyszących związanych z XML (schematy XML, XLinks, XPointers i tak dalej), ich listę znajdziesz pod adresem www.w3c.org/xml.

Rekomendacja definiująca XML 1.0 znajduje się pod adresem www.w3.org/TR/REC-xml. Dla naszej książki ta rekomendacja jest najważniejsza. Wraz ze związanymi z nią standardami (Unicode i ISO/IEC 10646 z opisem znaków, Internet RFC 1766 ze znacznikami identyfikującymi języki, ISO 639 z kodami nazw języków oraz ISO 3166 z kodami nazw krajów) rekomendacja ta zapewnia wszystko, co jest potrzebne do zrozumienia XML w wersji 1.0 i tworzenia dokumentów XML. Teraz czas tę rekomendację wykorzystać tworząc poprawnie sformułowane dokumenty.

Czym jest poprawnie sformułowany dokument XML?

W3C, twórca terminu poprawność sformułowania, definiuje to pojęcie w rekomendacji XML 1.0:

Obiekt tekstowy jest poprawnie sformułowanym dokumentem, jeśli:

Proszę o kontrolę poniższego punktu.

·         Jako całość spełnia definicję dokumentu etykietowego.

·         Zgodny jest z regułami poprawności sformułowania podanymi w specyfikacji (www.w3.org/TR/REC-xml).

·         Każda parsowana encja (część), do której w dokumencie jest odwołanie bezpośrednie lub pośrednie, jest poprawnie sformułowana.

W3C nazywa poszczególne specyfikacje szkicu roboczego lub rekomendacji definicjami. W tym wypadku, aby być poprawnie sformułowanym, dokument musi być zgodny z definicją dokumentu, co oznacza, że sam dokument musi mieć trzy części: prolog (może być pusty), element główny i opcjonalną część końcową.

Prolog, który wkrótce będzie omawiany, może i powinien zawierać deklarację XML (<?xml version="1.0"?>)[1] oraz opcjonalną część końcową zawierającą komentarze, instrukcje przetwarzania i tak dalej. Element główny dokumentu zawierać może inne elementy – trudno zresztą wyobrazić sobie użyteczny dokument XML, w którym element główny nie zawiera już żadnych innych elementów. Poprawnie sformułowany dokument zawiera zawsze dokładnie jeden element główny, wszystkie inne elementy muszą być w elemencie głównym zawarte (nie dotyczy to oczywiście prologu, gdyż instrukcje przetwarzania czy komentarze nie są elementami).

Część końcowa zawierać może komentarze, instrukcje przetwarzania i białe znaki (spacje, tabulatory i tak dalej). Dalej zajmiemy się dokładniej prologiem, elementem głównym i częścią końcową.

Następnie żąda się, aby dokument XML był poprawnie sformułowany zgodnie z regułami podanymi w specyfikacji XML 1.0 Oznacza to, że dokument XML musi spełniać wymagania składniowe określone w rekomendacji XML 1.0. Reguły te omówimy też w tym rozdziale.

Wymagania poprawności sformułowania

Jeśli przejrzysz specyfikację XML 1.0, zauważysz, że odpowiednie wymagania oznaczone są słowami „Well-Formedness Constraint”.

W końcu wymaga się, aby każda parsowana encja (część) była sama poprawnie sformułowana. Co to znaczy?

Części dokumentu XML nazywa się encjami. Encja to część dokumentu, która zawierać może tekst lub dane binarne (ale nie jedno i drugie). Encja odwoływać się może do innych encji i w ten sposób włączać je do dokumentu. Encje mogą być parsowane (dane tekstowe) lub nieparsowane (albo dane tekstowe zawierające coś innego niż kod XML, albo dane binarne, których procesor XML nie będzie analizował). Krótko mówiąc encja to ogólne określenie jednostki składowej w XML. Na przykład plik z kilkoma elementami XML jest encją ale jeśli nie jest poprawnie sformułowany, nie jest dokumentem.

Reguła dotycząca encji parsowanych mówi, że jeśli odwołujesz się do encji i włączasz do dokumentu dane tej encji (które zawierać mogą dane ze źródeł zewnętrznych), te włączane dane muszą być poprawnie sformułowane.

Taka jest definicja poprawnie sformułowanego dokumentu, ale jeszcze daleko nam do pełnej jasności co do jej znaczenia. Jakie są owe wymagania poprawności, których trzeba się trzymać? Co dokładnie może wystąpić w prologu? Aby odpowiedzieć na te i podobne pytania, w dalszej części tego rozdziału omówimy wszystko dokładniej.

Zaczniemy od przyjrzenia się dokumentowi XML, który będziemy omawiali w tym rozdziale zastanawiając się, jakie warunki trzeba spełnić, aby był on poprawnie sformułowany. Będziemy zapisywać w dokumencie order.xml dane o pewnych zakupach. Zaczynamy oczywiście od deklaracji XML:

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

Użyliśmy deklaracji <?xml?>, aby wskazać, że tworzymy dokument XML, wskazaliśmy też wersję – jedyną obecnie istniejącą, czyli 1.0. Dokumenty umieszczane w tym rozdziale będą samodzielne (czyli nie będą odwoływały się ani nie będą zawierały żadnych encji zewnętrznych), więc można ustawić wartość atrybutu standalone (samodzielny) na yes (tak):

<?xml version="1.0" encoding="iso-8859-2" standalone="yes"?>

Atrybut ten, który może być przez parser użyty lub nie, wskazuje, czy dokument jest całkowicie samodzielny. Formalnie rzecz biorąc dokumenty XML nie muszą zaczynać się od deklaracji XML, ale W3C zaleca jej stosowanie.

Następnie dodajemy element główny, będzie to DOKUMENT – nazwa jednak mogłaby być dowolna:

<?xml version="1.0" encoding="iso-8859-2" standalone="yes"?>

<DOKUMENT>

  .

  .

  .

</DOKUMENT>

Element główny może oczywiście zawierać inne elementy. Dodamy na razie trzy elementy opisujące klientów:

<?xml version="1.0" encoding="iso-8859-2" standalone="yes"?>

<DOKUMENT>

  <KLIENT>

    .

    .

    .

  </KLIENT>

  <KLIENT>

    .

    .

    .

  </KLIENT>

  <KLIENT>

    .

    .

    .

  </KLIENT>

</DOKUMENT>

Będziemy zapisywać nazwiska klientów – w elemencie IMIĘNAZWISKO umieścimy elementy NAZWISKO i IMIĘ:

<?xml version="1.0" encoding="iso-8859-2" standalone="yes"?>

<DOKUMENT>

  <KLIENT>

    <IMIĘNAZWISKO>

      <NAZWISKO>Smith</NAZWISKO>

      <IMIĘ>Sam</IMIĘ>

    </IMIĘNAZWISKO>

    .

    .

    .

  </KLIENT>

  <KLIENT>

    .

    .

    .

  </KLIENT>

  <KLIENT>

    .

    ....

Zgłoś jeśli naruszono regulamin