---
marp: true
theme: default
paginate: true
size: 16:9
style: |
  section {
    font-size: 24px;
  }
  section h1 {
    color: #1a5276;
  }
  section h2 {
    color: #2980b9;
  }
  section table {
    font-size: 20px;
  }
  section small {
    font-size: 18px;
  }
---
# Wykład 4
## DTD — definiowanie typów dokumentów

**Systemy Zarządzania Treścią**  
Politechnika Poznańska

---

# Część 1
## Wprowadzenie do DTD

---

## Czym jest DTD?

> **DTD (Document Type Definition)** to klasyczny mechanizm definiowania struktury dokumentu XML, wywodzący się bezpośrednio z języka **SGML**.

### Rola DTD

DTD określa **gramatykę dokumentu**:
- jakie elementy mogą wystąpić,
- w jakiej kolejności i liczbie,
- jakie atrybuty są dozwolone,
- jakie są typy wartości atrybutów.

### Umiejscowienie DTD

| Umiejscowienie | Opis |
|---|---|
| **Wewnętrzne (internal subset)** | DTD zapisane bezpośrednio w dokumencie XML |
| **Zewnętrzne (external subset)** | DTD w osobnym pliku, dołączane przez odwołanie |

---

## DTD wewnętrzne i zewnętrzne

### DTD wewnętrzne (w dokumencie)

```xml
<?xml version="1.0"?>
<!DOCTYPE notatka [
  <!ELEMENT notatka (tytul, tresc)>
  <!ELEMENT tytul (#PCDATA)>
  <!ELEMENT tresc (#PCDATA)>
]>
<notatka>
  <tytul>Ważne</tytul>
  <tresc>Treść notatki</tresc>
</notatka>
```

### DTD zewnętrzne (osobny plik)

**Plik `notatka.dtd`:**
```
<!ELEMENT notatka (tytul, tresc)>
<!ELEMENT tytul (#PCDATA)>
<!ELEMENT tresc (#PCDATA)>
```

**Dokument XML:**
```xml
<?xml version="1.0"?>
<!DOCTYPE notatka SYSTEM "notatka.dtd">
<notatka>
  <tytul>Ważne</tytul>
  <tresc>Treść notatki</tresc>
</notatka>
```

> Zewnętrzne DTD jest **wielokrotnie używane** przez wiele dokumentów — to standardowy sposób organizacji.

---

## DTD — prosty przykład

```xml
<!DOCTYPE wiersz [
  <!ELEMENT wiersz  (autor, tytul?, zwrotka*)>
  <!ATTLIST wiersz bialy (tak|nie) "nie">
  <!ELEMENT autor   (#PCDATA)>
  <!ELEMENT tytul   (#PCDATA)>
  <!ELEMENT zwrotka (wers)*>
  <!ELEMENT wers    (#PCDATA)>
]>
```

### Cztery konstrukcje DTD

| Konstrukcja | Przeznaczenie |
|---|---|
| `<!ELEMENT>` | Definicja elementu i jego zawartości |
| `<!ATTLIST>` | Definicja atrybutów elementu |
| `<!ENTITY>` | Definicja encji (skrótów, zasobów) |
| `<!NOTATION>` | Opis formatów nieparsowalnych (np. obrazów) |

### Analiza przykładu

- `wiersz` zawiera: `autor` (raz), `tytul` (opcjonalnie), `zwrotka` (dowolnie wiele),
- `wiersz` ma atrybut `bialy` typu wyliczeniowego `(tak|nie)` z domyślną wartością `"nie"`,
- `autor`, `tytul`, `wers` zawierają tylko tekst (`#PCDATA`),
- `zwrotka` zawiera dowolną liczbę elementów `wers`.

---

# Część 2
## Deklaracja elementu — `<!ELEMENT>`

---

## Notacja modelu zawartości

Model zawartości elementu opisuje się przy użyciu **wyrażeń regularnych**, które określają, jakie elementy potomne — w jakiej kolejności i liczbie — mogą wystąpić.

![width:85%](../img/dtd-notacja-modelu.svg)

### Operatory liczebności (krotności)

| Operator | Znaczenie | Przykład | Interpretacja |
|---|---|---|---|
| *(brak)* | dokładnie raz | `(autor)` | element `autor` wystąpi dokładnie 1 raz |
| `?` | zero lub raz | `(tytul?)` | element `tytul` może nie wystąpić lub wystąpić 1 raz |
| `*` | zero lub więcej | `(zwrotka*)` | element `zwrotka` dowolną liczbę razy (także 0) |
| `+` | jeden lub więcej | `(wers+)` | element `wers` co najmniej 1 raz |

### Operatory łączenia

