Doplňková validace HTML a XHTML dokumentů

Existuje několik zdrojů omezení, která jsou kladena na dokumenty v jazyce HTML. Hlavním zdrojem standardizačních aktivit je v dnešní době W3C (World Wide Web Consorcium), které vydává tzv. doporučení v podobě specifikací jazyka HTML. Standardizací HTML se zabývá i Mezinárodní organizace pro standardizaci (ISO) spolu s Mezinárodní elektrotechnickou komisí (IEC). Jejich specifikace ISO/IEC 15445 viz. [ISO15445], známá též jako ISO-HTML, vychází z HTML 4.01 od W3C. ISO-HTML je v podstatě podmnožinou HTML 4.01, neboť tuto specifikaci dále omezuje, ale nerozšiřuje. Dá se tedy říci, že dokument, který je validní podle ISO-HTML, bude validní i podle specifikace W3C (nemusí platit obráceně). Kromě zmíněných standardů existuje ještě celá řada dalších, které se snaží nějakým způsobem vést autory k psaní kvalitnějších dokumentů a vývojáře prohlížečů k jejich lepšímu zobrazování. Jedním z nich je i směrnice WCAG, která se snaží o zpřístupnění HTML stránek co nejširšímu okruhu uživatelů. Touto směrnicí se budeme také dále zabývat.

Doporučení W3C definují celou škálu variant jazyka HTML. Pokud pomineme starší verze, které není doporučeno používat, je v dnešní době aktuální HTML 4.01, které je díky dobré kompatibilitě s prohlížeči velice rozšířené. Z tohoto jazyka dále vychází jazyk XHTML 1.0, který není v podstatě ničím jiným než restrikcí HTML 4.01 tak, aby splňoval omezení jazyka XML. To přináší celou řadu výhod. Zpracování takového dokumentu je o poznání jednodušší. Navíc lze využít bohatou škálu nástrojů vyvinutých pro jazyk XML, jako jsou různé parsery, transformační nástroje nebo validační jazyky. Další verze XHTML pak přináší modularizaci jednotlivých konstruktů jazyka, což umožňuje vytvářet libovolné podmnožiny jazyka HTML podle potřeby. V této práci se zaměříme hlavně na XHTML 1.0 a HTML 4.01. Důvodem je jejich široké používání v praxi. Také platí, že HTML 4.01 je v podstatě poslední verzí, kde došlo ke změně množiny elementů a atributů jazyka. Další verze postavené na XML totiž samotný jazyk nijak závažně nemění. Specifické modifikace jazyka, jako je například XHTML Print, XHTML Basic a další, jsou nad rámec této práce.

Doporučení W3C rozeznávají v zásadě dva hlavní adresáty definovaných omezení. Jedni jsou lidé implementující prohlížeče HTML dokumentů. Ti musí vědět, jaký význam přikládat jednotlivým elementům jazyka HTML a jakým způsobem tyto elementy a jejich obsah interpretovat. Těchto omezení se bude tato práce dotýkat pouze okrajově. Už z principu nemohou být předmětem validace HTML dokumentů, a proto ani předmětem validace doplňkové. Druhou skupinou jsou autoři dokumentů. Omezení týkající se autorů budou dále podrobně rozebrána. Právě ta z nich, která nejsou podchycena v oficiálních DTD definicích, budou předmětem doplňkové validace.

Některá doporučení adresovaná autorům dokumentů se zabývají tím, jakým způsobem mají autoři ošetřit některé prezentační aspekty dokumentů ve stylových definicích. Tato omezení nebudou předmětem této práce, protože je není možné automaticky validovat na základě validace samotných HTML dokumentů.

Obrázek 1.1. Vztah SGML, XML, HTML a XHTML

Specifikace XHTML 1.0 je v podstatě přepracováním HTML 4.01 tak, aby splňovala omezení kladená na jazyk XML (Extensible Markup Language). XHTML je tedy aplikací XML. Množina elementů a atributů je plně poděděna z HTML 4.01. Kromě omezení, která vznikla z důvodu dodržování přísnější syntaxe jazyka XML, definuje specifikace ještě několik doporučených postupů, které mají zajistit zpětnou kompatibilitu XHTML dokumentů s HTML prohlížeči.

Přechod na XML zajišťuje jazyku HTML nemalé výhody. Autoři dokumentů i prohlížečů mohou k editaci i zpracování XHTML dokumentů využívat velkou škálu nástrojů, aplikací a knihoven, které XML podporují. Těch je vzhledem k oblíbenosti tohoto jazyka v dnešní době skutečně velké množství. K nim se řadí i validační nástroje, které budou předmětem další kapitoly. Důvodem, proč je XML tak populární, je pravděpodobně to, jakým způsobem zachovává původní vyjadřovací schopnosti SGML, a přitom snižuje jeho přílišnou komplexitu. Striktní syntaxe XML nedovoluje některé možnosti zápisu elementů a atributů, které byly možné v případě HTML odvozeného přímo ze SGML. Tato striktnost výrazně ulehčuje práci aplikacím zpracovávajícím XHTML, jako jsou například prohlížeče. Tato skutečnost je významná například pro mobilní zařízení s malým výpočetním výkonem.

Dokumenty striktně splňují specifikaci XHTML, pokud splňují všechna mandatorní omezení uvedená ve specifikaci. Takový dokument musí odpovídat některé DTD definici v rámci XHTML 1.0. Kořenový element musí mít definován odpovídající jmenný prostor a odpovídajícím způsobem musí být deklarován i typ dokumentu s odkazem na použité DTD. Jmenné prostory přinášejí zajímavou možnost kombinovat XHTML s jinými XML jazyky, jako je například SVG, používané pro vyjádření vektorové grafiky, nebo MathML, používané pro vyjádření matematických vzorců.

ISO-HTML je de facto mezinárodní standard, na jehož tvorbě se podílela Mezinárodní standardizační organizace (ISO) a Mezinárodní elektrotechnická komise (IEC). Blízce spolupracovalo i W3C. Ostatně ISO-HTML vychází z doporučení W3C pro HTML 4.01 viz. [HTML4]. ISO-HTML respektuje všechna omezení v tomto doporučení a přidává navíc některá vlastní viz. [ISO15445]. Cílem standardizace ISO-HTML je definovat určité jádro jazyka HTML, které bude obsahovat jen obecně podporované funkce, aby dokumenty splňující tyto standardy byly zobrazitelné na co největším okruhu prohlížečů a platforem.

V zásadě platí, že mnoho elementů je převzato bez jakýchkoli změn z doporučení W3C z mutace strict a některé elementy jsou upraveny o další restrikce. Mnoho atributů je vypuštěno, protože popisují spíše prezentaci a ne význam elementů. ISO-HTML se zbavuje všech potlačených prvků, všech vlastností, jejichž role je pouze kosmetická, a také prvků, které jsou nestabilní nebo nevyzrálé. Také byly vypuštěny některé volitelné konstrukty, jako je například vynechávání některých značek. Syntaxe jazyka se tak stala striktnější i na té nejnižší úrovni. ISO-HTML také není svázáno požadavky na zpětnou kompatibilitu, jako jsou doporučení W3C.

WAI (Web Accessibility Initiative) je iniciativa při W3C, která se snaží koordinovaně s organizacemi po celém světě pomoci webu a HTML dokumentům, aby byly dostupnější pro všechny, tedy i pro osoby s různými postiženími a podobně. Kromě jiných aktivit vydává i směrnice týkající se dokumentů HTML. Ty budou právě předmětem našeho zájmu.

Směrnice pro dostupnost webového obsahu WCAG (Web Content Accessibility Guidelines) viz. [WCAG1] jsou určeny primárně autorům HTML dokumentů a autorům publikačních nástrojů. Dodržování těchto standardů nepřináší jenom větší dostupnost pro uživatele s postiženími, ale obecně zlepšuje dostupnost pro všechny uživatele bez ohledu na platformu a nebo prohlížeč. Další oblastí, kde mají směrnice pomoci, je lepší vyhledávání dokumentů.

Směrnice WCAG řeší v podstatě dva základní okruhy problémů. První okruh se zabývá dostupností dokumentů v různých prostředích a s různými omezeními na straně uživatele. Jde například o fyzická, senzorická a jiná postižení nebo pracovní a technologické bariéry. Obecně se dá říci, že v této oblasti pomáhá mimo jiné: separování prezentační a strukturální vrstvy, využívání textu (ten je totiž dostupný v podstatě v jakémkoli prostředí), poskytování informací ve vizuálních i v nevizuálních kanálech a vytváření stránek nezávisle na hardwaru (malá obrazovka, bez myši apod.). Těmito problémy se zabývají směrnice 1 až 11.

Směrnice 12, 13 a 14 se zbývají druhým okruhem problémů. Jejich cílem je učinit dokumenty srozumitelné a lehce navigovatelné. Autoři by měli vybavit dokumenty navigačními nástroji a informacemi pro lepší orientaci v dokumentech.

Jednotlivá doporučení v rámci směrnice jsou opatřena prioritami. Existují tři základní prioritní stupně. Splnění směrnice s prioritou 1 je naprostou nutností. Pokud není takové doporučení splněno, bude dokument nedostupný pro některé skupiny uživatelů. Priorita 2 říká, že nesplnění tohoto doporučení nevede sice k nedostupnosti dokumentu, ale značně ztěžuje jeho dosažení určitým skupinám uživatelů. Doporučení s prioritou 3 vede obecně ke zlepšení dostupnosti dokumentů.

Dodržené priority determinují stupeň souladu dokumentu se směrnicemi. Dokumenty s označením „Triple-A“ splňují všechny priority, dokumenty „Double-A“ první dvě priority a dokumenty označené „A“ jen prioritu 1.

WAI neposkytuje automatickou možnost validace svých směrnic. Díky pokročilým validačním jazykům jsou některé části těchto směrnic předmětem doplňkové validace v rámci této práce.

