Standardy

Zalecane sposoby definiowania struktury dokumentu:

• DTD (Document Type Definition) – część standardu XML,
• XML Schema – rekomendacja W3C.

Alternatywne standardy (jako ciekawostka):

• Relax NG – standard podobny do XML Schema, mniej rozbudowana i bardziej czytelna składnia ułatwia ręczną edycję,
• Schematron – odmienna ideologia, typ dokumentu określa się tu nie w oparciu o gramatykę, ale poprzez listę predykatów, które dokumenty muszą spełniać.

Obecnie najbardziej zalecanym standardem do definiowania nowych typów dokumentów jest XML Schema. Istnieje jednak wiele typów dokumentów już zdefiniowanych za pomocą DTD, a czasem, ze względu na specyfikę zastosowania i używane narzędzia, DTD opracowuje się (lub generuje się ze schematów) również dla nowych standardów (np. XHTML).

Dwa stopnie poprawności dokumentu, walidacja

Każdy dokument XML musi być poprawny składniowo (well-formed) – być zgodny z gramatyką XML i spełniać well-formedness constraints wymienione w rekomendacji XML.

Dodatkowo dokument XML może być poprawny strukturalnie (valid) – być zgodny z definicją struktury. Jeśli nie jest powiedziane inaczej, chodzi o DTD, a dokument ma spełniać validity constraints wymienione w rekomendacji XML. Tego samego terminu używa się także do określenia zgodności ze schematem XML Schema bądź innych standardów.

Proces sprawdzania poprawności strukturalnej nazywa się walidacją. Po wykonaniu walidacji mamy pewność, że dokument posiada właściwą strukturę. Dzięki temu, np. we własnych programach czy w arkuszach XSLT, nie musimy już rozważać przypadków błędnych i od razu wiemy, że np. wymagane elementy rzeczywiście występują.

Definicja struktury i proces walidacji mogą mieć wpływ na zawartość dokumentu w warstwie logicznej. Dzieje się tak ponieważ:

• zarówno DTD jak i schemat XML Schema może określać domyślne wartości atrybutów,
• na podstawie definicji struktury oraz specjalnego atrybutu xml:space parser może zignorować niektóre białe znaki między elementami,
• (tylko) DTD może definiować encje, które rozwijają się do określonej zawartości; encje mogą odwoływać się także do zewnętrznych, potencjalnie zmiennych, zasobów.

Położenie

Deklaracja DTD w dokumencie występuje za deklaracją XML (jeśli istnieje) a przed elementem głównym. Może w całości być zawarta w dokumencie, może być zawarta w encji zewnętrznej, lub częściowo być w encji zewnętrznej, a częściowo w dokumencie - w tym przypadku jako pierwsza przetwarzana jest część wewnętrzna.

<?xml version="1.0"?> <!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Hello, world!</greeting>

<?xml version="1.0"?> <!DOCTYPE greeting PUBLIC "-//W3C//GREETEING 1.0//EN" "hello.dtd">
<greeting>Hello, world!</greeting>

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
  <!ELEMENT greeting (#PCDATA)>
]>
<greeting>Hello, world!</greeting>

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting SYSTEM "hello.dtd" [
  <!ATTLIST greeting words CDATA #IMPLIED>
]>
<greeting words="2">Hello, world!</greeting>

Elementy

Definiowanie struktury dokumentu w DTD opiera się na założeniu, że w całym dokumencie elementy o tej samej nazwie mają podobną strukturę. DTD definiuje typy elementów, elementami jednego typu są elementy o tej samej nazwie.

DTD pozwala zdefiniować takie własności dokumentu jak:

• zestaw dopuszczalnych typów elementów (nazwy elementów nie wymienione w DTD nie mogą występować w dokumencie),
• dla każdego typu elementu pozwala w pewnym stopniu określić jego dopuszczalną zawartość (patrz dalej),
• dla każdego typu elementu określa jego atrybuty, ich wartości domyślne, obowiązkowość występowania, w pewnym stopniu ich dopuszczalne wartości.

Dla każdej nazwy elementu może istnieć tylko jedna jego deklaracja w DTD. Deklaracja elementu ma postać:

<!ELEMENT nazwa-elementu typ-zawartości-elementu >

Typy zawartości elementu:

ANY

zawartość dowolna,

EMPTY

element zawsze jest pusty,

#PCDATA

zawartość tekstowa,

