pcblog.cz

V předešlých článcích jsme si ukázali základní syntaxi XML souboru a také návod, jak snadno ověřit, že dokument je well-formed. Tím jsme pokryli kontrolu syntaxe našeho XML. Nyní si ukážeme nejjednodušší způsob, jak zkontrolovat gramatiku tohoto souboru.

Použijeme nástroj jménem DTD, ve kterém specifikujeme strukturu a typ elementů a jejich atributů, jež se smí v XML vyskytovat.

DTD informace můžeme vměstnat buď přímo do XML dokumentu a nebo lépe do externího souboru, na který odkážeme.

V první řadě zde nabídneme předpřipravené XML, na němž se prvky z DTD budou ukazovat. Chtěl bych jen poznamenat, že ke skutečné interpretaci existujícího vozového parku má tento ukázkový dokument daleko. Je až nerealisticky zohýbán, aby se na něm dalo ukázat co nejvíc typů elementů a atributů.

XML soubor

Ukázka

<?xml version="1.0" encoding="utf-8" ?>
<!-- Vozovy park -->
<!DOCTYPE vozovy_park SYSTEM "vozovy_park.dtd" [
<!ENTITY hqm "Haligali-Quanchula-Managna">
]>

<vozovy_park patrici="pcblogu">

  <!-- ZDE JSOU VYPSANY VSECHNY VOZY -->
  <auto id="c01">
    <znacka>ford</znacka>
    <barva metaliza="ano">bila</barva>
    <kola pocet="4">zimni</kola>
    <airbagy pozice="predni-komplet"/>
    <spz>2T39087</spz>
  </auto>

  <auto id="c02" zavada="z01">
    <znacka>velorex</znacka>
    <barva>hneda</barva>
    <kola pocet="3">zimni</kola>
    <spz>3T34032</spz>
  </auto>

  <auto id="c03">
    <znacka>Haligali-Quanchula-Managna</znacka>
    <barva>cervena</barva>
    <kola>letni</kola>
    <docasna-spz>1T14322</docasna-spz>
  </auto>

  <auto id="c04" zavada="z02">
    <znacka>&hqm;</znacka>
    <barva>cervena</barva>
    <kola>letni</kola>
    <spz>2T44769</spz>
  </auto>

  <!-- ZDE JSOU VYPSANY PORUCHY NA VOZECH -->
  <poruchy>
    <zavada na_voze="c02" id="z01">
      <![CDATA[
        Pichla duse
      ]]>
    </zavada>
    <zavada na_voze="c04" id="z02">
      <![CDATA[
        Problem se soucastkou H<am>sterer
      ]]>
    </zavada>
  </poruchy>

</vozovy_park>

DTD soubor

Ukázka

<!ENTITY hqm "Haligali-Quanchula-Managna">

<!ELEMENT vozovy_park (auto+, poruchy)>
<!ATTLIST vozovy_park
patrici NMTOKEN #FIXED "pcblogu">

<!ELEMENT auto (znacka, barva, kola, airbagy?, (spz|docasna-spz))>
<!ATTLIST auto
id ID #REQUIRED
zavada IDREF #IMPLIED
zavada CDATA "neni">