V dnešní době existují desítky různých validačních jazyků, které validují XML dokumenty. Liší se od sebe stupněm dospělosti, rozšířeností, čitelností, podporou (jsou například zaštiťovány některou organizací s významným slovem v oblasti IT), oblíbeností v uživatelské komunitě a samozřejmě vyjadřovací schopností a přístupem k popisu omezení obecně.

V této práci není možné porovnávat vlastnosti a vhodnost všech validačních jazyků, kterých jsou desítky. Je nutné učinit určitý výběr, a ten teprve podrobit důslednějšímu zkoumání. Do tohoto výběru byly zvoleny jazyky: XML DTD, XML Schema, Relax NG, Schematron a DSD. V následujících několika odstavcích bude vysvětleno, jaké zajímavé vlastnosti jednotlivých jazyků vedly k jejich vybrání.

V této části se zaměříme na výčet schopností, které jsou obecně vlastní validačním jazykům a porovnáme podporu těchto vlastností v rámci námi vybraných kandidátů. Porovnání těchto základních vlastností je důležité, abychom si udělali přehled o celkových schopnostech a vyjadřovací síle vybraných jazyků. Cílem této části není pouze vybrat řešení, které popíše maximum omezení kladených na HTML dokumenty viz. první kapitola, ale je nutné vybrat i řešení, které bude nejsnadněji implementovatelné, dobře čitelné, pochopitelné a rozšiřitelné v případě, bude-li žádoucí implementovat některá další omezení. Například některé nově vznikající standardy W3C.

Dalším důležitým aspektem výběru vhodného jazyka je schopnost vyjádřit omezení modulárním způsobem. To bude velice důležité pro následnou formalizaci omezení jazyka HTML a XHTML a také pro implementaci prototypové aplikace, která by měla být schopná dynamicky validovat dokumenty jen oproti určité skupině omezení. Schopnost elegantně vyjádřit tato omezení v určitých vymezených modulech a tyto moduly následně jednoduše spojovat a rozdělovat bude tedy pro tuto práci klíčová.

Například mutace jazyka HTML/XHTML viz. sekce „Strict, Transitional, Frameset“ jsou definovány ve třech DTD definicích. Většina jednotlivých formalizačních zápisů se v těchto souborech vždy třikrát opakuje. Jednotlivé definice se liší jen málo. Přijetí takového konceptu by mělo za následek velice špatnou spravovatelnost definic. Každá změna by se musela zapisovat až třikrát a definice by se musely neustále udržovat navzájem konzistentní. Proto je jistě lepším řešením vyjádřit v přídavných modulech pouze odlišnosti jednotlivých mutací.

V následujícím textu je rozebrán určitý výčet podstatných vlastností validačních jazyků a jejich podpora mezi kandidáty pro doplňkovou validaci. Některé posuzované kategorie byly inspirovány prací [LEE-CHU].

<assert test="(number(@isbn) > 999999999) and (number(@isbn) < 1000000000)">
  ISBN je desetimístné číslo
</assert>

<!-- příklad v Schematronu -->
<rule context="Osoba">
  <report test="@vek and @datumNarozeni">
    Osoba nemůže obsahovat atribut vek a datumNarozeni současně
  </report>
</rule>

<!-- příklad v DSD -->
<if><element name="Osoba"/>
  <declare>
    <attribute name="vek"/>
    <attribute name="datumNarozeni"/>
  </declare>
  <if><attribute name="vek"/>
    <require><not><attribute name="datumNarozeni"/></not></require>
  </if>
  <if><attribute name="datumNarozeni"/>
    <require><not><attribute name="vek"/></not></require>
  </if>
</if>

<!-- příklad v Relax NG -->
<element name="Osoba">
  <choice>
  <attribute name="vek">
	  <text/>
  </attribute>
  <attribute name="datumNarozeni">
    <text/>
  </attribute>
  </choice>
</element>

<!-- příklad ve Schematronu (pouze pro typ radio) -->
<rule context="input">
  <report test="@type='radio' and not(@value)">
    Pokud atribut type obsahuje hodnotu 'radio' pak element input musí obsahovat atribut value
  </report>
</rule>

<!-- příklad v DSD (pouze pro typ radio) -->
<if>
	<and>
		<element name="input"/>
		<attribute name="type"><string value="radio"/></attribute>
	</and>
	<require>
		<attribute name="value"/>
	</declare>
</if>

<!-- příklad v Relax NG --> 
<!-- ošetřeny jsou všechny povolené hodnoty atributu type -->
<element name="input">
  <choice>
   <group>
     <attribute name="type">
       <choice>
         <value>radio</value>
         <value>checkbox</value>
       </choice>  
     </attribute>
     <attribute name="value"/>
   </group>
   <group>
     <attribute name="type">
       <choice>
         <value>text</value>
         <value>password</value>
         <value>submit</value>
         <value>reset</value>
         <value>hidden</value>
       </choice>
     </attribute>
     <optional>
       <attribute name="value"/>
     </optional>
   </group>
  </choice>
</element>

<!-- příklad v Schematronu -->
<rule context="a">
	<report test="(@hreflang) and not(@href)">
		Pokud element a obsahuje atribut hreflang, musí obsahovat i atribut href
	</report>
</rule>

<!-- příklad v Relax NG -->
<!-- nejsou definovány všechny atributy elementu a -->
<element name="a">
  <choice>
   <group>
     <attribute name="hreflang"/>
     <attribute name="href"/>
   </group>
   <group>
     <optional>
       <attribute name="href"/>
     </optional>
   </group>
  </choice>
</element>

Modularita

Tato část bude analyzovat možnosti validačních jazyků vzhledem k rozdělení definic omezení na drobné samostatné části. Bude také zkoumat možnosti jejich opětovného skládání do libovolných množin omezení dle aktuální validační potřeby.

Zahrnutí externích definic (include)

Tato funkcionalita nám umožňuje oddělit některé fragmenty definice do separátních souborů a následně je libovolně spojovat dohromady. Takový přístup zlepšuje čitelnost velmi dlouhých definic a umožňuje také jednoduše vytvářet více verzí omezení podle toho, které fragmenty do výsledné definice zahrneme. Zahrnutí externích definic je možné v XML DTD, XML Schema, Relax NG a DSD. Schematron sice přímo takovou funkcionalitu nepodporuje, ovšem díky jednoduchosti a otevřenosti návrhu Schematronu je ji možné lehce simulovat pomocí jím používaných technologií (XML, XSLT).

Dědění jednoduchých datových typů

Pokud máme modulární definici omezení, samotné poskládání jednotlivých fragmentů dohromady nám mnohokrát nestačí. Často je potřeba, aby nově zahrnutý fragment upravoval nějakým způsobem omezení již definovaná ve fragmentech ostatních a nebo z těchto omezení nějakým způsobem vycházel. Můžeme si tedy představit, že přidáním fragmentu potřebujeme spolu s ním zavést i nový datový typ. Ten se ovšem liší jen málo od některého datového typu, který již existuje v definici. Dědičnost tedy umožňuje rozšířit, a nebo omezit stávající definici datového typu.

Dobrou podporu pro dědičnost má XML Schema. Ovšem datové typy je možné pouze dále omezovat, a nikoli rozšiřovat. Relax NG umožňuje omezovat pouze zabudované datové typy, a nebo datové typy v přídavných knihovnách. Takto vzniklý typ není možné dále upravovat. Ovšem v Relax NG je možné i rozšiřovat enumerace o další povolené hodnoty. DSD umožňuje dále omezovat datové typy přidáním dalších booleovských podmínek. Podobně i Schematron může přidat další restrikce pomocí dodatečného testu. XML DTD se omezuje pouze na deset základních pevných datových typů a jejich expanzi ani restrikci neumožňuje. Kompletní přímou podporu rozšiřování datových typů neobsahuje žádný z uvedených jazyků (pouze nepřímo pomocí přepisu viz. dále).

Dědičnost a přepis definic elementů

Přidáním některého fragmentu do definice může nastat potřeba, aby tento fragment modifikoval některé stávající definice elementů. Pokud bychom například definovali omezení jazyka HTML a měli modul definic pro mutaci strict a k němu bychom zahrnuli ještě modul transitional, pak by bylo potřeba dodefinovat celou řadu elementů již definovaných ve strict tak, aby obsahovaly všechny prezentační atributy, které jsou v mutaci transitional navíc. Naopak v některých případech může vzniknout potřeba opačná. Přidáním některého fragmentu je potřeba omezit některé stávající definice elementů.

Obě předešlé možnosti jsou dostupné v XML Schema. XML Schema umožňuje díky elementu <redefine> zahrnout některý externí fragment a modifikovat libovolné definice v něm. Tento přístup má ovšem řadu omezení. Není například možné tyto definice kompletně přepsat, je možné je pouze rozšiřovat a nebo omezovat, což nemusí být vždy dostačující. Navíc tento mechanizmus umožňuje modifikovat pouze definice v zahrnovaném fragmentu. Zahrnovaný fragment nemůže ovlivnit definice ve fragmentu zahrnujícím.

Příklad 2.5.

<!-- Redefine v XML Schema, zákazník v main.xsd může obsahovat ještě element poznamka -->
fragment1.xsd:
<xs:complexType name="Osoba">
	<xs:sequence>
    <xs:element name="titul" minOccurs="0"/>
		<xs:element name="jmeno" minOccurs="0"/>
	</xs:sequence>
</xs:complexType>
	
<xs:element name="adresat" type="Osoba"/>
	
main.xsd:
<xs:redefine schemaLocation="fragement1.xsd">
  <xs:complexType name="Osoba">
  <xs:complexContent>
    <xs:extension base="Osoba">
      <xs:sequence>
        <xs:element name="poznamka" minOccurs="0"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
  </xs:complexType>
</xs:redefine>
	