| Operator | Znaczenie | Przykład |
|---|---|---|
| `,` | sekwencja (w podanej kolejności) | `(autor, tytul)` — najpierw autor, potem tytuł |
| `\|` | alternatywa (wybór jednego) | `(pies\|kot)` — albo pies, albo kot |
| `( )` | grupowanie | `(a, (b\|c))` — a, a następnie b lub c |

> Zapis `(autor, tytul?, zwrotka*)` oznacza: **autor** (raz), potem **tytul** (opcjonalnie), potem **zwrotka** (dowolnie wiele).

---

## Deklaracja elementu — składnia ogólna

```
<!ELEMENT nazwa-elementu model-zawartości>
```

### Rodzaje modelu zawartości

| Rodzaj | Składnia | Znaczenie | Przykład |
|---|---|---|---|
| **Pusty** | `EMPTY` | element nie może mieć treści | `<!ELEMENT br EMPTY>` |
| **Dowolny** | `ANY` | dowolna treść (rzadko stosowane) | `<!ELEMENT notka ANY>` |
| **Tekstowy** | `(#PCDATA)` | tylko tekst parsowalny | `<!ELEMENT autor (#PCDATA)>` |
| **Elementowy** | `(potomkowie)` | tylko elementy potomne | `<!ELEMENT wiersz (autor, tytul?, zwrotka*)>` |
| **Mieszany** | `(#PCDATA\|a\|b)*` | tekst przeplatany elementami | `<!ELEMENT tresc (#PCDATA\|data\|godzina)*>` |

### Słowo kluczowe `#PCDATA`

**PCDATA** (*Parsed Character Data*) oznacza tekst, który parser **przetwarza** (w przeciwieństwie do CDATA, która nie jest przetwarzana). Tekst w elemencie `(#PCDATA)` może zawierać encje i odwołania.

---

## Przykłady deklaracji ELEMENT

### Kompletna gramatyka książki

```
<!ELEMENT ksiazka (tytul, autor+, wydawca?, cena?)>
<!ELEMENT tytul (#PCDATA)>
<!ELEMENT autor (#PCDATA)>
<!ELEMENT wydawca (#PCDATA)>
<!ELEMENT cena (#PCDATA)>
<!ELEMENT lista-pusta EMPTY>
```

### Interpretacja

| Deklaracja | Znaczenie |
|---|---|
| `ksiazka (tytul, autor+, wydawca?, cena?)` | tytuł (raz), autorzy (≥1), wydawca (opcj.), cena (opcj.) — w tej kolejności |
| `tytul (#PCDATA)` | tylko tekst |
| `autor (#PCDATA)` | tylko tekst |
| `lista-pusta EMPTY` | brak jakiejkolwiek treści |

### Zagnieżdżone modele

```
<!ELEMENT raport (naglowek, sekcja+, stopka?)>
<!ELEMENT sekcja (tytul, akapit*)>
<!ELEMENT akapit (#PCDATA)>
```

> Modele zawartości można dowolnie **zagnieżdżać**, tworząc hierarchie o dowolnej głębokości.

---

# Część 3
## Deklaracja atrybutów — `<!ATTLIST>`

---

## Deklaracja atrybutów — składnia

Deklaracja `<!ATTLIST>` definiuje atrybuty danego elementu: nazwy, typy wartości i wartości domyślne.

```
<!ATTLIST nazwa-elementu
  nazwa-atrybutu typ-wartości deklaracja-domyślności>
```

### Struktura pojedynczej deklaracji

| Składnik | Opis |
|---|---|
| `nazwa-elementu` | Element, do którego atrybut należy |
| `nazwa-atrybutu` | Nazwa atrybutu |
| `typ-wartości` | Typ dopuszczalnych wartości (CDATA, ID, IDREF, ...) |
| `deklaracja-domyślności` | Czy atrybut wymagany, opcjonalny, domyślny czy ustalony |

---

## Typy wartości atrybutów

| Typ | Opis | Przykład |
|---|---|---|
| **CDATA** | dowolny tekst (najczęstszy) | `autor CDATA` |
| **ID** | unikatowy identyfikator — nie może się powtarzać w dokumencie | `id ID #REQUIRED` |
| **IDREF** | odwołanie do istniejącego ID innego elementu | `ref IDREF #IMPLIED` |
| **IDREFS** | lista odwołań do ID (rozdzielone spacjami) | `refs IDREFS #IMPLIED` |
| **NMTOKEN** | pojedynczy token (bez spacji) | `kod NMTOKEN` |
| **NMTOKENS** | lista tokenów rozdzielonych spacjami | `slowa NMTOKENS` |
| **ENTITY** | nazwa zadeklarowanej encji | `grafika ENTITY` |
| **ENTITIES** | lista nazw encji | `grafiki ENTITIES` |
| **NOTATION** | nazwa zadeklarowanej notacji | `format NOTATION` |
| **wyliczenie** | jedna z podanych wartości (w nawiasach, rozdzielone `\|`) | `bialy (tak\|nie) "nie"` |