(#PCDATA | nazwa-elementu1 | nazwa-elementu2 ... )*

model mieszany – zawartość tesktowa z zanurzonymi w niej elementami, bez kontroli kolejności ani liczności wystąpień,

wyrażenie regularne

zbudowane za pomocą ( ) , | ? * + z nazw elementów.

Atrybuty

Deklaracja listy atrybutów ma postać:

<!ATTLIST nazwa-elementu
	nazwa-atrybutu1 typ-zawartości-atrybutu1 opis-domyślnego1
	nazwa-atrybutu2 typ-zawartości-atrybutu2 opis-domyślnego2
	...
>

Dla każdego elementu może być wiele list atrybutów, są łączone. Dla każdego atrybutu może być w sumie wiele deklaracji – liczy się pierwsza.

Typy zawartości atrybutu:

CDATA

dowolny tekst,

ID

nazwa unikalna w całym dokumencie, dla danego typu elementu tylko jeden atrybut może być zadeklarowany jako ID,

IDREF

nazwa występująca gdzieś w dokumencie jako wartość typu ID,

IDREFS

jak IDREF, ale może być wiele nazw rozdzielonych białymi znakami

NMTOKEN, NMTOKENS

jeden lub wiele rozdzielonych białymi znakami tokenów, czyli napisów złożonych z liter, cyfr, znaków - _ :.

(token1 | token2 ...)

jeden z podanych tu tokenów,

ENTITY, ENTITIES, NOTATION

inne typy.

opis-domyślnego określa czy atrybut jest wymagany i jaką ma wartość domyślną:

#REQUIRED

atrybut zawsze musi być określony explicite,

#IMPLIED

atrybut nie musi być podany, nie ma wartości domyślnej,

"wartość-domyślna"

atrybut nie musi być podany, jeśli nie jest, to przyjmowana jest wymieniona tu wartość domyślna,

#FIXED "wartość-domyślna"

atrybut nie musi być podawany, zawsze ma określoną tu wartość domyślną, nie może w dokumencie występować z inną wartością.

Encje

Encja ma swoją nazwę i wartość – fragment dokumentu. Aby można było użyć danej encji, trzeba ją zadeklarować w DTD (nie dotyczy to pięciu encji predefiniowanych). Procesor XML powinien traktować dokument tak jakby w miejsce referencji do encji wstawił ich wartości.

Referencja do encji ogólnej w dokumencie ma postać &nazwa_encji; i może wystąpić poza DTD, natomiast deklaracja w DTD:

<!ENTITY nazwa-encji wartość-encji>

Może być wiele deklaracji encji o tej samej nazwie, liczy się pierwsza. Wartość encji może być podana bezpośrednio w deklaracji ujęta w znaki " lub ', wtedy encję nazywamy wewnętrzną.

Można też zadeklarować encję zewnętrzną – jest to uogólnienie pliku, jakiś zasób dostępny dla procesora XML. Do identyfikacji encji zewnętrznej służy identyfikator systemowy lub identyfikator publiczny. Encja po wstawieniu jest przetwarzana jako XML, powinna być fragmentem XML dającym się sparsować (jeśli jest znacznik otwierający, powinien być zamykający itp.), ponadto może zaczynać się od deklaracji analogicznej do deklaracji XML, podającej wersję XML i kodowanie. Istieją też encje nieprzetwarzane (tylko zewnętrzne).

<!ENTITY wewnetrzna
         "bla bla bla <bla>123</bla>">

<!ENTITY zewnetrzna_id_systemowy
         SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">

<!ENTITY zewnetrzna_id_publiczny
         PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
         "http://www.textuality.com/boilerplate/OpenHatch.xml">

<!ENTITY zewnetrzna_nieprzetwarzana
         SYSTEM "../grafix/OpenHatch.gif"
         NDATA gif >

Encja parametryczna to specjalny rodzaj encji, do której referencje pojawiać się mogą wewnątrz DTD. Referencja ma postać: %nazwa_encji;, natomiast deklaracja:

<!ENTITY % nazwa-encji wartość-encji>

Encje parametryczne też mogą być wewnętrzne i zewnętrzne, ale nie ma nieprzetwarzanych. Encje parametryczna i ogólna o tej samej nazwie są różnymi obiektami, mogą istnieć obok siebie. Encji parametrycznych używa się zwykle w celu zdefiniowania w jednym miejscu typu zawartości, który następnie jest używany dla wielu elementów / atrybutów.

Wszystkie encje muszą być zadeklarowane przed jakimkolwiek odwołaniem do nich.

Sekcje warunkowe

<![INCLUDE[ fragment DTD ]]>
<![IGNORE[ fragment DTD ]]>

W połączeniu z encjami parametrycznymi stanowią mechanizm do tworzenia sparametryzowanych DTD.