<xs:element name="zakaznik" type="Osoba"/>

Další možností, jak lze pracovat s modulární strukturou definic v XML Schema, jsou abstraktní typy. Jedná se o přístup podobný abstraktním třídám z OOP. Tímto způsobem lze definovat globální typy, které se dají použít až pokud jsou dodefinovány v některém ze zahrnutých fragmentů. Chceme-li tedy měnit definici některého elementu v závislosti na použitých fragmentech, je nejprve nutné definovat v nějakém společném fragmentu jednotlivé abstraktní typy. Ty mohou být posléze konkretizovány v přídavných fragmentech. Definice těchto elementů se pak může libovolně měnit podle toho, jakým způsobem konkretizujeme tyto typy v zahrnutých fragmentech, a které fragmenty zahrneme do definice.

Pokud se vrátíme k původnímu příkladu s mutacemi transitional a strict, je zřejmé, že dva moduly definic nestačí. Budeme potřebovat jakousi hlavní definici, která bude deklarovat všechny společné elementy a připraví všechny abstraktní elementy, které se mohou v jednotlivých mutacích lišit viz. obrázek 2.1 – „Modularita definic HTML pro mutaci strict a transitional s fragmentem společných definic“. K této hlavní definici pak podle potřeby zahrneme fragment transitional nebo strict, které budou poskytovat konkrétní definice abstraktních elementů.

Obrázek 2.1. Modularita definic HTML pro mutaci strict a transitional s fragmentem společných definic

Oproti relativně těžkopádné modularitě definic v XML Schema přichází Relax NG s velice jednoduchým, ale vysoce expresivním konceptem. Expanze definic elementů pomocí zahrnutých fragmentů je řešena atributem combine. Jednotlivé fragmenty totiž mohou obsahovat více definic stejného jména. Atribut combine potom pouze určí, jakým způsobem se mají definice zkombinovat. Tento atribut určuje, zda se jedná o vylučovací výběr, sekvenci a nebo o elementy v libovolném pořadí. Restrikce již není tak přímočará. Dá se pro ni ovšem využít mechanizmus přepisu (viz. overwriting v OOP).

V místě zahrnutí externího fragmentu můžeme jednoduše přepsat libovolné definice z toho fragmentu na jejich restriktivnější verze. V příkladu s mutacemi jazyka HTML bychom tedy skutečně mohli mít pouze strict a transitional fragment. Pro validaci dokumentu psaného v mutaci strict bychom použili pouze strict fragment. Naopak v případě transitional bychom validovali oproti oběma fragmentům zahrnutým společně viz. obrázek 2.2 – „Modularita definic HTML pro mutace strict a transitional se samostatným fragmentem strict“. Definice tohoto zahrnutí by obsahovala případné restriktivní přepisy. Ovšem pouze pokud by mutace transitional kladla nějaká restriktivnější omezení oproti mutaci strict.

Obrázek 2.2. Modularita definic HTML pro mutace strict a transitional se samostatným fragmentem strict

Schematron je dosti odlišný od předešlých dvou jazyků, a proto se zde omezíme pouze na to, že restriktivní modularita je v něm v zásadě možná přidáním dodatečných testů.

DSD také poskytuje jisté nástroje pro podporu dědičnosti a přepisu. Restriktivní dědičnost není z principu jazyka problém. Jednoduše se zahrnou separátní fragmenty, které budou přinášet dodatečná omezení pro jednotlivé elementy. Problém nastává v případě expanzivních změn. Expanzivní změny nejsou implicitně podporovány. Nepomůžeme si ani přepisem. Ten byl podporován elegantním způsobem ve verzi jedna pomocí atributu renewId. Odkazem na identifikátor příslušného elementu bylo možné přepsat celou definici, a dokonce přepsat i případné přepisy. Ovšem s restrukturalizací jazyka tento prvek ve verzi dvě vymizel.

Tabulka 2.2. Souhrnný přehled schopností validačních jazyků. Tabulka obsahuje i další vlastnosti, které nebyly zmíněny výše.

Vlastnost	XML DTD 1.0	XML Schema 1.0	Relax NG 1.0	Schematron 1.5	DSD 2.0
Obecné vlastnosti
XML syntaxe	NE	ANO	ANO	ANO	ANO
Podpora jmenných prostorů	NE	ANO	ANO	ANO	ANO
Datové typy
Zabudované datové typy	10	37	2-?	0	0
Rozšiřitelnost datových typů	NE	ANO	ANO	Částečná	ANO
Atributy
Vylučovací výskyt atributů	NE	NE	ANO	ANO	ANO
Podmíněná hodnota atributu	NE	NE	ANO	ANO	ANO
Podmíněný výskyt atributu na základě hodnoty jiného atributu	NE	NE	ANO	ANO	ANO
Povinné a nepovinné atributy	ANO	ANO	ANO	ANO	ANO
Elementy
Různé typy obsahu elementů	ANO	ANO	ANO	ANO	ANO
Pevné pořadí elementů	ANO	ANO	ANO	ANO	ANO
Neřazené sekvence elementů	Částečně (nutné definovat všechny možnosti)	ANO	ANO	ANO	ANO
Exklusivita (jeden vylučuje druhý)	ANO	ANO	ANO	ANO	ANO
Počet výskytu elementů	Částečně	ANO	Částečně	ANO	ANO
Podmíněný výskyt elementů	v zásadě NE	v zásadě NE	v zásadě NE	ANO	ANO
Modularita
Zahrnutí externích definic	ANO	ANO	ANO	přímo NE	ANO
Dědění jednoduchých datových typů restrikcí	NE	ANO	NE	ANO	ANO
Dědění jednoduchých datových typů expanzí	NE	NE	NE	NE	NE
Dědění definic restrikcí	NE	ANO	ANO	ANO	ANO
Dědění definic expanzí	NE	ANO	NE	NE	NE
Přepis definic	NE	NE	ANO	NE	NE

Obrázek 2.3. Profily validačních jazyků (koncept je převzat z [LEE-CHU] a přizpůsoben této práci)

S validačními jazyky úzce souvisí i čitelnost. Pokud negenerujeme a nezpracováváme definice omezení strojově, ale vytváříme je ručně, a tyto definice jsou značně rozsáhlé, což je přesně případ této práce, je čitelnost velice důležitým faktorem. S čitelností úzce souvisí také modularita, která byla rozebrána v předešlé části. Jazyk, který dovoluje rozdělit definice do malých úzce specifikovaných modulů a který nevytváří příliš velké náklady na jejich pozdější skloubení, obsahuje nezbytný základ k dobré čitelnosti rozsáhlých definic. Posouzení čitelnosti jednotlivých jazyků by mělo být považováno spíše za orientační, neboť čitelnost je vágní pojem, a není tedy možné jasně ohodnotit nejčitelnější z jazyků. Každý jazyk může být vhodnější pro popis určitých typů omezení nebo struktur. Navíc stejná omezení mohou být zapsána mnoha různými způsoby, a proto by opravdu vypovídající srovnání muselo být značně rozsáhlé. Jednoduchý příklad zápisu stejných omezení v různých jazycích je uveden v příloze A – „Definice záznamu o knize v jednotlivých validačních jazycích“. Z této přílohy si lze udělat alespoň hrubý obrázek o tom, co formalizace omezení v jednotlivých jazycích obnáší a jak se liší rozsáhlost a čitelnost definic v případě popisu stejných omezení.

V zásadě se dá říci, že XML obecně čitelnosti příliš neprospívá. Čitelnost definic psaných v DTD a nebo v kompaktní formě Relax NG je velice dobrá. XML Schema je ve svých definicích dosti rozvláčné. Dá se říci, že zápis podobných struktur v Relax NG bude vycházet o něco lépe. Filozofie Schematronu je značně odlišná od ostatních jazyků. Schematron není vhodným jazykem pro popis kompletní struktury dokumentů. Spíše je vhodný pro vyjádření jednotlivých testů. Proto je zápis ve Schematronu v podstatě nejméně čitelný. Na druhou stranu existuje celá řada případů, které lze vyjádřit jednoduchým Schematronovým testem, zatímco v ostatních jazycích by byla jejich formalizace velice komplikovaná, pokud by byla vůbec možná. Někde mezi Schematronem a ostatními stojí DSD, které je určitým kompromisem a umožňuje popsat relativně čitelně oba zmíněné přístupy. Uspořádání jednotlivých testů v DSD má totiž blízko ke kompletním strukturálním definicím.

Pro doplňkovou validaci se nemusíme omezovat pouze na použití jednoho z výše uvedených jazyků. Naopak velký potenciál může být skryt v kombinaci dvou či více jazyků. Taková kombinace by mohla zajistit maximální vyjadřovací schopnost při zachování určité přehlednosti a spravovatelnosti definic. Ideálním kandidátem na kombinování je Schematron. Jeho architektura přímo nabádá, aby se stal doplňkovým jazykem k jinému validačnímu jazyku. Většina struktury tak může být vyjádřena klasickým způsobem. Špatně vyjádřitelná či klasicky nevyjádřitelná omezení lze definovat dodatečně pomocí Schematronu.

<define name="a">
  <element name="a">
    <!-- Začátek Schematronového fragmentu -->
    <sch:pattern name="nested.a">
      <sch:rule context="html:a">
        <sch:report test="descendant::html:a">
          Element a nesmí obsahovat sebe sama na libovolné úrovni vnoření.
        </sch:report>
      </sch:rule>
    </sch:pattern>
    <!-- Konec Schematronového fragmentu -->
    <ref name="a.attlist"/>
    <ref name="Inline.model"/>
  </element>
</define>