<!ELEMENT znacka (#PCDATA)>
<!ELEMENT barva (#PCDATA)>
<!ATTLIST barva
metaliza (ano|ne) "ne">
<!ELEMENT kola (#PCDATA)>
<!ATTLIST kola
pocet CDATA #IMPLIED>
<!ELEMENT airbagy EMPTY>
<!ATTLIST airbagy
pozice (ridic|predni-komplet) #REQUIRED>
<!ELEMENT spz (#PCDATA)>
<!ELEMENT docasna-spz (#PCDATA)>

<!ELEMENT poruchy (zavada*)>
<!ELEMENT zavada ANY>
<!ATTLIST zavada
id ID #REQUIRED
na_voze IDREF #REQUIRED>

V první řadě vidíte hlavičku dokumentu, se kterou jsme se již setkali v minulých tutoriálech. Ještě jsme ale nezmiňovali komentář, jenž je použit hned za samotnou deklarací XML dokumentu. Text komentáře musí začínat <!– takto a být uzavřen –> tímto způsobem. Je poměrně dobré a rozhodně doporučené komentovat své dokumenty, neboť s nimi nemusíte pracovat jen Vy. Pokud někdo uvidí Vaši práci poprvé, těžko se v ní bude hned bez problémů orientovat. V tom komentáře jednoznačně napomohou.

DOCTYPE

Další novinkou je element <!DOCTYPE vozovy_park SYSTEM “vozovy_park.dtd“ … a tak dále. Tento element odkazuje na externí DTD soubor a navíc může sám DTD informace obsahovat. Je ale o poznání praktičtější a přehlednější mít příslušné DTD uložené mimo. Jako první parametr uvedeme kořenový element XML dokumentu. Dále následuje SYSTEM a cesta k DTD souboru. V hranaté závorce je uzavřena entita, k jejímu využití se dostaneme za okamžik

<!DOCTYPE vozovy_park SYSTEM "vozovy_park.dtd" [
<!ENTITY hqm "Haligali-Quanchula-Managna">
]>

Následuje již samotné XML, jenž si v krátkosti slovně popišme. Kořenový element vozovy_park obsahuje elementy auto a poruchy. V autě je specifikována značka, barva, kola atd. Poruchy obsahuje elementy zavada a v nich textový popis závady.

ENTITY

A teď konečně k DTD souboru. Na prvním řádku je opět již zmiňovaná entita. Ta funguje v DTD a XML také jako proměnná. Vymyšlená fiktivní značka automobilu Haligali-Quanchula-Managna zní rozhodně zajímavě. Kdo by ji ale chtěl vypisovat do každého elementu znacka. Proto si nadefinujeme entitu následujícím způsobem.

<!ENTITY hqm “Haligali-Quanchula-Managna”>

A je to, v XML nyní stačí v elementu znacka zapsat entitu ve formátu &název_entity; – pro nás tedy &hqm; a tato proměnná se bude nahrazovat uloženým řetězcem. Proč je ale tato entita uložena jak v elementu !DOCTYPE v XML dokumentu, tak v DTD? Zbytečná duplicita? Ano i ne. Pokud si totiž budete chtít tento XML dokument otevřít například v prohlížeči Firefox, prohlížeč si neumí sáhnout pro entitu do DTD souboru, proto by vyhazoval chybu. Pokud však entitu definujeme přímo v !DOCTYPE, poradí si s překladem entity i – co se XML týká – primitivní webový prohlížeč.

ELEMENT

Dalším prvkem v DTD je <!ELEMENT vozovy_park (auto+, poruchy)>. V překladu do češtiny znamená – Existuje element s názvem vozovy_park, který obsahuje podelementy auto a poruchy. Podelement auto se vyskytuje alespoň jednou, poruchy přesně jednou.

Kvantifikátory výskytu podelementů jsou následující:

• + – jedna a víc
• * – nula a víc
• ? – nula nebo jedna
• bez znaménka – přesně jednou

Ve druhém elementu auto vidíme možnost volby mezi spz a docasna-spz. Znamená, že se v elementu auto jako podelement musí vyskytovat spz nebo docasna-spz. Je jedno která, ale jedna z nich povinně.

U elementu znacka je vidět, že již neobsahuje další podelementy, ale jen textový řetězec. Proto místo výčtu podelementů vepisujeme za název do závorky (#PCDATA).

Element může být i prázdný, tedy nemít žádný obsah, jako je tomu například u airbagu, jenž má vlastnost EMPTY. Pokud je nám jedno, co daný element obsahuje, dáme mu vlastnost ANY, jako např. u závady.

ATTLIST

Následuje výčet atributů pro auto vždy ve formátu

<!ATTLIST název_elementu

název_atributu1 typ_atributu1 výskyt_atributu1

název_atributu2 typ_atributu2 výskyt_atributu2 … >

Hlavní typy atributů:

• ID – jedinečné identifikační číslo v rámci XML dokumentu, musí začínat písmenem
• IDREF – odkazuje na cizí klíč, cizí ID (použito v případě závady, která odkazuje na id auta)
• (ano|ne|cokoliv) – výběr z daných možností (tj. výčtový typ, hodnota musí souhlasit s některou z hodnot ve výčtu)
• CDATA – obyčejný textový údaj
• NMTOKEN -  textový řetězec pouze z písmen, čísel a podtržítka

Hlavní výskyty atributů:

• #REQUIRED – vyžadovaný (atribut musí být uveden)
• #IMPLIED – nepovinný
• #FIXED “hodnota” – s pevně danou hodnotou
• “hodnota” – pouze hodnota (pokud není nijak jinak uveden, nastaví se na zadanou hodnotu. Dobře vidět u atributů elementu auto, kde pokud není závada uvedena jako reference na id závady, uloží se jako hodnota závady „není“)

CDATA

Elementy zavada obsahují dosud také nespatřenou sekci CDATA. Je použita, protože delší textová pole mohou obsahovat znaky, se kterými by si XML nerozumělo. Pro ukázku se ve druhé závadě hovoří o smyšlené součástce H<am>ster. Špičaté závorky by evokovaly otvírací tag dalšího elementu, to ale rozhodně není to, co bychom zamýšleli. CDATA nás uchrání před podobnými problémy.

Kontrola validity XML vůči DTD

Pro kontrolu, zda Váš XML soubor skutečně odpovídá DTD předpisu je možné použít v minulém tutoriálu zmíněné NetBeans nebo Altova Parser. Příkaz pro Altova Parser je podobný jako pro kontrolu Well-formedness. Například:

C:\Program Files\Altova>AltovaXML -validation "C:\XML\test.xml" –dtd “C:\XML\test.dtd”

Nebo v našem případě, kdy si dáme oba soubory do stejného adresáře, ve kterém je spouštěcí soubor Altovy:

Cesta_do_adresáře>AltovaXML –v vozovy_park.xml –dtd vozovy_park.dtd