---

## Typy ID i IDREF — mechanizm odwołań

Typy `ID`, `IDREF` i `IDREFS` tworzą **mechanizm wewnętrznych odwołań** w dokumencie:

```xml
<!DOCTYPE katalog [
  <!ELEMENT katalog (osoba*)>
  <!ELEMENT osoba (#PCDATA)>
  <!ATTLIST osoba id ID #REQUIRED
                   przełożony IDREF #IMPLIED>
]>
<katalog>
  <osoba id="p1">Jan Kowalski</osoba>
  <osoba id="p2" przełożony="p1">Anna Nowak</osoba>
  <osoba id="p3" przełożony="p1">Piotr Wiśniewski</osoba>
</katalog>
```

### Zasady

- **ID** — wartość unikatowa w całym dokumencie (jak klucz),
- **IDREF** — wskazuje na istniejący ID (jak klucz obcy),
- **IDREFS** — lista odwołań rozdzielonych spacjami.

> Mechanizm ID/IDREF to prosty odpowiednik **relacji klucz obcy → klucz główny** znany z baz danych.

---

## Deklaracje domyślności atrybutów

| Deklaracja | Znaczenie | Przykład |
|---|---|---|
| `#REQUIRED` | atrybut **wymagany** — musi wystąpić | `id ID #REQUIRED` |
| `#IMPLIED` | atrybut **opcjonalny** — może nie wystąpić | `notatka CDATA #IMPLIED` |
| `#FIXED "wartość"` | atrybut ma **ustaloną**, niezmienną wartość | `wersja CDATA #FIXED "1.0"` |
| `"wartość"` | **domyślna** wartość, gdy atrybut pominięty | `plec (K\|M) "K"` |

### Różnica `#FIXED` vs domyślna

- **Domyślna** (`"wartość"`): jeśli atrybut pominięty, parser **dodaje** go z tą wartością; jeśli podany — może mieć inną wartość,
- **#FIXED**: atrybut musi mieć **dokładnie tę wartość** (jeśli wystąpi z inną — błąd).

---

## Przykład pełnej deklaracji ATTLIST

```xml
<!ATTLIST osoba
  id         ID      #REQUIRED
  pesel      CDATA   #REQUIRED
  plec       (K|M)   "K"
  notatka    CDATA   #IMPLIED
  wersja     CDATA   #FIXED "1.0"
  przełożony IDREF   #IMPLIED
>
```

### Wyjaśnienie

| Atrybut | Typ | Domyślność | Znaczenie |
|---|---|---|---|
| `id` | ID | #REQUIRED | unikatowy identyfikator, obowiązkowy |
| `pesel` | CDATA | #REQUIRED | tekst, obowiązkowy |
| `plec` | wyliczenie | `"K"` | tylko K lub M, domyślnie K |
| `notatka` | CDATA | #IMPLIED | tekst, opcjonalny |
| `wersja` | CDATA | #FIXED "1.0" | zawsze "1.0" |
| `przełożony` | IDREF | #IMPLIED | odwołanie do ID innego elementu |

---

# Część 4
## Encje i notacje

---

## Deklaracja encji — `<!ENTITY>`

Encje pozwalają definiować **skróty, symbole i zasoby zewnętrzne**. Dzielą się na wewnętrzne i zewnętrzne.

### Encje wewnętrzne (definiowane w DTD)

```xml
<!ENTITY firma "Politechnika Poznańska">
<!ENTITY copyright "&#169; 2025 Politechnika Poznańska">
```

Użycie w dokumencie: `&firma;` zostanie zastąpione tekstem `Politechnika Poznańska`.

### Encje zewnętrzne (odwołanie do pliku)

```xml
<!ENTITY rozdzial1 SYSTEM "rozdzial1.xml">
<!ENTITY logo SYSTEM "logo.gif" NDATA gif>
```

Użycie `&rozdzial1;` wstawi zawartość pliku `rozdzial1.xml`.

> Encje działają jak **makrodefinicje** — definiujesz raz, używasz wielokrotnie.

---

## Encje parametryczne

Encje parametryczne (z `%`) używane są **wyłącznie wewnątrz DTD** do wielokrotnego wykorzystania fragmentów deklaracji:

```xml
<!ENTITY % wspolne-atrybuty "
  id   ID    #REQUIRED
  data CDATA #IMPLIED">

<!ATTLIST dokument %wspolne-atrybuty;>
<!ATTLIST artykul  %wspolne-atrybuty;>
```