Relax NG i XML Schema nabízejí dobrou podporu vnořených Schematronových testů. V XML Schema lze Schematron ukrýt ve značkách určených pro anotace. Obsah elementu <appinfo> je při validaci ignorován. Vhodnou transformací je pak možné vybrat pouze Schematronové definice a validovat oproti nim. Problematické je, že anotační elementy není možné přidat na libovolné místo definice. Ještě lepší mechanizmus nabízí Relax NG. Ten totiž ignoruje jakoukoli součást definice zapsanou v jiném jmenném prostoru, než je jmenný prostor používaný tímto jazykem. Schematron tak můžeme přidávat prakticky kamkoli. Dodatečná omezení týkající se určitého aspektu definice tak mohou být zapsána přímo tam, kde jsou definována i související omezení v rámci Relax NG. Validaci vůči Schematronu lze opět uskutečnit po jednoduché transformaci.

Otázkou je, jakým způsobem by mělo smysl kombinovat DSD. Tento jazyk stojí někde uprostřed dvou rozdílných přístupů k validaci XML dokumentů. Sám o sobě má silnou vyjadřovací schopnost v obou těchto směrech. Nedosahuje ovšem takových výsledků jako kombinace Schematronu a jiného jazyka. Kombinace se Schematronem ani s Relax NG nebo XML Schema by tento problém nevyřešila. Obě zmíněné možnosti by DSD nepřinesly žádnou přidanou hodnotu. Jazyky by se svými schopnostmi vždy z velké části překrývaly. Definice by se staly zbytečně složité a špatně spravovatelné.

Validaci oproti více validačním jazykům lze definovat i pomocí tzv. NRL (Namespace Routing Language) viz. [NRL]. Tento jazyk slouží k mapování různých jmenných prostorů na definice omezení psané v různých validačních jazycích. Fragmenty XML v příslušném jmenném prostoru jsou pak validovány oproti specifikovaným definicím. Ovšem pro jeden jmenný prostor lze definovat i více validačních definic. Následující příklad nám ukazuje, jakým způsobem lze konfigurovat validaci XHTML dokumentů oproti Relax NG i Schematronové definici zároveň.

<rules xmlns="http://www.thaiopensource.com/validate/nrl">
  <namespace ns="http://www.w3.org/1999/xhtml">
    <validate schema="xhtml.rng"/>
    <validate schema="xhtml.sch"/>
  </namespace>
</rules>

Po důkladném zvážení všech pro a proti se nejvýhodnější kombinací validačních jazyků pro doplňkovou validaci HTML a XHTML dokumentů zdá být kombinace Relax NG a Schematronu. Tato kombinace přináší výbornou vyjadřovací schopnost (lze vyžít regulárních výrazů i jazyka XPath) a velice dobrou integrovatelnost obou jazyků. Integrovaný Schematron lze jednoduše validovat pomocí běžných transformačních nástrojů v rámci XML. Není tedy potřeba využívat dodatečné nástroje, jako je NRL. Ty by mohly mít význam v případě kombinované validace vůči mnoha různým validačním jazykům nebo při validaci různých vnořených XML fragmentů s různými jmennými prostory.

Velice silnou kombinací by jistě bylo i XML Schema spolu se Schematronem. Dá se říci, že vyjadřovací schopnost této a předešlé varianty je téměř totožná. Pro Relax NG ovšem mluví lepší čitelnost definic, lepší (i když téměř srovnatelná) integrovatelnost se Schematronem, dobře navržené možnosti modularity, ale hlavně obecně jednoduchost a jistá elegance vyjadřování.

DSD je podle mého názoru jazyk s velkým potenciálem a výbornou vyjadřovací schopností. Proti mluví určitá nedospělost, která se vyznačuje velkými změnami ve struktuře jazyka ve verzi dvě oproti předešlé verzi jedna. Tento jazyk také není tak široce používán jako jeho konkurenti. To vede k horší podpoře a nedostatku kvalitních nástrojů. Nasazení tohoto jazyka je tedy rizikové. Neexistuje zde dostatečná komunita uživatelů, která může pomoci řešit případné problémy. Použití pouze jednoho validačního jazyka je vzhledem k jednoduchosti definice lákavé, ovšem zmíněné kombinace Schematronu a jiného jazyka jsou velice dobře integrovatelné a zároveň i čitelnost je na takové úrovni, že v obecném kontextu ztrácí nasazení DSD pro doplňkovou validaci v rámci této práce smysl.

Samotné Relax NG nebo XML Schema přinášejí už samy o sobě výrazně lepší vyjadřovací schopnost než DTD. Jenom oblast datových typů řeší celou řadu omezení, které nebylo možné definovat pomocí DTD. Ovšem kombinace se Schematronem přináší poměrně velkou přidanou hodnotu. I v případě, že lze určité omezení formalizovat bez využití Schematronu, může být tato definice poměrně složitá a její zakomponování do zbytku definice může vyžadovat značné změny na více místech. V takovém případě přináší Schematron jednoduchou a čitelnou alternativu „za rozumnou cenu“. Jeho přidáním se totiž nezhoršuje nijak zásadně komplexnost definice ani čitelnost (spíše naopak). Jedinou komplikací je problém správného řešení vícejazyčné validace. Ovšem s dobře navrženou validační aplikací se i tento problém stává jednoduše řešitelným.

Ještě jsme se nevěnovali kombinaci XML DTD a Schematronu. Tato možnost by znamenala velice jednoduchou implementaci. Stačilo by užít stávající definice a přidat pouze Schematronové testy pro chybějící omezení. Jistě by šlo o řešení velice jednoduché, které by přinášelo neoddiskutovatelnou přidanou hodnotu, ale mnoho omezení by se nedalo řádně podchytit. Hlavně simulovaná funkcionalita datových typů ve Schematronu není dostatečně výstižná, aby podchytila všechny rozdílné požadavky kladené standardy HTML. XPath ve verzi 1.0 se v tomto ohledu nemůže rovnat vyjadřovacím schopnostem regulárních výrazů podporovaných v jiných validačních jazycích.

Zajímavá je jistě i možnost kombinace XML DTD a DSD užitého pouze pro doplňkovou validaci. Ta by oproti předešlé alternativě přinášela větší expresivitu v oblasti datových typů a menší v oblasti popisu struktury. Hlavní nevýhodu tohoto řešení lze vidět v malé rozšířenosti DSD a špatné integrovatelnosti obou jazyků.

V této kapitole se budeme zabývat formalizací jednotlivých omezení kladených na HTML dokumenty pomocí jazyků Relax NG a Schematron. Tato kapitola popisuje nejen zajímavé aspekty konkrétní implementace některých omezení, ale i celkovou architekturu definic. Popisuje i metodiku implementačních prací a nastiňuje základní vývojový cyklus, který pomáhá zajistit konzistenci a správnost definic. Pokud nebude řečeno jinak, budeme se zabývat výhradně formalizací omezení specifikovaných v doporučení W3C pro jazyky HTML 4.01 a XHTML 1.0. K formalizaci směrnic WCAG 1.0 se dostaneme v závěru této kapitoly.

Jako základ pro implementaci omezení byla zvolena modulární definice XHTML napsaná Jamesem Clarkem viz. [XHTMLMOD-RNG]. Ta vychází z modularizace XHTML popsané v doporučení W3C viz. [XHTMLMOD]. Toto doporučení zatím nebylo v této práci zmíněno. Ve stručnosti se dá říci, že modularizace XHTML vychází plně z XHTML 1.0, ale nerozlišuje již mutace jazyka strict, transitional a frameset. Místo toho zavádí mnoho malých modulů, z nichž každý definuje určitou jasně vymezenou oblast jazyka.

Takový přístup přináší řadu výhod. Definice jsou přehledné a neopakují se na více místech. Navíc modularizace umožňuje vytvářet mnoho různých kombinací podmnožin jazyka HTML a validovat pouze tyto podmnožiny. Validace takovýchto podmnožin je nad rámec této práce. Ovšem dodržení modularity definic (tak jak je popsána v [XHTMLMOD]) přinese hlavně jejich lepší čitelnost a spravovatelnost. Správným poskládáním příslušných modulů bude možné vytvořit jednotlivé mutace jazyka HTML podle [HTML4] a [XHTML1].

Použitá definice od Jamese Clarka je v zásadě implementací modularizace XHTML v Relax NG. Oproti implementaci od W3C, která využívá XML DTD, demonstruje tato definice jednoduchost, s jakou lze vytvářet a spojovat jednotlivé moduly v Relax NG. Zatímco v DTD je nutná existence jakési společné definice, do které lze teprve zahrnovat další moduly, v Relax NG takovouto definici nepotřebuje. Jednotlivé moduly se po svém zahrnutí samy umí postarat o správnou modifikaci definic příslušných elementů.

Zmíněná implementace definic posloužila této práci pouze jako hrubý základ. Vzhledem k tomu, že se jedná o čistě ukázkovou záležitost, která slouží k demonstraci některých vlastností jazyka Relax NG, obsahují tyto definice velké množství nepřesností a chyb, které bylo nutné v prvé řadě odstranit. Moduly jsou navíc navrženy tak, že není možné oddělit definice pro mutace transitional a frameset. Dalším úkolem tedy bylo fragmentovat definice, aby byla umožněna separátní validace těchto mutací.

Původní definice v Relax NG si nekladla za cíl žádnou doplňkovou validaci. Záměrem bylo pouze vyjádření modularity XHTML elegantněji, než je to možné v DTD. Posledním úkolem tedy bylo doplnit všechna dodatečná omezení (nad rámec DTD), která lze vyjádřit díky skvělé expresivitě kombinace validačních jazyků Relax NG a Schematron.

Obrázek 3.1. Jednotlivé moduly definice a vyjádření mutací jazyka HTML pomocí jejich uskupení

