XML/Elementy

Poprawność dokumentu

Standard XML definiuje dwa rodzaje poprawności - poprawność składniową (well-formedness, dokument poprawny składniowo is well-formed) oraz "ważność" (validity, dokument "ważny" is valid). Definicja poprawności składniowej jest rekurencyjna, odwołuje się do samej siebie:

• Wszystkie elementy są zamknięte w jednym. Taki obiekt w m.in. obiektowym modelu dokumentu, który poznamy później, nazywany jest document, który reprezentuje cały dokument. W reprezentacji drzewa nazywa się korzeniem.
• Przestrzegane są wszystkie reguły poprawności składniowej wymienione w specyfikacji.
• Wszystkie encje występujące w dokumencie są poprawne składniowo.

Zwróć uwagę na to, że dokument "ważny" musi być jednocześnie poprawny składniowo, inaczej parser, czyli analizator kodu, nie będzie w stanie rozpoznać elementu, a te, zgodnie ze standardami, muszą przerwać analizowanie dokumentu po wystąpieniu błędu, w przeciwieństwie do HTML, w którym próbuje się odtworzyć dokument naprawiając drobne błędy składniowe lub ignorując bardziej uszkodzone elementy (w HTML 5 to zachowanie jest nawet standaryzowane). Waga poprawności jest więc bardzo wysoka.

Najbardziej podstawowymi zasadami dotyczącymi poprawności składniowej dokumentu są te dotyczące budowy elementów i, co za tym idzie, ich znaczników. Tak jak w HTML i SGML, jeśli białe znaki nie przedzielają literałów (czyli wartości będących w jednym wyrazie), nie mają żadnego znaczenia w dokumencie.

Przepis na poprawny element

Spróbujmy pójść drogą algorytmiczną - tak postępują parsery oraz tak informacje podaje często specyfikacja standardu (mimo że specyfikacja definiuje dokładnie nawet nazwę, czy pierwszy znak nazwy, ten opis aż tak szczegółowy nie będzie).

Znacznik otwierający

• Musi wystąpić znak '<'
• Musi wystąpić nazwa
• Musi wystąpić biały znak
• Może wystąpić wielokrotnie
  • Atrybut
  • Biały znak
• Może wystąpić biały znak (jeśli nie został wstawiony po atrybucie, to musi)
• Musi wystąpić znak '>'.

Atrybut jest zdefiniowany jako literał nazwy, znak równości i literał wartości objęty w apostrofy lub cudzysłowy. Nie są dozwolone żadne skrócone metody dostępne w SGML i HTML.

Jako pierwszy został podany przykład najbardziej "schludny" zgodny z zasadą Canonical XML, jako drugi, jedna z możliwych wariacji. Uwaga! W przykładzie literał wartości atrybutu jest ujęty w cudzysłowy, ale standard Canonical XML się na ten temat nie wypowiada (więc dozwolone są obie wersje).

<element attr="value">

<element attr   = 
    "value"         >

• Muszą wystąpić znaki '</'
• Musi wystąpić nazwa
• Mogą wystąpić białe znaki
• Musi wystąpić '>'.

</element>

</element
    >

Znacznik pusty

Jest to element niezawierający wartości. Może zawierać atrybuty. Nie należy mylić go ze znacznikami między którymi nie ma wartości, mimo że oba wskazują na puste elementy

<!-- Równoważne definicje pustych elementów -->
<element attr="val"></element> <!-- para znaczników bez wartości -->
<element /> <!-- pusty znacznik -->

Canonical XML zaleca używanie pustych znaczników bez wartości, czyli unikanie definicji przez pusty znacznik.

Instrukcje przetwarzania oraz prolog

Instrukcje przetwarzania to wszelkiego rodzaju informacje dla aplikacji, niebędące częścią danych. Składają się z dwóch części, pierwsza jest literałem identyfikującym cel (aplikację, działanie), druga jest częścią właściwą. Może też wystąpić instrukcja bez części właściwej. Również jest poprawna.

<?instrukcja a to jest część właściwa instrukcji?> <!-- instrukcja przetwarzania z częścią właściwą -->
<?instrukcja?> <!-- instrukcja przetwarzania bez części właściwej -->