### Zastosowanie

- Deklaracja `wspolne-atrybuty` definiowana **raz**,
- Używana w wielu deklaracjach `ATTLIST` przez `%wspolne-atrybuty;`.

> Encje parametryczne to mechanizm **wielokrotnego użycia** fragmentów DTD — analog grupy atrybutów z XML Schema.

---

## Deklaracja notacji — `<!NOTATION>`

Notacja opisuje format danych **nieparsowalnych** (obrazy, dźwięk, wideo) i wiąże go z aplikacją zewnętrzną.

### Deklaracja notacji

```xml
<!NOTATION gif SYSTEM "image/gif">
<!NOTATION jpg SYSTEM "image/jpeg">
<!NOTATION png SYSTEM "image/png">
```

### Użycie notacji w atrybucie

```xml
<!ELEMENT grafika EMPTY>
<!ATTLIST grafika format NOTATION (gif|jpg|png) #REQUIRED>
```

### Powiązanie encji z notacją

```xml
<!ENTITY logo SYSTEM "logo.gif" NDATA gif>
```

> Notacje opisują **zewnętrzne formaty binarne**, których parser XML nie potrafi (i nie musi) interpretować.

---

# Część 5
## Ograniczenia DTD

---

## Dlaczego DTD nie wystarcza?

Zastosowania XML w integracji aplikacji wymagają **precyzyjnej kontroli struktur danych**. Przeniesienie sprawdzania poprawności z aplikacji na narzędzie walidujące daje spore oszczędności — szacuje się, że **~60% tworzonego kodu dotyczy weryfikacji poprawności danych** (Roger L. Costello, *XML Schema Tutorial*).

### Ograniczenia DTD

| Ograniczenie | Opis |
|---|---|
| **Brak kontroli tekstu** | Niemal brak kontroli nad tekstową zawartością elementów i wartościami atrybutów |
| **Ogólne metody częstości** | Bardzo ogólne metody definiowania liczby wystąpień |
| **Mało obiektowe** | Nierozszerzalne modele struktury |
| **Składnia nie-XML** | DTD ma własną, specyficzną składnię |
| **Brak typów danych** | Nie można określić, że wartość jest liczbą, datą czy pasuje do wzorca |
| **Brak przestrzeni nazw** | DTD nie wspiera namespace'ów |

> DTD nie pozwala np. powiedzieć: "wartość atrybutu musi być liczbą całkowitą z zakresu 1–49" ani "element musi pasować do wzorca `\d{3}-\d{3}-\d{2}-\d{2}`".

---

## DTD vs XML Schema

| Cecha | DTD | XML Schema |
|---|---|---|
| **Pochodzenie** | Wywodzi się z SGML-a | Zaprojektowany na potrzeby XML-a |
| **Składnia** | Specyficzna (nie-XML) | Składnia XML |
| **Typy danych** | 10 typów | 44 wbudowane typy proste + własne |
| **Model zawartości** | Typowy mieszany | Możliwość definiowania własnych typów |
| **Kontrola tekstu** | Brak kontroli tekstowej | Zaawansowana kontrola (pattern, ranges) |
| **Przestrzenie nazw** | Brak wsparcia | Pełne wsparcie |
| **Rozszerzalność** | Nierozszerzalne | Dziedziczenie, rozszerzanie typów |

> XML Schema zachowuje pełną składnię XML, co pozwala przetwarzać schematy tymi samymi narzędziami co dokumenty — to jej fundamentalna przewaga. XML Schema jest szczegółowo omówiona w **wykładach 5–7**.

---

## Podsumowanie

| Temat | Kluczowe wnioski |
|---|---|
| **DTD** | Klasyczny mechanizm definiowania struktury dokumentu |
| **Umiejscowienie** | Wewnętrzne (w dokumencie) lub zewnętrzne (osobny plik) |
| **`<!ELEMENT>`** | Definiuje element i model zawartości (EMPTY, ANY, #PCDATA, potomkowie) |
| **Notacja modelu** | `,` sekwencja, `\|` alternatywa, `?` `*` `+` krotności |
| **`<!ATTLIST>`** | Atrybuty: typy (CDATA, ID, IDREF, ...) i domyślność |
| **ID/IDREF** | Mechanizm odwołań wewnętrznych (klucz → klucz obcy) |
| **`<!ENTITY>`** | Encje wewnętrzne, zewnętrzne i parametryczne |
| **`<!NOTATION>`** | Opis formatów nieparsowalnych |
| **Ograniczenia** | Brak typów danych, namespace'ów i rozszerzalności |

---

# Dziękuję za uwagę

**Systemy Zarządzania Treścią**  
Politechnika Poznańska