Moduly využité v definici odpovídají zhruba modulům definovaným v [XHTMLMOD]. V některých případech jsou ještě o něco málo podrobnější, než uvádí toto doporučení W3C. Ačkoli vyjádření různých podmnožin HTML (včetně specifické mutace zvané XHTML Basic) je pomocí různých kombinací modulů principielně možné, tato práce se bude snažit o korektní validaci pouze v případě XHTML 1.0 a HTML 4.01. Validace jiných mutací jazyka HTML je sice nad rámec této práce, ovšem zvolená architektura dává výborný odrazový můstek k budoucímu rozšíření definice tak, aby kompletně splňovala doporučení pro modularizaci XHTML.

Vývojový cyklus implementace formalizací jednotlivých omezení, který byl aplikován v této práci, ukazuje obrázek 3.2 – „Vývojový cyklus při formalizaci omezení“. V první fázi je vybráno konkrétní omezení, které má být naimplementováno. Podkladem pro tento výběr je kapitola 1 – „Analýza omezení a požadavků kladených na HTML a XHTML dokumenty“. V druhé fázi je pak zvolen vhodný způsob formalizace. Cílem je vybrat logické začlenění do zbytku definic a vhodný modul, jehož se toto omezení stane součástí. Je také nutné zvolit jazyk, který bude nejlépe odpovídat typu omezení a jeho specifikám. V našem případě tedy volíme mezi Relax NG a Schematronem.

Následuje implementace vybraného omezení. V této fázi je formalizované omezení zapsáno ve vybraném jazyce a umístěno na správné místo v některém z modulů. Součástí této fáze je i tvorba výstižných komentářů k implementovaným definicím. Tyto komentáře jsou obzvláště důležité u Schematronových testů, kde by měly důsledně popisovat mechanizmus testu, a u regulárních výrazů, kde by měly sloužit jako slovní popis takového výrazu.

Poslední fáze, která se zabývá testováním, je fází nejdůležitější. Každé implementované omezení je nutné řádně otestovat. Je nutné zjistit, zda se nově implementované doplňkové omezení chová tak, jak jsme skutečně zamýšleli. Důležitou součásti takového testu je i ověření, zda definice zůstávají v souladu s oficiálním DTD od W3C. Všechny chyby, které je možné automaticky validovat proti tomuto DTD, by měla odhalit jako chyby i naše definice.

Obrázek 3.2. Vývojový cyklus při formalizaci omezení

Pokud pomineme implementaci jednotlivých definic, je výstupem vývojového cyklu v každé jeho fázi i soustava testových úloh. Každá taková úloha má v podstatě podobu jednoduchého HTML dokumentu. Tento dokument může být validní i chybný. Cílem testu je určit, zda jsou validní dokumenty skutečně validní a zda jsou v chybných dokumentech správným způsobem označeny všechny chyby. Každá testová úloha se váže ke konkrétnímu omezení. Implementace každého nového omezení má vyústit v napsání jedné, nebo několika testových úloh, které prověřují důležité aspekty tohoto omezení. V průběhu vývojového cyklu takto vzniká hierarchicky uspořádaná knihovna testových úloh. Takováto knihovna přináší mnoho výhod. Umožňuje například udržovat definice konzistentní v průběhu celého vývojového cyklu. Součástí testovací fáze je totiž i kontrola toho, zda nebyla přidáním nové definice narušena nějaká již implementovaná funkcionalita a zda se všechny přítomné testové úlohy chovají stále správně a konzistentně s DTD. Toho je dosahováno tím, že není testováno pouze nové omezení a jeho testové úlohy, ale při každém zásahu do definice dojde ke kompletnímu testu všech testových úloh v knihovně. Teprve pokud se všechny testy chovají korektně, lze definici v aktuální podobě zachovat.

Takováto automatizovaná podpora vývoje je možná díky implementaci testového prostředí, jehož popis je součástí kapitoly 4 – „Implementace prototypové validační aplikace“.

V této části se podíváme na to, jak je konkrétním způsobem řešena formalizace některých omezení. Pokusíme se zvolit k tomuto účelu vhodné kandidáty, kteří budou demonstrovat různé formalizační přístupy. Kompletní výčet formalizací opatřených komentáři je součástí přiložené prototypové validační aplikace a není tedy plně zmiňován v tomto textu.

<define name="URI.datatype">
  <data type="anyURI"/>
</define>

<define name="tabindexNumber.datatype">
  <data type="nonNegativeInteger">
    <!-- pouze sekvence číslic -->
    <param name="pattern">[0-9]+</param>
    <param name="minInclusive">0</param>
    <!-- shora omezeno, maximálně 32767 včetně -->
    <param name="maxInclusive">32767</param>
  </data>
</define>

(Black|Green|Silver|Lime|Gray|Olive|White|Yellow|Maroon|Navy|Red|Blue|
Purple|Teal|Fuchsia|Aqua)|#[0-9A-Fa-f]{6}

[bB][lL][aA][cC][kK]|[gG][rR][eE][eE][nN]|[sS][iI][lL][vV][eE][rR]|[lL]
[iI][mM][eE]|[gG][rR][aA][yY]|[oO][lL][iI][vV][eE]|[wW][hH][iI][tT][eE]
|[yY][eE][lL][lL][oO][wW]|[mM][aA][rR][oO][oO][nN]|[nN][aA][vV][yY]|
[rR][eE][dD]|[bB][lL][uU][eE]|[pP][uU][rR][pP][lL][eE]|[tT][eE][aA]
[lL]|[fF][uU][cC][hH][sS][iI][aA]|[aA][qQ][uU][aA]|[0-9A-Fa-f]{6}

<define name="URIs.datatype">
  <list>
    <oneOrMore>
      <data type="anyURI"/>
    </oneOrMore>
  </list>
</define>

<define name="shape.attrib">
  <optional>
    <choice>
      <group>
        <attribute name="coords">
          <!-- Implicitním tvarem je obdélník. Pokud není přítomen atribut shape, předpokládají se tedy souřadnice pro obdélník (rect). -->
          <ref name="coords.rect.datatype"/>
        </attribute>
      </group>
      <group>
        <!-- V případě hodnoty default je tvarem celá plocha a není tedy třeba specifikovat jednotlivé souřadnice. --> 
        <attribute name="shape">
          <value>default</value>
        </attribute>
      </group>
      <group>
        <attribute name="shape">
          <value>poly</value>
        </attribute>
        <attribute name="coords">
          <ref name="coords.datatype"/>
        </attribute>
      </group>
      <group>
        <attribute name="shape">
          <value>rect</value>
        </attribute>
        <attribute name="coords">
          <ref name="coords.rect.datatype"/>
        </attribute>
      </group>
      <group>
        <attribute name="shape">
          <value>circle</value>
        </attribute>
        <attribute name="coords">
          <ref name="coords.circle.datatype"/>
        </attribute>
      </group>
    </choice>
  </optional>
</define>

<!-- zde jsou definovány různé podoby povolených souřadnic pro různé typy tvarů -->
<define name="coords.datatype">
  <data type="string">
    <!-- tento tvar souřadnic je povolen v případě polygonu -->
    <!-- Regulární výraz umožňuje zapsat libovolný počet délek oddělených čárkou. -->
    <param name="pattern">( )*([-+]?(\d+|\d+(\.\d+)?%))(( )*,( )*[-+]?(\d+|\d+(\.\d+)?%))*( )*</param>
  </data>
</define>
<define name="coords.circle.datatype">
  <data type="string">
    <!-- tento tvar souřadnic je povolen v případě kruhu -->
    <!-- je možné zapsat přesně tři délky oddělené čárkou -->
    <param name="pattern">( )*([-+]?(\d+|\d+(\.\d+)?%)( )*,( )*){2}([-+]?(\d+|\d+(\.\d+)?%))( )*</param>
  </data>
</define>
<define name="coords.rect.datatype">
  <data type="string">
    <!-- tento tvar souřadnic je povolen v případě obdélníku -->
    <!-- je možné zapsat přesně čtyři délky oddělené čárkou -->
    <param name="pattern">( )*([-+]?(\d+|\d+(\.\d+)?%)( )*,( )*){3}([-+]?(\d+|\d+(\.\d+)?%))( )*</param>
  </data>
</define>

<sch:pattern name="area.shape.coords">
  <sch:rule context="html:area">
    <sch:report test="@shape = 'circle' and (string(number(substring-before(@coords,','))) = 'NaN' or string(number(substring-before(substring-after(@coords,','),','))) = 'NaN' or string(number(substring-after(substring-after(@coords,','),','))) = 'NaN')">
      Pokud je atribut shape elementu area nastaven na hodnotu circle,
      atribut coords musí obsahovat právě 3 čísla oddělená čárkou.
    </sch:report>
  </sch:rule>
</sch:pattern>

<define name="ul">
  <element name="ul">
    <ref name="ul.attlist"/>
      <oneOrMore>
        <ref name="li"/>
      </oneOrMore>
  </element>
</define>

<define name="ul.attlist">
  <ref name="Common.attrib"/>
</define>

<define name="ul.attlist" combine="interleave">
  <optional>
    <attribute name="type">
      <choice>
        <value>disc</value>
        <value>square</value>
        <value>circle</value>
      </choice>
    </attribute>
  </optional>
  <optional>
    <attribute name="compact">
      <value>compact</value>
    </attribute>
  </optional>
</define>

<include href="modules/base.rng">
  <!-- přepis --> 
  <define name="base.attlist">
    <optional>
      <attribute name="href">
		    <ref name="URI.datatype"/>
      </attribute>
    </optional>
  </define>
</include>

<sch:rule context="html:param">
    <sch:assert test="@name">
      Atribut name elementu param je povinný.
    </sch:assert>
  </sch:rule>

<!-- implicitní jmenný prostor patří Relax NG, ale jmenný prostor označený předponou "sch" patří Schematronu -->
<grammar xmlns="http://relaxng.org/ns/structure/1.0" xmlns:sch="http://www.ascc.net/xml/schematron">

<!-- zde je definován jmenný prostor pro xhtml, což je důležité pro adresování HTML elementů pomocí XPath. -->
<sch:ns prefix="html" uri="http://www.w3.org/1999/xhtml"/>