Pierwszy wyraz jest identyfikacją celu, wszystkie następne są częścią właściwą (o ile występuje). Składnia części właściwej może być dowolna. Może to być notacja elementów, skrypty - wszystko, co jest potrzebne. Jeśli aplikacja nie zna danej instrukcji przetwarzania (bo np. nie jest do jej wykonywania stworzona), po prostu ją pomija. Często występująca na początku składowa nie jest instrukcją przetwarzania, choć tak wygląda. To prolog dokumentu. Zawiera podstawowe informacje o dokumencie.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

• xml jest informacją, że to prolog.
• version to wersja XML. Obecnie dostępne są dwie - 1.0 i 1.1. Dla większości zastosowań jest zalecana wersja 1.0 (wersja 1.1 zawiera zmiany na niskim poziomie).
• encoding to strona kodowa dokumentu. Zależy od edytora tekstu. Domyślną jest Unicode UTF-8. Parser musi też akceptować UTF-16. Inne mogą być akceptowane, lecz nie muszą.
• standalone to informacja, czy dokument zawiera jakiekolwiek encje zewnętrzne czy odwołania do zewnętrznych źródeł (takich jak np. schematy).

Wartości podane w przykładzie są wartościami domyślnymi. Jeśli którakolwiek jest domyślna, można parę z nią pominąć. Parę encoding=... można pominąć również wtedy, gdy wartością jest utf-16, a kodowanie jest zaznaczone przez edytor tekstowy w BOM. Nie jest błędem określenie "no", kiedy dokument jest samodzielny (natomiast określenie "yes", kiedy dokument nie jest samodzielny, jest błędem). Dzięki temu, jeśli dwie pierwsze pary miałyby wartości domyślne lub kodowaniem jest UTF-16 z BOM, cały prolog można usunąć, a w standardzie Canonical XML jest to zalecane.

Komentarze

Komentarze, jeśli nie znasz ich z HTML, już znasz przez przypadek. Bo są to ciągi znaków, które zostały użyte do opisów w powyższych przykładach.

<!-- comment -->

Parser całkowicie takie ciągi znaków ignoruje. Wobec tego niemożliwe jest umieszczanie tam ważnych informacji (od tego są instrukcje przetwarzania) ani zagnieżdżanie komentarzy (czyli umieszczanie jednego w drugim).

Encje

Encje to specjalne byty, które pozwalają rozbudować dokument o nowe możliwości. Można zadeklarować encje wewnętrzne, które są wywoływane za pomocą znaków zastępczych. Podobnie działają encje zewnętrzne parsowane, które pozwolą zaimportować fragment dokumentu z zewnętrznych plików (zwróć uwagę na to, że to nie musi być statyczny plik, ale np. generowany z bazy danych na żywo przez aplikację np. program na serwerze).. Encje zewnętrzne nieparsowane różnią się od poprzednich tym, że nie są analizowane przez parser. Jest to dobra furtka do wstawiania tekstów przypominających te ze znacznikami (ale bez analizowania, bo to naprawdę nie są znaczniki), czy do wstawiania danych binarnych.

Przedsmak, czyli odwołania znakowe

Te rodzaje encji zna chyba wielu korzystających z internetu, a na pewno piszący w HTML-u czy czytelnicy tego kursu, którzy już wcześniej eksperymentowali z XML. Wobec tego nie ma potrzeby powtarzać tabel z tymi referencjami. Oba szablony po prawej odwołują do stron z siostrzanych projektów, które dobrze opisują te elementy.

<element>
    <k>To jest referencja znakowa, która pozwala uniknąć próby zinterpretowania &apos;&lt;&apos; jako znacznika.</k>
    <!-- To jest referencja znakowa, która pozwala uniknąć próby zinterpretowania '<' jako znacznika -->
</element>

Powyższy przykład ilustruje dobrze, jak można wykorzystać podstawowe odwołania znakowe SGML w XML. Poniższy pokazuje, jak można używać znaków zastępczych za litery alfabetu łacińskiego. Mimo że XML wspiera generycznie Unicode, użycie referencji znakowych zwalnia piszącego dokument z szukania znaków w tablicach znaków do kopiuj-wklej czy uczenia się obsługi różnych klawiatur.

Mogę napisać "narzeczona" po angielsku i francusku bez szukania znaku - dzięki encjom: Fiancée
<!-- Mogę napisać "narzeczona" po angielsku i francusku bez szukania znaku - dzięki encjom: Fiancée -->

Tworzenie własnych encji wymaga znajomości budowy deklaracji typu dokumentu (DTD). Nauczysz się tego w dalszej części kursu.