<!-- definice elementu form v Relax NG -->
<define name="form">
  <element name="form">
    <!-- začátek vnořeného Schematronu -->
    <sch:pattern name="nested.form">
      <sch:rule context="html:form">
        <sch:report test="descendant::html:form">
          Element form nesmí obsahovat žádné další elementy form na libovolné úrovni vnoření.
        </sch:report>
      </sch:rule>
    </sch:pattern>
    <!-- konec vnořeného Schematronu -->
    <ref name="form.attlist"/>
    <oneOrMore>
      <ref name="Block.class"/>
    </oneOrMore>
  </element>
</define>

</grammer>

<sch:rule context="html:*">
  <sch:report test="@id and @name and @id != @name">
    Atributy id a name musí mít stejnou hodnotu, pokud se vyskytují současně.
  </sch:report>
</sch:rule>

<define name="Color.datatype">
  <data type="string">
    <!-- regulární výraz pro kontrolu číselné formy -->
    <param name="pattern">[A-Za-z]+|#[0-9A-Fa-f]{3}|#[0-9A-Fa-f]{6}</param>
  </data>
  <!-- Následující Schematronový test kontroluje navíc jména barev, zda-li patří mezi 16 specifikovaných jmen. -->
  <sch:pattern name="color.datatype">
    <sch:rule context="html:font | html:basefont">
      <sch:report test="@color and not(starts-with(@color,'#'))
      and translate(@color, 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ') != 'BLACK'
      and translate(@color, 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ') != 'SILVER'

      ... všech 16 názvů barev ...

      and translate(@color, 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ') != 'TEAL'
      and translate(@color, 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ') != 'AQUA'
      ">
        Pouze 16 jmen barev je rozeznáváno:
        Black, Green, Silver, Lime, Gray, Olive, White,
        Yellow, Maroon, Navy, Red, Blue, Purple, Teal,
        Fuchsia and Aqua.
      </sch:report>
    </sch:rule>
  </sch:pattern>
</define>

<sch:pattern name="color.datatype">
  <sch:rule context="html:font | html:basefont">
    <sch:let name="color" value="translate(@color, 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')"/>
    <sch:report test="@color and not(starts-with(@color,'#')) and $color != 'BLACK' .... and $color != 'AQUA'">
      Pouze 16 jmen barev je rozeznáváno.
    </sch:report>
  </sch:rule>
</sch:pattern>

<sch:rule context="html:input">
  <sch:report test="((@type = 'radio' or @type = 'checkbox') and (not(@value) or string-length(@value) = 0))">
    Ovládací prvky radio a checkbox by měly mít specifikován neprázdný atribut value.
  </sch:report>
</sch:rule>

<sch:rule context="html:select">
  <sch:report test="not(@multiple) and count(html:option[@selected]) > 1">
    Elementy select bez atributu multiple nemohou mít více vybraných voleb.
  </sch:report>
</sch:rule>

<sch:rule context="html:button">
  <sch:report test="descendant::html:img[@usemap]">
    Obrázky vnořené v elementech button nesmí obsahovat atribut usemap.
  </sch:report>
</sch:rule>

Většina omezení vycházejících ze směrnic pro dostupnost obsahu webu je pro formalizaci příliš vágní. Směrnice 8, 13 a 14 se nepodařilo formalizovat vůbec. Ostatní směrnice jsou podchyceny částečně. Pro formalizaci omezení byl využit výlučně Schematron. Ten se na daný úkol ideálně hodí. Směrnice totiž nepopisují gramatiku nějakého jazyka, ale spíše jednotlivá omezení, která jsou na sobě v podstatě nezávislá. Navíc jsou tato omezení mnohdy strukturálně velmi komplexní a těžko by šla formalizovat v jiném jazyce. Schematron je vhodný i z toho důvodu, že v něm lze jednoduše vyjádřit modulární restrikce, a to pouhým zapsáním pravidel do příslušného modulu. Formalizace se skládá ze 43 pravidel sloučených do skupin podle směrnice, které se týkají. Každý test obsahuje i informaci o prioritě viz. [WCAG1]. Kompletní seznam všech formalizovaných pravidel je k nalezení v příslušném modulu definice v rámci prototypové aplikace. V následujících odstavcích si ukážeme pouze výběr nejzajímavějších z nich.

V první směrnici se testová pravidla zabývají hlavně tím, zda jsou vyplněny příslušné atributy týkající se slovních popisů jednotlivých elementů. Jedná se hlavně o atributy alt a longdesc. Tato pravidla jsou většinou jednoduchá a není třeba je zde podrobněji popisovat.

Formalizace druhé směrnice se snaží předejít tomu, aby byla barva popředí a pozadí shodná. To by znamenalo nečitelnost textu. Zajímavé by jistě bylo i kontrolovat kontrast barev. Zde by bylo problematické využít formát RGB, ve které jsou barvy v HTML zapisovány. Kontrast jednotlivých složek spektra je totiž různý. Na zelenou je lidské oko o něco citlivější, naopak modrá se nám jeví většinou tmavší. Tento problém mohou vyřešit správně zvolené váhy, které budou tyto rozdíly brát v úvahu. Ovšem hodnoty vah se mohou lišit například podle druhu zobrazovacího zařízení. Problematický by byl i samotný převod hexadecimálních čísel na decimální pomocí XPath 1.0, ke kterému by bylo nutné přistoupit. Z těchto důvodů se nakonec test kontrastu v definici nevyskytuje. Není to ovšem velká ztráta, protože barevné informace by stejně měly být zachyceny ve stylových definicích.

Třetí směrnice se zabývá tím, aby nebyly užívány prezentační nástroje HTML (ty mají být definovány ve stylech). Tato směrnice navíc doporučuje užívání relativních délek místo absolutních. Testy jsou opět velice jednoduché. Kontrolují se výskyty prezentačních atributů a výskyty znaků „*“ a „%“ v atributech určujících délku.

Čtvrtá směrnice mimo jiné vyžaduje, aby se u prvního použití zkratky v dokumentu vyskytoval titulek s jejím vysvětlením. Následující příklad ukazuje využití Schematronu pro formalizaci takového požadavku. Chyba je ohlášena pro každou zkratku, která neobsahuje atribut title a ani neexistuje stejná předchozí zkratka, která by tento atribut obsahovala.

<sch:rule context="html:abbr">
  <sch:report test="not(@title) and not(preceding::html:abbr[. = string(current())][@title])">
    WCAG 1.0 Checkpoint 4.2 (Priority 3) Titulek musí být uveden minimálně u prvního výskytu zkratky.
  </sch:report>                                                
</sch:rule>

Pátá směrnice se zabývá tabulkami. Formalizovány byly požadavky na popisky v tabulce a zkratky v záhlavích. Šestá směrnice vyžaduje využívání elementu <noframes> z důvodu kompatibility s prohlížeči, které nepodporují rámy. Toto omezení bylo jednoduše formalizováno. Ostatní omezení byla pro formalizaci již příliš vágní. Sedmá směrnice zakazuje nekontrolovatelné blikání a pohyb obsahu. Zde je kontrolována přítomnost proprietárních elementů <blink> a <marquee>, které mohou způsobovat právě takovéto chování obsahu. Tyto elementy jsou ovšem kontrolovány i tak, protože nejsou součástí definice jazyka HTML. Blikání a pohyb lze ovšem uskutečnit i některým skriptovacím jazykem. V tomto případě by byla kontrola mimořádně obtížná. Podobné je to i v případě požadavku, že by uživatel neměl být nekontrolovatelně přesměrováván na jiné dokumenty. V tomto případě lze testovat příslušný parametr v hlavičce dokumentu (viz. následující příklad), ovšem přesměrování lze realizovat i skriptovacími jazyky.

<sch:report test="translate(@http-equiv,'REFRESH','refresh') = 'refresh'">
  WCAG 1.0 Checkpoint 7.4 (Priorita 2) Uživatelé by neměli být nekontrolovatelně přesměrováváni.
</sch:report>

Jedním z požadavků deváté směrnice je i dostupnost ovládacích prvků nezávisle na použitém vstupním zařízení. Jednu z formalizací toho požadavku ukazuje následující příklad. Pokud je ošetřena událost vyvolaná počítačovou myší, měla by být ošetřena i odpovídající událost vyvolaná pomocí klávesnice.

<sch:rule context="*[@onclick]">
  <sch:assert test="@onkeypress">
    WCAG 1.0 Checkpoint 9.2 (Priorita 2) Pokud je na elementu <sch:name />
    ošetřena událost onclick měla by být ošetřena i událost onkeypress.
  </sch:assert>
</sch:rule>

Jedním z omezení desáté směrnice je i požadavek, aby nebyla používána tzv. „vyskakující“ okna (pop-ups). Formalizace tohoto požadavku jde za hranice HTML a testuje přítomnost příslušných metod v obsahu elementu <script> pro dva široce rozšířené skriptovací jazyky. Tento přístup má ovšem několik omezení. Netestuje skripty obsažené v událostech nebo v externích souborech a podporuje pouze dva skriptovací jazyky (HTML je nezávislé na užitém skriptovacím jazyce).

<sch:rule context="html:script">
  <sch:report test="@type = 'text/javascript' and contains(text(),'window.open(')">
    WCAG 1.0 Checkpoint 10.1 (Priorita 2) Není 
    doporučeno používat "vyskakovací" okna.
  </sch:report>
  <sch:report test="@type = 'text/vbscript' and contains(text(),'MsgBox')">
    WCAG 1.0 Checkpoint 10.1 (Priorita 2) Není 
    doporučeno používat "vyskakující" okna.
  </sch:report>
</sch:rule>

Formalizace jedenácté směrnice je zúžena na kontrolu všech potlačených elementů a atributů jazyka HTML. Testy jsou v zásadě triviální a kontrolují pouze výskyt těchto prvků. Kompletní seznam potlačených elementů a atributů je obsažen ve specifikaci HTML 4.01 viz. [HTML4].

Poslední směrnicí, kde se podařilo formalizovat některé z omezení, je dvanáctá směrnice. Dvanáctá směrnice požaduje, aby ovládací prvky využívaly explicitní popisky. V tomto případě by měl být element <input> obalen elementem <label>, jehož atribut for by se měl shodovat s příslušným atributem id tohoto ovládacího prvku. Tento požadavek je formalizován v následujícím příkladu.

<sch:rule context="html:input">
  <sch:report test="@type = 'text' and (not(parent::html:label)	or not(parent::html:label[@for]) or not(@id))">
    WCAG 1.0 Checkpoint 12.4 (Priorita 2) Ovládací prvky by měly mít explicitně asociovány popisky pomocí elementu label.
  </sch:report>
  <sch:report test="@type = 'text' and (string(parent::html:label/@for) != string(@id))">
    WCAG 1.0 Checkpoint 12.4 (Priorita 2) Atribut for elementu label musí odpovídat atributu id příslušného elementu input.
    "<sch:value-of select="string(@id)"/>" != "<sch:value-of select="string(parent::html:label/@for)"/>"
  </sch:report>
</sch:rule>

Dá se říci, že pomocí Relax NG a Schematronu lze formalizovat velkou část dodatečných omezení kladených na HTML dokumenty. Jde o ta omezení, která ze své podstaty nevyžadují lidský zásah a lidské posouzení. Exaktně definovaná a kvantifikovaná omezení, která nelze vyjádřit pomocí DTD, lze většinou dobře realizovat hlavně díky regulárním výrazům a jazyku XPath. Velký podíl na expresivitě moderních validačních jazyků mají právě tyto dvě technologie. Zlepšování záběru automatické validace HTML dokumentů může vést k většímu dodržování standardů. Automatická validace sice nikdy nenahradí lidský faktor a znalost smyslu a záměru omezení definovaných ve standardech, ale může výrazně urychlit validační proces a částečně ulehčit roli lidského činitele v něm.

Formalizace omezení kladených na jazyk ISO-HTML je nad rámec této práce.

V této kapitole se budeme zabývat návrhem a implementací prototypové aplikace pro validaci HTML dokumentů oproti definici navržené v předešlé kapitole. Popsána bude užitá technologie, jednotlivé komponenty, jejich vzájemná interakce a ukázka užití prototypové aplikace v praxi.

Prototypová aplikace (v textu někdy označována také pouze jako aplikace) je složena z několika vzájemně spolupracujících komponent. Cílem návrhu byla jednoduchá použitelnost aplikačního rozhraní, dobrá rozšiřitelnost aplikace a co největší konfigurovatelnost prostřednictvím konfiguračních souborů. Architekturu aplikace znázorňuje obrázek 4.1 – „Architektura prototypové aplikace“.

Obrázek 4.1. Architektura prototypové aplikace

Ústřední komponentou je ValidatorCollector. Ten nabízí jednotné a jednoduché validační rozhraní nezávisle na počtu užitých validačních komponent. Metoda pro zahájení validace je tak zavolána pouze jednou. ValidatorCollector se sám postará o správnou propagaci tohoto volání jednotlivým validačním komponentám. Navíc se stará o korektní agregaci všech chybových zpráv vzniklých při procesu validace.

Aplikace, které využívají rozhraní komponenty ValidatorCollector, poskytují validovaný dokument v podobě proudu dat (stream). Tento proud dat je však v průběhu validace opakovaně využíván jednotlivými validačními komponentami. Pro opakovaný přístup je tedy nutné data získaná z datového proudu vhodným způsobem uskladnit. Tento úkol plní komponenta DokumentStorage. Tato komponenta se také stará o filtrování obsahu dokumentů ještě před samotnou validací. K tomuto účelu využívá posloupnost filtrů organizovaných do určitého řetězce. Předchozí filtr vždy poskytuje filtrovaná data filtru následujícímu. Tento řetězec je sestavován dynamicky na základě konfiguračního souboru, který určuje nejen užité filtry, ale i jejich pořadí v řetězci.

Příkladem využití řetězce filtrů je filtr, který je součástí prototypové aplikace a který dovoluje konverzi dokumentů psaných v HTML na formát XHTML. Tento filtr tedy umožňuje validovat i HTML dokumenty pomocí validačních jazyků určených pro validaci XML. Předpokladem validace takových dokumentů je samozřejmě úspěšná konverze. Obrázek 4.2 – „Konverze HTML dokumentů do formátu XHTML“ ukazuje proces, který takovouto konverzi zajišťuje. Cílem tohoto procesu je garantovat validovatelnost dokumentů pomocí zvolených validačních jazyků.

Obrázek 4.2. Konverze HTML dokumentů do formátu XHTML

Po zahájení validace jsou postupně aktivovány jednotlivé validační komponenty a dochází k agregaci jejich výstupů. Validační komponenty využívají specifický druh konfigurace, který mapuje veřejný identifikátor dokumentů (publicId) na příslušnou definici, která má být pro daný typ dokumentu užita k validaci. Takovéto mapování je dále strukturováno do skupin podle validačního parametru, který je zadáván uživatelem. Tento parametr v zásadě dává uživateli prostor zvolit si režim validace. Typicky je možné vybrat standard, proti kterému je vstupní dokument validován. Následující příklad ukazuje takovouto konfiguraci.

<option name="xhtml" desc="W3C XHTML 1.0 / HTML 4.01">
  <entry default="true" schemaPath="/conf/schema/rng/xhtml-transitional.rng" />
  <entry publicId="-//W3C//DTD XHTML 1.0 Strict//EN" schemaPath="/conf/schema/rng/xhtml-strict.rng" />
  <entry publicId="-//W3C//DTD XHTML 1.0 Transitional//EN" schemaPath="/conf/schema/rng/xhtml-transitional.rng" />
  <entry publicId="-//W3C//DTD XHTML 1.0 Frameset//EN" schemaPath="/conf/schema/rng/xhtml-frameset.rng" />
  <entry publicId="-//W3C//DTD HTML 4.01//EN" schemaPath="/conf/schema/rng/xhtml-strict.rng" />				
  <entry publicId="-//W3C//DTD HTML 4.01 Strict//EN" schemaPath="/conf/schema/rng/xhtml-strict.rng" />
  <entry publicId="-//W3C//DTD HTML 4.01 Transitional//EN" schemaPath="/conf/schema/rng/xhtml-transitional.rng" />
  <entry publicId="-//W3C//DTD HTML 4.01 Frameset//EN" schemaPath="/conf/schema/rng/xhtml-frameset.rng" />
</option>
<option name="xhtml+wcag" desc="WAI WCAG 1.0 and W3C XHTML 1.0 / HTML 4.01">
  <entry default="true" schemaPath="/conf/schema/rng/xhtml-transitional-wcag.rng" />
  <entry publicId="-//W3C//DTD XHTML 1.0//EN" schemaPath="/conf/schema/rng/xhtml-strict-wcag.rng" />
  <entry publicId="-//W3C//DTD XHTML 1.0 Strict//EN" schemaPath="/conf/schema/rng/xhtml-strict-wcag.rng" />
  <entry publicId="-//W3C//DTD XHTML 1.0 Transitional//EN" schemaPath="/conf/schema/rng/xhtml-transitional-wcag.rng" />
  <entry publicId="-//W3C//DTD XHTML 1.0 Frameset//EN" schemaPath="/conf/schema/rng/xhtml-frameset-wcag.rng" />
  <entry publicId="-//W3C//DTD HTML 4.01//EN" schemaPath="/conf/schema/rng/xhtml-strict-wcag.rng" />
  <entry publicId="-//W3C//DTD HTML 4.01 Strict//EN" schemaPath="/conf/schema/rng/xhtml-strict-wcag.rng" />
  <entry publicId="-//W3C//DTD HTML 4.01 Transitional//EN" schemaPath="/conf/schema/rng/xhtml-transitional-wcag.rng" />
  <entry publicId="-//W3C//DTD HTML 4.01 Frameset//EN" schemaPath="/conf/schema/rng/xhtml-frameset-wcag.rng" />
</option>

První validační komponentou je tzv. JARV (Java Application Programming Interface for RELAX Verifiers) validátor. JARV je validační rozhranní, které je nezávislé na použité implementaci validátoru. Velkou výhodou využití takového rozhraní je možnost validovat s pomocí téměř libovolných validačních jazyků bez nutnosti změny kódu aplikace. Stačí změnit konfiguraci v některém z konfiguračních souborů. Toto rozhraní tedy dává validační komponentě možnost jednoduchého rozšíření. Ve stávající aplikaci je ovšem využívána pouze validace oproti definicím zapsaným v Relax NG. V případě potřeby je ovšem možné stejnou validační komponentu jednoduše použít pro validaci definic zapsaných v XML Schema nebo v některém jiném podporovaném validačním jazyce.

Další validační komponentou je komponenta umožňující validaci vnořeného Schematronu. Návrh validační komponenty je opět velmi otevřený. Pouhou změnou konfiguračních souborů a napsáním příslušných transformačních stylů je možné uskutečnit validaci Schematronu vnořeného v některém jiném validačním jazyce, než je použité Relax NG. Validace je v tomto případě v podstatě sérií čtyř po sobě jdoucích XSLT transformací. Průběh těchto transformací znázorňuje obrázek 4.3 – „Transformační proces při validaci vnořeného Schematronu“.

Obrázek 4.3. Transformační proces při validaci vnořeného Schematronu

První transformační proces transformuje vstup, což je v našem případě definice v jazyce Relax NG s vnořenými Schematronovými testy, na čistý Schematron, který je získáván ze všech zahrnutých modulů definice. Schematronová definice je dále transformována na Schematronový transformační styl. Ten je již přímo možné použít k transformaci validovaného dokumentu, jejíž výsledkem by byla příslušná chybová hlášení. Z praktických důvodů je však lepší zahrnout do takových hlášení ještě čísla řádek, na kterých došlo ve validovaném dokumentu k chybám. Tato informace výrazně zvyšuje použitelnost validačního výstupu a urychluje odstraňování chyb. Získání čísel řádku zdrojového dokumentu v průběhu transformace ovšem nepatří mezi standardní funkce transformačních nástrojů. Pro implementaci této validační komponenty byl vybrán transformační nástroj Saxon, který obsahuje proprietární rozšíření pro zjištění čísel řádků. Další transformační proces tedy přidává do Schematronového transformačního stylu speciální značku, která je v průběhu transformace rozeznána Saxonem a nahrazena ve výstupu příslušným číslem řádku.

Do posledního transformačního procesu vstupuje konečně samotný validovaný dokument. Ten je transformován pomocí Schematronového stylu, který jsme získali předešlými kroky. Výsledkem jsou pak konkrétní chybové zprávy opatřené i číslem řádku, na kterém byla chyba objevena. Tyto zprávy je možné spolu se zprávami z ostatních validačních komponent nakonec zobrazit koncovým uživatelům aplikace.

Všechny validační komponenty jsou potomky abstraktní validační třídy. Tato třída v sobě zahrnuje společnou funkcionalitu validačních komponent. Tato funkcionalita se týká i správy validačních definic. Je zřejmé, že před samotnou validací je třeba validační definice náležitě připravit. Tato příprava je relativně náročná na zdroje. Například v případě validátoru vnořeného Schematronu obnáší tři transformační procesy. Proto je dobré připravené definice uchovávat k opětovnému využití. Tuto službu zajišťuje právě abstraktní validační třída. Její potomci implementují pouze specifické způsoby přípravy definice a samotný validační proces, který je také specifický pro každou validační komponentu.

Specifický je i způsob mapování veřejných identifikátorů na definice. Každá validační komponenta tak má možnost využívat vlastní mechanizmy k tomuto účelu. Lze například využít jiný formát mapovacího konfiguračního souboru a nebo třeba používat vždy stejnou validační definici bez ohledu na veřejný identifikátor dokumentu.

Prototypová aplikace nabízí uživateli dva základní přístupy k validační funkcionalitě. První z nich je validační aplikace ovládaná z příkazové řádky. Ta umožňuje validovat jednotlivé soubory, celé adresáře nebo zdroje určené pomocí URL. Příkladem využití takové aplikace je validace všech testových úloh, které jsou součástí prototypové aplikace. Následující příklad ukazuje nápovědu validační aplikace ovládané z příkazové řádky. Lze si tak udělat obrázek o možnostech jejího použití.

CommandLineValidator - použití:
Povinné parametry:
  -o <validační parametr>  validační parametr
  -f | -r | -w             alespoň jedna z následujících
                           voleb musí být specifikována: 
                           kořenový adresář, jednotlivý soubor
                           nebo zdroj identifikovaný pomocí URL
Nepovinné parametry:
  -f <jednotlivý soubor>   validuje jednotlivý soubor, více souborů 
                           může být specifikováno opakováním tohoto 
                           parametru
  -w <URL>                 zdroj identifikovaný pomocí URL, více zdrojů
                           lze specifikovat opakováním tohoto parametru
  -r <kořenový adresář>    absolutní cesta ke kořenovému adresáři
  -d <list podadresářů>    tyto adresáře (relativní ke kořenovému)
                           jsou zahrnuty resp. vyjmuty z validace
  -i                       adresáře definované parametrem -d jsou
                           zahrnuty do validace
  -e (implicitně platí)    adresáře definované parametrem -d jsou
                           vyjmuty z validace
  -help                    vypíše tuto nápovědu
  -s                       tichý výstup, vypíše pouze testové úlohy,
                           které mají být validní resp. chybné a ve
                           skutečnosti platí opak

Pro snadnější ovládání obsahuje aplikace několik předdefinovaných konfigurací. Dvě z nich slouží jako automatizovaná podpora testové fáze vývojového cyklu viz. sekce „Metodika zápisu formalizací – vývojový cyklus“. První z nich postupně otestuje všechny testové úlohy v adresáři new, kde jsou vyvíjeny nové testové úlohy, které zachycují nějaký nově implementovaný jev. Teprve potom co považujeme implementaci tohoto jevu za dostatečně stabilní a všechny testové úlohy jsou úspěšné, můžeme přistoupit k druhé předdefinované konfiguraci. Ta je nastavena tak, aby validovala všechny testové úlohy, které jsou relevantní pro danou definici. Je nutné zajistit, aby nově naimplementovaný prvek nenarušil některá již implementovaná omezení. Pokud zjistíme nějaké nové nesrovnalosti, je třeba příslušným způsobem opravit definici. Celý proces opakujeme tak dlouho, dokud nejsou všechny testové úlohy v pořádku. Poté je možné zařadit nové testové úlohy do příslušné struktury mezi ostatní. Tento proces umožňuje plynulou implementaci a pomáhá udržovat definici konzistentní v celém průběhu vývojového cyklu.

Další možností přístupu k validační funkcionalitě je webové rozhraní. Zatímco příkazová řádka slouží spíše k účelům testování a správy validačních definic, webové rozhraní je určeno k použití skutečným autorům HTML dokumentů. Ti mají možnost prostřednictvím webového formuláře zadat URL svého dokumentu a příslušný validační parametr. Výstupem je potom seznam chybových zpráv. Rozhraní se tedy používá velice jednoduše a intuitivně.

Obrázek 4.4 – „Využití validační aplikace prostřednictvím prohlížeče Firefox 1.0.2“ ukazuje validační výstup pro hlavní stránku webového vyhledávače Google. Z výstupu je patrné, že nebyl rozpoznán typ dokumentu (ten není ve zdrojové stránce vůbec specifikován), a proto byl použit implicitní typ. Zdroj byl tedy konvertován na XHTML a posléze validován. Zbytek viditelného výstupu jsou validační chyby.

Obrázek 4.4. Využití validační aplikace prostřednictvím prohlížeče Firefox 1.0.2

Na obrázku 4.5 – „Využití validační aplikace prostřednictvím prohlížeče Internet Explorer 6.0“ vidíme validační výstup pro hlavní stránku magazínu Interval.cz. Uživatelem byla zvolena také validace směrnic WCAG. Stránky jsou psány v XHTML a konverze tedy v tomto případě nebyla nutná.

Obrázek 4.5. Využití validační aplikace prostřednictvím prohlížeče Internet Explorer 6.0

Na obrázku 4.6 – „Stránky abclinux.cz validované v textovém prohlížeči Lynx 2.8.5“ vidíme validační výstup v textovém prohlížeči Lynx. I přestože se jedná o dokument v jazyce HTML, byl typ tohoto dokumentu správně rozeznán a byla provedena konverze na XHTML.

Obrázek 4.6. Stránky abclinux.cz validované v textovém prohlížeči Lynx 2.8.5

Na závěr je připravena ukázka výstupu validace samotné hlavní stránky prototypové validační aplikace viz. obrázek 4.7 – „Bezchybný výstup“. Jsou validovány i směrnice WCAG.

Obrázek 4.7. Bezchybný výstup

Prototypová aplikace je napsána s využitím programovacího jazyka Java 1.4. Pro běh aplikace je nutná celá řada knihoven, které jsou součástí distribuce této aplikace. Jedná se například o výše popsané validační rozhraní JARV 1.4. Toto rozhraní dále používá validační nástroj Sun Multi-Schema Validator (MSV) 1.2, který podporuje validaci s využitím celé řady validačních jazyků (Relax NG a XML Schema nevyjímaje). XSLT transformace zajišťuje Saxon 6.5.3.

O konverzi HTML na XHTML se stará knihovna Tag Soupe. Jedná se o relativně malý a velice mladý projekt, jehož cílem je zpřístupnit HTML dokumenty XML nástrojům. Na rozdíl od jiných podobných knihoven se vůbec nezabývá zkrášlováním HTML zdroje. Jeho jediným cílem je zajistit výstup ve správně formovaném XML/XHTML, které nebude problematické pro další zpracování. Prioritou konverzního procesu je vyprodukovat nějaký použitelný výstup nezávisle na chybách, ke kterým mohlo v průběhu konverze dojít. Tento přístup je ideální pro využití v prototypové aplikaci, protože vždy dovoluje doručit uživatelům informace o chybách v jejich dokumentech. Může se ovšem stát, že některé zásadní chyby nebudou odhaleny. Protože by jejich přítomnost znemožňovala další zpracování, jsou tyto chyby knihovnou Tag Soupe opraveny, a neobjeví se tak v chybovém výstupu.

Aplikace dále využívá distribuční nástroj ANT od Apache Foundation. Ten umožňuje automatizovaný výkon úloh, které jsou nezbytné pro provoz aplikace. Definice těchto úloh je součástí aplikace a je zapsána v konfiguračních souborech psaných v XML. K základním úlohám patří kompilace zdrojových kódů, generování dokumentace a instalace webového rozhraní na příslušný aplikační server (aplikace byla testována na serveru Tomcat 5.0.14). Další úlohy potom umožňují automatizované provádění testových úloh s různými parametry a nebo validaci jednotlivých HTML dokumentů z příkazové řádky.

Další informace o implementaci prototypové aplikace lze nalézt v dokumentačním adresáři doc v adresářové struktuře přiložené validační aplikace. Tento adresář obsahuje (kromě textu této práce) stručnou dokumentaci jednotlivých javovských tříd. Tato dokumentace je vygenerována pomocí standardního dokumentačního nástroje javadoc, který je součástí vývojového balíku programovacího jazyka Java.