• No results found

ONLINE APLIKACE PRO VALIDACI XML

N/A
N/A
Protected

Academic year: 2022

Share "ONLINE APLIKACE PRO VALIDACI XML"

Copied!
44
0
0

Loading.... (view fulltext now)

Full text

(1)

ONLINE APLIKACE PRO VALIDACI XML

Bakalářská práce

Studijní program: B2646 – Informační technologie Studijní obor: 1802R007 – Informační technologie Autor práce: Martin Kubíček

Vedoucí práce: Ing. Mojmír Volf

(2)
(3)
(4)

Prohlášení

Byl(a) jsem seznámen(a) s tím, že na mou bakalářskou práci se plně vztahuje zákon č. 121/2000 Sb. o právu autorském, zejména § 60 – školní dílo.

Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé bakalářské práce pro vnitřní potřebu TUL.

Užiji-li bakalářskou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto případě má TUL právo ode mne požadovat úhra- du nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.

Bakalářskou práci jsem vypracoval(a) samostatně s použitím uvedené literatury a na základě konzultací s vedoucím bakalářské práce a konzultantem.

Současně čestně prohlašuji, že tištěná verze práce se shoduje s elektronickou verzí, vloženou do IS STAG.

Datum:

Podpis:

(5)

Abstrakt

Tato bakalářská práce rozebírá základy XML validace a soustředí se na její uplatnění v online prostředí. V kapitole XML dokumenty a schémata je popsána XML technologie a jsou roze- brány dva nejrozšířenější typy schémat XML Schema a DTD. Kapitola dále popisuje několik způsobů, jak lze XML dokumenty číst a zpracovávat.

Kapitola Webová aplikace rozebírá vytvořený webový XML validátor, jeho postup vývoje, popis uživatelského rozhraní a vnitřních metod. Dále je ukázáno a popsáno, jak tento validátor validuje XML dokumenty v praxi a jaké dokáže poskytnout výsledky validace uživateli. Popis webové aplikace je doplněn o doprovodné obrázky.

V kapitole Srovnání s ostatními validátory jsou pak porovnány tři ostatní validační služby nalezené na internetu. Kapitola obsahuje podrobný popis těchto služeb a porovnání jejich funkčnosti s vytvořenou webovou aplikací. Závěr pak obsahuje shrnutí dosažených výsledků a získaných znalostí.

Klíčová slova:

XML, XML Schema, XSD, validace, webová aplikace

Abstract

This thesis analyses the basics of XML validation and focuses on its use in online environ- ment. Chapter XML dokumenty a schémata describes XML technology and the two most widespread XML schemes called XML Schema and DTD. This chapter also describes several ways of how to read and process XML documents.

Chapter Webová aplikace describes a created online application, its development, user inter- face and inner algorithms. It also illustrates how this online application performs a validation and what validation results it can show to the user. The description features attached screen- shots of the application.

Chapter Srovnání s ostatními validátory compares the three other validating services available on the internet. This chapter contains detailed description of these services and compares their functionality with the created application. The conclusion then sums up the achieved results and the acquired knowledge.

Key words:

XML, XML Schema, XSD, validation, web application

(6)

Obsah

1 Úvod ...7

1.1 K čemu je dobrá validace? ...7

1.2 Motivace ...8

2 Cíl práce ...9

3 XML dokumenty a schémata ... 10

3.1 Typy XML schémat ... 11

3.1.1 DTD ... 11

3.1.2 XML Schema ... 12

3.2 Jak lze pracovat s XML dokumenty ... 15

3.2.1 Push model (SAX Parser) ... 15

3.2.2 Pull model ... 15

3.2.3 DOM Parser ... 16

3.3 Podpora XML validace ... 16

3.3.1 PHP ... 17

3.3.2 C# ... 17

3.3.3 Java SE ... 17

4 Webová aplikace... 18

4.1 Vývoj aplikace ... 18

4.2 Popis uživatelského rozhraní ... 19

4.2.1 Vstupní část... 20

4.2.2 Výstupní část ... 22

4.3 Popis vnitřních metod a algoritmů ... 23

4.3.1 ValidationSettings ... 23

4.3.2 InputFile ... 24

4.3.3 Btn_validate_Click ... 25

4.3.4 Process_upload... 25

4.3.5 Process_text_input ... 26

4.3.6 Process_URL ... 27

4.3.7 Validate_inline ... 28

4.3.8 Validate_extern ... 29

4.3.9 Validation_callback ... 29

4.3.10 Get_lines ... 30

4.3.11 Check_URL_status... 30

(7)

5 Ukázka webové aplikace v praxi ... 31

5.1 Validní XML dokument ... 31

5.2 Nevalidní XML dokument ... 31

5.3 Validní XML dokument s varováním... 33

5.4 Non well-formed XML dokument nebo XSD schéma ... 34

5.5 Validování XML dokumentu s vnořeným (inline) XSD schématem ... 35

6 Srovnání s ostatními validátory ... 36

6.1 W3Schools XML Validator ... 36

6.2 The W3C Markup Validation Service ... 37

6.3 Www.xmlvalidation.com ... 38

7 Závěr ... 40

Seznam použité literatury ... 41

Příloha ... 43

(8)

1 Úvod

Lidé už stovky let produkují ohromné množství psaného materiálu – knihy, seznamy, zprávy, dokumenty. S postupně rozvíjející se technologií začaly růst i nároky na jednotlivé členění a zpracování těchto textů. V dokumentech začalo být zapotřebí odlišit jednotlivé kapitoly, nadpisy, odstavce, různé seznamy obsahovaly odlišné informace a data, zprávy musely být psané v určených formátech. Ve dvacátém století s příchodem počítačů a informačních systé- mů začala být tato potřeba enormní.

Představme si například vývojáře, který si chce v elektronické formě vytvořit telefonní se- znam a udržovat ho. Jistě by rád měl svůj seznam telefonních čísel vytvořen tak, aby v něm šlo snadno vyčíst co je telefonní číslo, co jméno, adresa a další věci. Také by určitě chtěl mít možnost jednoduchého vložení nového záznamu či jeho editaci, aby svůj seznam čísel mohl udržovat aktuální. V posledních letech se široce rozšířil jazyk XML, který je nejen pro tako- véto použití velmi vhodný.

XML je značkovací jazyk. Značkou se rozumí slovo ohraničené špičatými závorkami „<“

a „>“. V XML dokumentu tedy může vypadat označkovaný text například takto: <rok>

1990</rok>. Tento zápis znamená, že mezi značkami <rok> a </rok> se bude nacházet čí- selně zapsaný rok. Tyto značky mohou být libovolné a mohou ohraničovat a určovat jakýko- liv typ informace, který chceme uchovat.

1.1 K čemu je dobrá validace?

Pokud si znova představíme našeho vývojáře, který si vytvořil pomocí XML svůj telefonní seznam, pravděpodobně ho bude chtít nějakým způsobem použít v počítačovém programu nebo systému. Může tedy napsat implementaci pro práci se svým XML dokumentem se struk- turou, co si sám určil. Jenže pak může nastat situace, kdy se daný XML dokument stane neva- lidním – bude obsahovat špatně vnořené značky, nepovolené znaky nebo jeho vnitřní struktura nebude odpovídat požadavkům aplikace. Nebo náš vývojář zjistí, že potřebuje tento XML dokument sdílet mezi dvěma různými systémy a zajistit tak vzájemnou kompatibilitu.

Tento problém řeší takzvaná XML schémata. Tyto schémata určují pravidla pro přípustnou vnitřní strukturu značek v XML dokumentu a dá se podle nich XML dokument poté valido- vat. Validace nám tedy zajistí, že XML dokument bude mít požadovanou vnitřní strukturu značek, a bude tak splňovat všechny podmínky, aby byl kompatibilní se systémy, kde bude

(9)

využíván. U těchto systémů pak stačí, aby zpracovávaly XML dokumenty na základě pravidel definovaných v daném XML schématu.

1.2 Motivace

V dnešní době se mnoho desktopových aplikací přesouvá do internetových vod, protože je internet dostupný prakticky všude a kdykoliv, a odpadá tak nutnost mít u sebe kopii progra- mu. S webovými aplikacemi můžete kdekoliv prostřednictvím internetového prohlížeče pro- vádět spoustu věcí. Můžete třeba editovat textové dokumenty, kreslit, upravovat fotky, hrát hry, ale i validovat nejrůznější soubory.

Ani validace XML dokumentů prostřednictvím webové aplikace tedy není výjimkou, a tímto směrem se v budoucnu budou jistě ubírat i další původně desktopové aplikace. Na internetu se v tuto chvíli již nalézají řešení pro validaci XML dokumentů, ovšem často bývají dost omeze- né. Některé validátory nejsou skutečnými validátory, ale umožňují pouze tzv. well-formed kontrolu, neboli kontrolu syntaxe dokumentu, nikoliv validaci dokumentu podle schématu.

Jiné aplikace zase validaci podle schématu podporují, ale chybí jim propracované uživatelské rozhraní, které by uživatelům poskytlo větší svobodu v možnostech, jak na server nahrát XML dokument k validaci.

(10)

2 Cíl práce

Cílem této bakalářské práce je seznámení se s technologií XML a se způsoby, jak XML do- kumenty validovat pomocí schémat v online prostředí. Dále by měla být vytvořena webová aplikace umožňující validaci libovolných uživatelských XML dokumentů pomocí schémat typu XML Schema.

Aplikace může být vytvořena prostřednictvím libovolné webové technologie a v jakémkoliv programovacím jazyce. Aplikace nebude nijak řešit samotný obsah XML dokumentů, půjde pouze o jejich validaci. Aplikace bude schopná ověřit jakýkoliv uživatelský XML dokument, a to zda má správnou syntaxi (neboli zda je well-formed) a zda je validní oproti dodanému schématu.

Práce se zaměřuje pouze na validaci XML dokumentů pomocí schématu typu XML Schema, nebude tedy umět validovat schémata typu DTD nebo jiné. Existují další jazyky pro psaní schémat, jako například Relax-NG nebo Schematron. Tyto jazyky sice přinášejí některé další vylepšení oproti jazyku XML Schema, nicméně jejich hlavní problém spočívá v tom, že nej- sou téměř vůbec rozšířeny. Jsou to perspektivní technologie, které se ale nachází na začátku svého vývoje a zatím nemají velké uplatnění. Jazyk DTD sice rozšířen je, nicméně pro svou jednoduchost je mnohonásobně překonán nejpoužívanějším jazykem XML Schema.

Jazyk XML Schema je tedy v dnešní době tou nejlepší volbou pro psaní schémat k XML do- kumentům. Tento jazyk je navíc de facto standard, je vytvořen pod křídly organizace World Wide Web Consortium. Je také ve velkém podporován IT průmyslem. Z těchto všech důvodů tedy bude vytvořená webová aplikace validovat pouze pomocí schémat v jazyce XML Schema.

Aplikace bude mít grafické uživatelské rozhraní, zobrazitelné ve standardním moderním we- bovém prohlížeči, které bude umožňovat nahrání XML dokumentů a schémat vícero způsoby.

Výsledek validace pak bude uživateli předložen v podobě textového výpisu a bude obohacen o přesná čísla řádků, kde se případná chyba v kódu nachází. Taktéž bude k chybě vypsán i kus samotného XML kódu, aby uživatel mohl tuto případnou chybu vidět v dokumentu i bez jeho otevření v textovém editoru nebo jiném programu.

(11)

3 XML dokumenty a schémata

Jak již bylo řečeno, XML je značkovací jazyk. Zkratka XML znamená eXtensible Markup Language [3]. Pomocí tohoto jazyka lze snadno a efektivně označkovat libovolná data, a to tak, že se ve struktuře XML dokumentu vyzná i člověk. Specifikace XML nedefinuje, jaké značky se mají konkrétně používat, ale definuje pouze způsob zápisu těchto značek. Uživatel si pak může vytvořit libovolné značky pro svojí potřebu, a ty pak zapisovat ve formátu defi- novaném XML specifikací.

Na obrázku 3.1 můžete vidět strukturu XML dokumentu. Každý dokument by měl začínat deklarací verze XML a použitou znakovou sadou. Dále může následovat deklarace schématu dokumentu, která se ale na obrázku 3.1 nevyskytuje. Pak XML dokument vždy obsahuje je- den kořenový element, a v něm je pak vnořen libovolný počet dalších elementů. Každý ne- prázdný element je párový, a musí být tedy ukončen. Pokud je element prázdný (neohraničuje svými značkami žádnou informaci), ukončovací znak „/“ se může napsat na konec počáteční značky elementu, a ukončovací značka se poté nepíše.

Elementy mohou obsahovat další vnořené elementy, textové řetězce a atributy. Na obrázku 3.1 obsahuje element1 pouze atribut s názvem atribut hodnotu hodnota1, element neobsahuje nic jiného, a proto je na konec elementu před ukončovací závorku > umístěno ukončovací lomítko. Element element2 pak obsahuje pouze textový řetězec, který je uzavřen mezi počá- teční a ukončovací značkou elementu.

Struktura XML dokumentu tedy záleží pouze na uživateli. Díky této všestrannosti se XML prosadilo v mnoha různých oborech, kde si každý může strukturu XML dokumentu upravit podle svých potřeb.

<?xml version="1.0" encoding="windows-1250"?>

<kořenovýElement>

<element>

<element1 atribut="hodnota1"/>

<element2>textový řetězec</element>

</element>

<element>

<element1 atribut="hodnota2"/>

<element2>jiný textový řetězec</element>

</element>

</kořenovýElement>

Obrázek 3.1: Ukázka XML dokumentu

(12)

3.1 Typy XML schémat

V praxi je ze zmíněných důvodů výhodné mít vymezena pravidla pro strukturu XML doku- mentu. XML nachází využití v oborech s odlišnými požadavky, a proto je žádoucí, aby bylo možno specifikovat určitá pravidla, která musí XML dokumenty splnit, aby mohly být zpra- covány daným systémem.

Existuje několik způsobů, jak takové schéma zapsat a vytvořit. Jeden ze způsobů je použít jazyk DTD, který ale dnes přestává stačit díky své jednoduchosti [1]. Pro složitější aplikace je lepší využít jazyk XML Schema, často označovaný zkratkou XSD, který poskytuje mnohem větší vyjadřovací sílu oproti jazyku DTD [1]. Existují i další jazyky pro popis XML struktury, které již ale nejsou tak rozšířeny jako tyto dva, a proto nebudou dále rozebírány. Patří mezi ně například Relax NG a Schematron.

3.1.1 DTD

XML dokument může být popsán pomocí jazyka pro Definici Typu Dokumentu, neboli DTD [2]. DTD je jednoduchý způsob, jak navrhnout sadu pravidel pro strukturu XML dokumentu.

Tento jazyk je přímo součástí specifikace XML [1]. Pomocí něj lze určit, jaké elementy musí dokument obsahovat, v jakém mají být pořadí, jak mají být v sobě vnořeny, zda musí obsaho- vat hodnotu, jaké mají atributy a dokáže určit jejich četnost [1]. DTD schéma může být ulože- no přímo uvnitř XML dokumentu, nebo může být v samostatném souboru s příponou .dtd.

V dokumentu je pak na DTD schéma uveden odkaz [1].

Obrázek 3.2: Ukázka zápisu schématu v jazyce DTD

Na obrázku 3.2 lze vidět zápis pravidel v jazyce DTD. Tento zápis určuje, že XML dokument musí obsahovat jeden kořenový element list, který může obsahovat libovolný počet elementů entry. Každý element entry pak musí obsahovat jeden element name, jeden nebo více elemen- tů number a jeden element address. Dále je u elementů name a number specifikován jejich obsah prostřednictvím zápisu #PCDATA, který znamená, že mohou obsahovat libovolná zna- ková data. Element address pak musí obsahovat vnořené elementy street, streetNo a city

<!ELEMENT list (entry*)>

<!ELEMENT entry (name, number+, address)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT number (#PCDATA)>

<!ELEMENT address (street, streetNo, city, country?)>

<!ELEMENT street (#PCDATA)>

<!ELEMENT streetNo (#PCDATA)>

<!ELEMENT city (#PCDATA)>

<!ELEMENT country (#PCDATA)>

(13)

a může obsahovat element country. Elementy street, streetNo, city, i country pak mohou ob- sahovat znaková data.

Obrázek 3.3: Ukázka XML dokumentu s externím DTD schématem

Obrázek 3.3 pak představuje XML dokument validní podle DTD schématu z obrázku 3.2. Jak je vidět, na druhém řádku dokumentu je umístěn odkaz na externí DTD schéma, které je lo- kálně uloženo v souboru phonebook.dtd. Struktura dokumentu pak odpovídá pravidlům za- psaných ve schématu, takže se dá tento XML dokument považovat za validní.

Hlavní problém DTD spočívá v nemožnosti podrobnějšího určení obsahu jednotlivých ele- mentů. Uživatel si nemůže například určit, že chce, aby se v elementu number mohlo vysky- tovat pouze číslo, a to o délce devíti znaků. Může pouze určit, že zde mohou být znaková data. Tudíž se zde klidně může nacházet textový řetězec a z hlediska validace bude vše v pořádku. Dále je prakticky nemožné rozumným způsobem určit maximální počet výskytů nějakého elementu. Pomocí regulárních výrazů lze pouze určit, zda se daný element může vyskytovat jednou, vícekrát nebo v libovolném počtu. Nejen toto, ale i další omezení řeší ja- zyk XML Schema.

3.1.2 XML Schema

Dalším jazykem pro popis XML dat je jazyk XML Schema. Tento jazyk byl vytvořen konsor- ciem W3C jako odpověď na nedostatečnou vyjadřovací sílu jazyka DTD [1]. Pokud totiž uži- vatel chce popsat strukturu XML dokumentu velmi přesně, jazyk DTD je pro tento účel nedostatečný. XML Schema má poněkud nešťastný název, pokud se chceme bavit o schéma- tech pro XML dokumenty, a proto se vžila zkratka XSD, která jej označuje. XSD znamená

„XML Schema Definition“ [1].

XML Schema poskytuje daleko mocnější nástroje pro popis pravidel XML dokumentů. XML Schema na rozdíl od DTD již umožňuje používání datových typů pro určení obsahu jednotli-

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

<!DOCTYPE PHONEBOOK SYSTEM "phonebook.dtd">

<list>

<entry>

<name>Adam John</name>

<number>420123456</number>

<number>776123456</number>

<address>

<street>Prazska</street>

<streetNo>42</streetNo>

<city>Praha 1</city>

</address>

</entry>

</list>

(14)

vých elementů. Lze si též definovat vlastní datové typy. Navíc schéma popsané jazykem XML Schema je samo o sobě XML dokumentem, protože jazyk XML Schema z jazyka XML vychází [1]. Díky tomu lze schémata typu XML Schema zpracovávat a validovat se standard- ními XML nástroji.

Na obrázku 3.4 lze vidět zápis pravidel v jazyce XML Schema. Na první pohled je to zápis delší a složitější, než u DTD, ale umožňuje nám přesněji definovat pravidla. Vzhledem k to- mu, že se jedná taktéž o XML dokument, začíná schéma deklarací verze XML a použitým kódováním. Následuje kořenový element schema, ve kterém je pomocí atributu xmlns specifi- kován jmenný prostor jazyka XML Schema. Za atributem xmlns je dvojtečkou oddělen prefix, pomocí kterého se ve zbytku schématu označují veškeré značky spadající do tohoto jmenného prostoru.

Obrázek 3.4: Ukázka schématu zapsaného v jazyce XML Schema

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

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:simpleType name="phoneNumber">

<xsd:restriction base="xsd:string">

<xsd:pattern value="\d{9}"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="streetNumber">

<xsd:restriction base="xsd:integer">

<xsd:totalDigits value="4"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name="adressType">

<xsd:sequence>

<xsd:element name="street" type="xsd:string"/>

<xsd:element name="streetNo" type="streetNumber"/>

<xsd:element name="city" type="xsd:string"/>

<xsd:element name="country" type="xsd:string" minOccurs="0"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="entryType">

<xsd:sequence>

<xsd:element name="name" type="xsd:string"/>

<xsd:element name="number" type="phoneNumber" maxOccurs="3"/>

<xsd:element name="address" type="adressType"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="listType">

<xsd:sequence minOccurs="0" maxOccurs="unbounded">

<xsd:element name="entry" type="entryType"/>

</xsd:sequence>

</xsd:complexType>

<xsd:element name="list" type="listType"/>

</xsd:schema>

(15)

Uvnitř kořenového elementu schema je nejprve pomocí elementu simpleType vytvořen uživa- telsky definovaný datový typ s názvem phoneNumber. Ten obsahuje element restriction s atributem base, který určuje, ze kterého datového typu se uživatelský datový typ odvozuje.

V tomto případě je to datový typ string, který je definován ve specifikaci jazyka XML Schema. Pak je vnořen ještě element pattern, kde je pomocí regulárních výrazů specifikován požadovaný tvar dat, který může element s datovým typem phoneNumber uchovávat. Níže je vytvořen uživatelský datový typ s názvem streetNumber, který tentokrát vychází z datového typu integer a elementem totalDigits je pak určena maximální délka čísla na 4 cifry.

Následují tři elementy complexType, které umožňují definování složených uživatelských da- tových typů. První se jmenuje addressType a obsahuje čtyři vnořené elementy street, street- No, city a country. Elementy street, city a country jsou typu string, element streetNo má určen datový typ streetNumber. Element country má pak pomocí atributu minOccurs nastaven mi- nimální počet výskytů na žádný, nemusí se tedy v XML dokumentu vyskytovat. Další element complexType s názvem entryType, který definuje uživatelský datový typ, se nese ve stejném duchu jako předchozí, a poslední uživatelský složený datový typ listType se odlišuje hlavně atributem maxOccurs s hodnotou unbounded, která určuje, že element s tímto uživatelským datovým typem se může v XML dokumentu vyskytovat v neomezeném počtu.

Jak je vidět na obrázku 3.5, samotný XML dokument, který je validní podle schématu v jazy- ce XML Schema, se liší od dokumentu s DTD pouze v deklaraci schématu. Nyní se projeví síla XML Schema, protože pokud by se v XML dokumentu změnila hodnota v elementu nu- mber z devítimístného čísla na osmimístné, validace již neprojde a XML dokument nebude validní. Pokud by se ovšem takováto změna udělala v XML dokumentu s DTD schématem, dokument bude stále validní, a přitom bude obsahovat evidentně neplatné telefonní číslo. Ne- bo pokud se vezme element streetNo a místo číslic se tam napíše třeba „ab“, validátor tuto

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

<list

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="phonebook.xsd">

<entry>

<name>Adam John</name>

<number>420123456</number>

<number>776123456</number>

<address>

<street>Prazska</street>

<streetNo>42</streetNo>

<city>Praha 1</city>

</address>

</entry>

</list>

Obrázek 3.5: Ukázka XML dokumentu validního podle schématu XML schema

(16)

chybu díky XSD schématu rozpozná a validace neprojde, kdežto s DTD schématem se toto zkontrolovat nedá, a dokument by prošel jako validní s evidentní chybou.

Pro jednoduché aplikace často stačí jazyk DTD, ovšem pokud chceme přesněji hlídat hodnoty v jednotlivých elementech a pokročile určovat pravidla XML dokumentů, DTD již nedostaču- je, a je proto vhodnější použít jazyk XML Schema. Bohužel z toho vyplývá relativní složitost tohoto jazyka, což je daň za pokročilé funkce, které tento jazyk poskytuje.

3.2 Jak lze pracovat s XML dokumenty

Za dobu existence XML se vyvinulo několik postupů, jak XML dokumenty číst a pracovat s nimi. První způsob je zpracování dokumentu takzvaným parserem typu SAX. Dále je mož- nost číst dokument pomocí rozhraní DOM, které veškeré elementy a prvky dokumentu repre- zentuje jako objekty. Dále existují různé upravené variace na tyto způsoby.

3.2.1 Push model (SAX Parser)

SAX je zkratkou pro Simple API for XML [4]. Toto rozhraní bylo původně vytvořené speci- álně pro jazyk Java, nicméně dnes je již dostupné pro mnoho různých jazyků. SAX je proudo- vé rozhraní, kde je předáván aplikaci kontinuální proud dat, díky čemuž je tento přístup velmi efektivní co se týče časové náročnosti a paměti, nicméně práce s tímto rozhraním bývá složi- tější než u DOM přístupu [5]. SAX parser během čtení XML dokumentu průběžně vyvolává události, jak postupně naráží na začátky různých elementů a dalších prvků, a vývojář může na tyto události podle potřeby reagovat [6]. Tento způsob čtení XML dokumentu se někdy ozna- čuje jako push model, protože parser do aplikace tlačí informace ze čteného XML dokumentu.

Ve čtení dokumentu se nelze vracet zpět.

3.2.2 Pull model

SAX Parser a jeho nevýhoda v podobě celkové složitosti vedla k vytvoření novějších způsobů pro práci s XML dokumenty, mezi které se řadí hlavně tzv. pull model. Tento způsob čtení

Obrázek 3.6: Push model (SAX Parser)

Push parser Aplikace

Posílám ti další data, starej se!

XML

(17)

se tím, že vývojář si v aplikaci sám říká o to, kdy chce přečíst další část XML dokumentu.

Neboli, aplikace si tahá (odtud pull) data jen, když je potřebuje. Mezi nejznámější parsery typu pull model patří XML Pull Parser (XPP) [7] nebo StAX (Streaming API for XML) [8].

3.2.3 DOM Parser

Zcela jinou metodu zpracování XML dokumentů poskytuje rozhraní Document Object Model [9]. Toto rozhraní je definováno samotným W3C konsorciem, které vytvořilo XML specifika- ci. Pomocí tohoto rozhraní lze po načtení XML dokumentu vytvořit v paměti obraz dokumen- tu pomocí stromu uzlů, kde je každý uzel reprezentován jako objekt [10]. Vývojářům poskytuje jednoduchou cestu, jak zpracovávat obsah XML dokumentů, nicméně má své ne- výhody. Hlavní nevýhoda spočívá ve velké náročnosti na paměť, protože je nutné celý doku- ment udržovat v paměti.

Tato metoda zpracování XML dokumentu je výhodná při náročnějších operacích s XML daty, ale pro použití pouze k samotné validaci se příliš nehodí, protože by se zbytečně plýtvalo s pamětí, která by byla zabrána vytvořeným stromem objektů, které nebudou nijak využity.

Pokud chceme XML dokumenty pouze validovat, je tedy výhodnější použít SAX parser nebo parsery z něj odvozené, použití DOM je v našem případě zbytečné a nevyhovující.

XML parsery se dále dají rozdělit na validující a nevalidující parsery. Nevalidující parser umí pouze číst XML dokument a kontrolovat jeho syntaxi (zda je well-formed), kdežto validující parser umožňuje validovat XML dokument pomocí schémat. Pro potřeby webové aplikace tedy bude potřeba parser, který umí zároveň validovat. Přehled takových parserů bude násle- dovat v další kapitole.

3.3 Podpora XML validace

Dnešní podpora XML technologie je velmi rozšířená a každý programovací jazyk s tímto ja- zykem umí pracovat v rámci různých knihoven či frameworků. Níže bude přehled dostupných knihoven pro validaci XML dokumentů ve vybraných programovacích jazycích.

Pull parser Aplikace

Chci další data!

XML

Obrázek 3.7: Pull model

(18)

3.3.1 PHP

Jazyk PHP verze 5 obsahuje třídu SimpleXML, která načte do paměti celý XML dokument a pracuje s ním jako se strukturou objektů, nicméně validaci nepodporuje [11]. Validaci po- mocí XSD schémat podporuje třída DOMDocument [12]. Ta obsahuje metodu schemaValida- te, která již umožňuje validovat dokumenty podle XSD schématu. Dále obsahuje metody validate (pro DTD) a relaxNGValidate (pro RelaxNG schéma). Nicméně jak už bylo uvedeno, DOM se pro validaci XML dokumentu příliš nehodí, pokud se dále nezpracovává vytvořený strom uzlů. Nejlepší třída pro validaci XML dokumentů s našimi potřebami v PHP je tedy XmlReader [13]. Tato třída využívá pull model způsob pro čtení XML dokumentů, přičemž si zachovává dobré vlastnosti SAX parseru [14]. Obsahuje metodu setSchema, která slouží pro validování XSD schémat a dále obsahuje metodu setRelaxNGSchema, takže umí validovat i podle RelaxNG schématu.

3.3.2 C#

Programovací jazyk C# má k dispozici v rámci .NET frameworku verze 4.5 třídu Sys- tem.Xml.XmlReader, pomocí které lze jednoduše číst i validovat XML dokumenty [15]. Pro- gramátor bude chtít využít také třídu System.Xml.XmlReaderSettings, která umožňuje nastavit parametry samotné validace [16]. XmlReaderSettings obsahuje vlastnost ValidationType, ve které se nastavuje typ validace. Jsou podporovány validace podle DTD a XSD schémat. Dále se zde dá pomocí vlastnosti ValidationFlags nastavit, zda se schéma nachází v externím sou- boru nebo zda je vložené uvnitř XML dokumentu, a zda se mají při validaci vracet i chyby validace typu Warning. Události ValidationEventHandler se pak může přiřadit metoda, která se zavolá v případě nalezení chyby při validaci.

3.3.3 Java SE

Java SE 7 určená pro desktopové aplikace obsahuje balíček javax.xml.parsers, který umožňu- je načítat XML dokumenty dvěma způsoby. První způsob je pomocí SAXParseru třídy SAX- Parser [17], druhý způsob umožňuje načítat dokumenty do stromu uzlů DOM pomocí třídy DocumentBuilder [18]. Dále Java SE 7 obsahuje balíček javax.xml.validation, který slouží pro validaci XML dokumentu pomocí schémat [19]. Tento baláček umožňuje validovat dokumen- ty podle jazyků DTD, XML Schema a RelaxNG.

(19)

4 Webová aplikace

V této kapitole bude nejprve popsáno, jak probíhal vývoj webové aplikace a jaké nastaly komplikace, a poté bude popsána vytvořená webová aplikace, včetně uživatelského rozhraní a vnitřních programových metod a algoritmů. Popis bude doplněn obrázky uživatelského roz- hraní a zdrojového kódu, aby čtenář získal větší přehled během popisu aplikace.

4.1 Vývoj aplikace

V zadání práce nebyl určen způsob, jak aplikaci napsat, ani nebyla určena žádná platforma, takže tyto volby záležely čistě na osobní preferenci. Vzhledem k použití jazyka C# probíhala počáteční fáze tvorby aplikace v desktopové verzi pomocí WinForms API, která je součástí .NET Frameworku. WinForms API je velmi podobné WebForms API používané v ASP.NET, kde také bude probíhat závěrečná fáze vývoje.

Bylo nutné vymyslet a implementovat samotný algoritmus pro načítání a validaci XML do- kumentů a schémat, a proto byl zvolen nejprve vývoj desktopové verze aplikace. Toto roz- hodnutí usnadnilo počáteční vývoj, protože nebylo třeba se zabývat záležitostmi spojenými s vývojem webové aplikace, a tak se dalo lépe věnovat vývoji vhodných algoritmů. Aplikace tedy měla v raných verzích jednoduchý design tvořený pomocí WinForms API a umožňovala základní validaci pomocí XSD schémat.

Jakmile byla implementována funkční validace XSD schémat, začaly práce na migrování aplikace do webového prostředí. Tyto práce zahrnovaly hlavně změnu některých grafických komponent používaných ve Winforms na komponenty dostupné pomocí WebForms. Musela se řešit náhrada za WinForms komponentu OpenFileDialog, která nemá ve WebForms pří- mou náhradu. Nakonec bylo využito WebForms komponenty FileUpload, pomocí které se řeší nahrávání XML dokumentů a schémat na server aplikace. Původně se využívalo její me- tody SaveAs, která uživatelův XML dokument ukládala na server, kde byl pak validován, nicméně poté bylo od tohoto řešení upuštěno (vysvětlení níže).

Bylo důležité se rozhodnout, jakým způsobem se bude uvnitř aplikace předávat samotný XML dokument a schéma k validaci. Aplikace má disponovat více vstupy, a každý se musí zpracovat tedy jinak.

V prvních verzích programu se tyto soubory předávaly přímo jako soubory, ukládaly se tedy na server, odkud je pak četl parser. Toto řešení ale mělo své nevýhody. Mohla vzniknout situ- ace, kdy by existovaly dva různé XML soubory se stejnými jmény. Část programu starající se

(20)

o ukládání XML souborů byla napsána tak, aby byl soubor ihned po validaci smazán, ale i tak mohla vzniknout riziková situace, že ve stejný moment budou dva uživatelé validovat soubor se stejným názvem.

Další problém byl teoretický v oblasti bezpečnosti, kdy se musel na serveru ukládat soubor od uživatelů, a tedy i od potencionálních útočníků, kteří by neměli dobré úmysly a chtěli by apli- kaci či server poškodit a vyřadit z činnosti. Zde platí pravidlo „nikdy nevěřte uživatelům“, a proto byl tento způsob nahrávání a skladování XML souborů nakonec zavrhnut jako řešení s příliš mnoha potenciálními problémy a začalo se přemýšlet nad řešením novým.

Nakonec se postupně přešlo k daleko lepšímu řešení, a to k použití datových proudů neboli streamů. Stream je obecné označení pro datové proudy, přičemž jich existuje několik typů.

Jako nejlepší typ streamu pro potřeby této aplikace se ukázal MemoryStream, kde se celý do- kument, který chceme validovat, načte do paměti RAM, a odtud proudí k samotnému validač- nímu parseru. Nikdy tedy nedojde k přímému uložení jakýchkoliv uživatelských souborů na server aplikace. Jakmile se validace dokončí, stream je vymazán z operační paměti, a není tedy dále dostupný. Tímto krokem je zajištěna větší bezpečnost aplikace proti nahrávání škod- livých souborů.

Webová aplikace je stavěna pouze na validaci podle XSD schémat, nicméně může nastat situ- ace, že uživatel nahraje k validaci XML dokument, který v sobě bude mít DTD deklaraci.

Aplikace se původně chovala tak, že se uživateli vypsala výjimka vyhozená parserem, která popisovala, že z bezpečnostních důvodů není povolena validace pomocí DTD schématu. Tato chybová hláška byla generována parserem kvůli nastavení vlastnosti ValidationType na typ Schema. Tato vlastnost definuje, že se bude validovat podle schématu typu XML Schema, tudíž tato definice musí být přítomna v nastavení parseru. Vypisovaná chybová hláška ale byla matoucí, a proto se nakonec vymyslelo řešení, kdy se do validační metody přidal řádek kódu settings.DtdPRocessing = DtdProcessing.Ignore;. Tento zápis nastaví, že se během va- lidace bude případná DTD deklarace kompletně ignorovat. Validátor tedy bude případný řá- dek kódu s DTD deklarací ignorovat a zbytek XML dokumentu bude standardně validován podle přiloženého XSD schématu.

4.2 Popis uživatelského rozhraní

Uživatel má dostupné webové grafické uživatelské rozhraní, pomocí kterého může aplikaci ovládat. Uživatelské rozhraní je navrženo tak, aby v případě potřeby bylo možné roztáhnout

(21)

bylo pohodlné ho číst. Aplikace je rozdělena do dvou sloupců, kde první (levý) sloupec po- skytuje uživateli několik možností, jak nahrát XML dokument do aplikace k validaci. Pravý sloupec pak obsahuje několik textových polí, které slouží pro výpis výsledků validace.

4.2.1 Vstupní část

Uživatel může nahrát XML dokumenty a schémata třemi různými způsoby. Tyto způsoby jsou v levém sloupci rozděleny do sekcí. První sekce umožňuje označení souborů na disku a jejich následné nahrání na server, kde je provozována aplikace. Po kliknutí na tlačítka „Pro- cházet“ v levé horní části okna se uživateli objeví nové okno pro výběr souborů.

Obrázek 4.1: Náhled na grafické prostředí aplikace

Vzhledem k technologickému omezení ze strany webových prohlížečů může uživatel vybrat libovolný soubor, a to včetně takového, který není XML dokumentem nebo XSD schématem.

Okno pro výběr souboru totiž vytváří prohlížeč a nelze mu nijak předat, jaký typ souboru chceme povolit k nahrání na server. Tento nedostatek je řešen programově v samotné webové aplikaci, kde se po nahrání souboru na server kontroluje jeho přípona. Pokud přípona neodpo- vídá formátu xml nebo xsd, je soubor zahozen a uživatel informován o špatném formátu na- hraného souboru. Kontrola formátu nerozlišuje velká a malá písmena (není case-sensitive).

(22)

Díky tomuto kroku je zamezeno validování souborů jiných než souborů s příponou xml nebo xsd, nicméně je tím znemožněna validace XML souborů s jinými příponami (SVG, XHTML,…). Pokud by chtěl uživatel validovat XML soubory s těmito příponami, musí pou- žít vstupní textová pole, která budou vzápětí vysvětlena.

Druhý způsob, jak vložit dokument a schéma k validaci, je prostřednictvím vstupních texto- vých polí. Uživatel pak musí pomocí nějakého textového editoru otevřít XML dokument nebo schéma, zkopírovat celý jeho obsah do schránky a vložit do správných textových polí. Obsah polí se nikde neukládá a putuje přes MemoryStream přímo do XmlReaderu, který začne pro- vádět validaci. Tento způsob tedy umožňuje již vložit jakýkoliv dokument založený na XML technologii, včetně těch, které obsahují jinou příponu než xml.

Poslední způsob pak představuje vložení dokumentu a schématu pomocí URL adresy. Adresy musí být v jednoznačném tvaru, neboli musí končit příponou xml nebo xsd. Jednotlivé adresy jsou nejdříve ověřeny, zda existují, a poté je provedena kontrola na správnost přípony, aby uživatel nemohl vložit odkaz třeba na obrázek nebo na celou stránku. Na obrázku 4.2 lze vidět rozhraní pro vložení dokumentů pomocí URL odkazu. V tomto případě zadal uživatel neexis- tující URL odkazy a uživatel tak je patřičně informován.

Obrázek 4.2: Každé zadané URL je nejprve kontrolováno

Velká výhoda aplikace spočívá v tom, že lze tyto vstupy libovolně kombinovat. Uživatel tak může použít třeba URL odkaz na XSD schéma umístěné někde na internetu a validovat lokál- ní XML dokumenty pomocí tohoto webového schématu. Pokud uživatel použije více XML nebo XSD vstupů najednou, aplikace použije k validaci ten vstup, který má vyšší prioritu.

Nejvyšší prioritu mají vstupní textová pole. Druhá nejvyšší priorita je určena pro nahrávání lokálních souborů. Nejmenší prioritu pak mají URL odkazy. Pokud tedy uživatel vloží XSD schéma jako URL odkaz a zároveň XSD schéma vloží do textového pole, aplikace bude vali-

(23)

Aplikace v levé dolní části obsahuje dvě tlačítka. První tlačítko Validate slouží ke spuštění samotné validace, druhé tlačítko Clear all pak slouží k vymazání všech vstupů i výstupů apli- kace. Všechny vstupy mají vnitřní ochrany, aby nebylo možné nahrát pouze schéma bez sa- motného XML dokumentu, dokument místo schématu apod.

XSD schéma většinou bývá přiloženo v samostatném XSD souboru a validace pak probíhá pomocí tohoto souboru. Pokud schéma přiloženo není, validátor předpokládá, že je XSD schéma uloženo uvnitř XML dokumentu a snaží se podle něj validovat. Pokud žádné vnitřní schéma není nalezeno, validátor vypíše seznam všech nedefinovaných elementů XML doku- mentu. Takto provedená validace je pak neplatná.

4.2.2 Výstupní část

Pravá část aplikace poskytuje detailní výpis z průběhu validace. V horní části se zde nachází textové pole s názvem Info, které můžete vidět na obrázku 4.3. V tomto poli se při každé vali- daci vypíše, jakého XML dokumentu a schématu se daná validace týká. Uživatel totiž může provádět více validací za sebou a výpis aktuálního nahraného dokumentu a schématu ho ujistí, že validuje zrovna to, co opravdu chce. V případě, že byl dokument nahrán prostřednictvím výběru souboru z disku, je zde ještě uvedena kromě jména i jeho velikost v bajtech. V případě fatální chyby se toto okno využito pro její výpis. Mezi takové chyby se řadí například vyprše- ní časového limitu během validace přes URL odkaz.

Obrázek 4.3 Zobrazení informací o validovaném XML dokumentu a schématu

Prostřední textové pole s názvem Syntax check status vypisuje, zda je daný dokument takzva- ně well-formed, neboli zda má dokument správnou syntaktickou gramatiku jazyka XML. Po- kud bude v dokumentu překlep, bude chybět uzavírací značka nějakého elementu nebo budou elementy překříženy, parser se v tomto místě zastaví a vypíše chybu. Kromě samotné chyby je vypsáno i číslo řádku, kde se chyba nachází, a výpis je obohacen i o kus XML kódu ze zdro- jového XML dokumentu, aby mohl uživatel ihned vidět, co je špatně.

(24)

Pokud se syntaktická chyba bude nacházet níže v dokumentu, je možné, že stihne proběhnout validace některých prvků XML dokumentu před touto chybou. Tato validace ovšem není uži- vateli vypsána, uživateli se pouze vypíše syntaktická chyba v okně Syntax check status, kterou je nutno opravit před dalším pokusem o validaci. Pokud dokument nemá správnou syntaxi, a není tedy well-formed, nemůže být ani validní. Na obrázku 4.4 lze vidět pole Syntax check status a Validation status, kde se během validace zobrazují výsledky.

Obrázek 4.4: Textová pole sloužící pro výpis výsledků validace

Poslední textové pole Validation status je z pohledu validace nejdůležitější, protože se zde uživatel dozví, zda jeho XML dokument plně odpovídá zvolenému XSD schématu. Pokud parser objeví chybu ve schématu, k validaci nikdy nedojde. Pokud je dokument i schéma po syntaktické stránce v pořádku, validace proběhne a její výsledek je vypsán do textového pole.

Případné chyby validace jsou rozděleny podle závažnosti na warning (varování) a error (chy- ba). Počet varování a chyb je pak zobrazen v popisku textového pole. Stejně jako u validace syntaxe je i zde ke každé chybě i varování vypsán kus zdrojového kódu dokumentu včetně čísla řádku, kde se daná chyba nachází.

4.3 Popis vnitřních metod a algoritmů

Aplikace obsahuje několik metod a tříd, které jsou rozděleny podle použití na metody obslu- hující vstupní část aplikace a na metody starající se o samotnou validaci.

4.3.1 ValidationSettings

Důležité bylo vyřešit, jak předávat nahraný XML dokument a schéma validačním metodám.

Vytvořila se k tomu speciální třída ValidationSetting, která je ukázána na obrázku 4.8. Tato

(25)

třída obsahuje dvě proměnné xml a xsd typu InputFile, které uchovávají XML dokument a XSD schéma v průběhu validace. Třída InputFile bude popsána za chvíli.

Třída ValidtionSettings dále obsahuje proměnnou isValid typu bool, která informuje validační metodu o tom, zda je XML dokument stále validní. Proměnné noWarnings a noErrors typu int uchovávají počet chyb a varování, kterých validovaný XML dokument dosáhl. Třída Vali- dationSettings dále obsahuje konstruktor, který při vytvoření nové instance této třídy nastaví standardní hodnoty proměnných.

Obrázek 4.5: Třída ValidationSettings

4.3.2 InputFile

InputFile je další vytvořenou třídou, která je využívána třídou ValidationSettings. Třída InputFile obsahuje proměnnou fileStream typu Stream, která slouží jako datový proud pro XmlReader, ze kterého se při validaci čte XML dokument. Dále tato třída obsahuje proměn- nou fileName typu string. Proměnná fileName uchovává název nahraného XML dokumentu nebo schématu.

Obrázek 4.6: Třída InputFile

(26)

Třída InputFile je navržena tak, aby uchovávala obsah XML dokumentu dvakrát. Jednou po- mocí MemoryStreamu, který se následně předává XmlReaderu k validaci a podruhé pomocí proměnné fileData typu string. Tato druhá proměnná je použita proto, aby validati- on_callback metoda mohla během validace průběžně vypisovat k případným nalezeným chy- bám i související chybné řádky kódu XML dokumentu. MemoryStream sice umožňuje vyresetování pozice datového proudu a opětovné čtení, nicméně toto řešení by bylo kompli- kované pro implementaci, takže bylo využito mnohem jednoduššího způsobu, spočívajícího ve vytvoření druhé proměnné typu string, ve které se dá opakovaně vracet, snadno se pohy- bovat po jednotlivých řádcích a vypisovat je podle potřeby. Třída InputFile je navíc navrhnuta tak, že může uchovávat informace jak o XML dokumentu, tak o XSD schématu, a lze ji proto využít univerzálně pro oba typy souborů.

4.3.3 Btn_validate_Click

Aplikace obsahuje metodu btn_validate_Click, která se volá po zmáčknutí tlačítka Validate.

Tato metoda obsahuje podmínkovou konstrukci, která určuje, jaké vstupy se použijí k valida- ci. Nejdříve se detekuje, do jakých polí vložil uživatel XML dokument a schéma. Tato detek- ce probíhá podle priority jednotlivých vstupů. Nejprve probíhá detekce XML dokumentu, přičemž se nejdříve detekuje, zda je dokument vložen do textového pole. Pokud ne, kontroluje se přítomnost souboru v komponentě UploadFile. Pokud ani zde není soubor, zkontroluje se, zda uživatel vložil XML dokument přes URL odkaz. Poté se stejná detekce provede i pro XSD schéma.

Uživatel může použít více vstupů najednou. Pokud tato situace nastane, algoritmus automa- ticky použije vstup s nejvyšší prioritou. Nejvyšší prioritu mají vstupní textová pole, poté na- hrávané soubory přes UploadFile a vstup s nejnižší prioritou je pak URL odkaz. Po úspěšné detekci použitých vstupů je tento vstup předán metodám process_upload, process_text_input nebo process_URL. Ty jej následně zpracují a zpět předají. Zpracování bude popsáno v další podkapitole. Nakonec je zavolána metoda validate_inline nebo validate_extern, podle toho, zda uživatel nahrál společně s XML dokumentem i XSD schéma.

4.3.4 Process_upload

Metoda process_upload, jejíž hlavní část je vidět na obrázku 4.7, se stará o zpracování soubo- ru vloženého k validaci pomocí komponenty UploadFile z lokálního úložiště. Nahrát lze sou- bor s jakoukoliv příponou, protože tato věc nejde ošetřit prostřednictvím prohlížeče.

(27)

Obrázek 4.7: Část metody process_upload

Poté, co se soubor nahraje do paměti aplikace, je programově ošetřeno, zda se jedná o správný typ souboru pomocí kontroly přípony. Pokud je soubor přípony .xml, respektive .xsd, je dále metodou zpracován, jinak je zahozen. Když je zahozen, je uživateli vypsána odpovídající chybová hláška, proč se tak stalo.

Pokud je vše v pořádku, tak se následně vytvoří nová instance třídy InputFile. Zjistí se délka nahraného souboru, která se použije při vytvoření nového pole typu byte. Je vytvořen stream typu Stream, který se naplní obsahem nahraného souboru, a tento stream je zapsán do vytvo- řeného pole a následně vymazán z paměti. Nyní lze toto pole použít k naplnění nového strea- mu typu MemoryStream, který už lze předat instanci třídy InputFile.

Instance inFile třídy InputFile je následně naplněna jménem nahraného souboru, zmíněným MemoryStreamem a ještě jednou kopií celého XML dokumentu. Nakonec je stream uzavřen a instance InFile předána dále ke zpracování

4.3.5 Process_text_input

Další metoda pro zpracování vstupu je metoda process_text_input. Zde se zpracovává vstup vložený uživatelem do textových polí, což je v tomto případě jednoduché, pouze se vytvoří MemoryStream, do kterého se zkopíruje obsah textového pole. Tento obsah je metodě předán pomocí parametru input. Jméno XML dokumentu je v tomto případě generické. Druhá kopie XML dokumentu pro výpis zdrojového kódu je pak jednoduše zkopírována z vstupního para- metru.

(28)

Obrázek 4.8: Metoda process_text_input

4.3.6 Process_URL

Metoda process_URL, jejíž část je vidět na obrázku 4.9, je poslední metodou, která se stará o zpracování uživatelova XML dokumentu a schématu pro potřeby validátoru. Ověření URL adresy proběhne již před zavoláním této metody, takže adresa předána metodě process_URL je již ve správném a existujícím formátu.

Obrázek 4.9: Část metody process_URL

Po vytvoření nové instance třídy InputFile je ověřena přípona odkazovaného souboru. Pokud přípoda neodpovídá příponě XML ani XSD souboru, je validace přerušena a uživateli je vy- psána chybová hláška. Pokud je vše v pořádku, je vyžádán WebRequest na dokument v URL odkazu. Poté je vytvořen nový stream, do kterého je webový soubor zkopírován. Následně je tento stream zkopírován do druhého streamu, který je tentokrát již typu MemoryStream. Tento MemoryStream je pak zkopírován do pole typu byte, odkud již může být konečne vložen do

(29)

URL odkazu na soubor a v proměnné fileData je vytvořena druhá kopie XML souboru zkopí- rováním obsahu z pole data.

4.3.7 Validate_inline

Samotná validační část aplikace je z důvodu vnitřního fungování rozdělena na dvě samostatné metody validate_inline a validate_extern, které se volají podle toho, zda uživatel přiložil schéma externí, nebo zda se schéma nachází uvnitř samotného XML dokumentu. Pokud uži- vatel externí XSD nepředloží, zavolá se vnitřní metoda validate_inline. V tomto případě se nejprve vytvoří instance třídy XmlReaderSettings, pomocí které se nastavují parametry vali- dace. Pomocí vlastnosti ValidationFlags se nastaví, že se bude validovat podle schématu typu XSD, že se nachází přímo uvnitř XML dokumentu, dále se zapne podpora hlášení validačních varování a připojí se metoda validation_callback, která je volána validátorem v případě vý- skytu chyby nebo varování. Vlastností DtdProcessing.Ignore se vypíná zpracování případ- ných DTD deklarací vyskytujících se v dokumentu, a nakonec se vytvoří instance třídy XmlReader, která toto nastavení převezme společně s MemoryStreamem ze třídy InputFile.

V cyklu while se pak parserem čte vytvořená instance XmlReaderu. Pokud během čtení XML dokumentu narazí parser na chybu, čtení se přeruší a je vyvolána výjimka typu XmlException, která je zachytnuta. Do textového pole Syntax check status se uživateli vypíše chyba parseru společně s číslem řádku a vypíše se část zdrojového kódu XML dokumentu s chybou. V tento moment je již další čtení dokumentu přerušeno. Pokud se syntaktická chyba vyskytovala ně- kde níže v dokumentu, mohla u části dat před tímto místem proběhnout validace, nicméně validace je to nekompletní a dokud dokument nebude well-formed, nikdy neproběhne validace celá.

Obrázek 4.10: Část metody validate_inline

(30)

Během syntaktické kontroly dokumentu se tedy zároveň provádí i validace. V případě nálezu chyby se zavolá metoda validation_callback, která přičítá celkové množství chyb a varování a zároveň tyto chyby vypisuje uživateli do textového pole. Pokud se alespoň jednou za dobu validace zavolá metoda validation_callback a nalezený typ chyby je Error, je proměnná isVa- lid nastavena na false a výsledek validace je tedy negativní. Metoda validation_callback rozli- šuje chyby validace pomocí speciální proměnné XmlSeverityType, která může nabývat hodnot Error nebo Warning.

4.3.8 Validate_extern

Metoda validate_extern již podporuje externí XSD schémata. Tato metoda se zavolá v přípa- dě, že uživatel nahraje kromě XML dokumentu i externí XSD soubor. Je zde stejně jako v první metodě vytvořena instance typu XmlReaderSettings, kam se tentokrát přiřazuje uživa- telské schéma. Toto přiřazení se může provést až po úspěšném přečtení schématu. Pokud je schéma chybné, vyhodí instance třídy XmlSchema výjimku, která ukončí celou validaci. Uži- vatel je pak informován o tom, že je schéma vadné a je mu vypsána chyba s číslem řádku a kusem zdrojového kódu schématu z místa, kde se chyba nachází.

Obrázek 4.11: Část metody validate_extern

Když je schéma korektně načteno, přiřadí se do vytvořené instance typu XmlReaderSettings a instance XmlReaderu začne číst uživatelův XML dokument. Zde je již stejný postup jako u inline validace. Pokud XmlReader při čtení dokumentu narazí na chybu, vypíše ji uživateli a ukončí validaci. Pokud je čtení dokumentu úspěšné až do konce, validace proběhne kom- pletně.

4.3.9 Validation_callback

Tato metoda se stará o výpis varování a chyb uživateli a je volána z validačním metod v pří- padě nálezu problému v XML dokumentu během validace. Metota rozdělena do dvou sekcí,

(31)

které se vykonávají podle toho, zda typ zjištěného problému je varování nebo chyba. Obě sekce pak vypisují uživateli nalezený problém, který byl této metodě předán z XmlReaderu prostřednictvím parametru args typu ValidationEventArgs. Nakonec je zde volána metoda get_lines, která pod chybu vypíše zdrojový kód XML dokumentu z místa, kde se chyba na- chází.

4.3.10 Get_lines

Aplikace obsahuje také metodu get_lines, která se stará o zmiňovaný výpis tří řádků chybné- ho XML kódu v případě chyby. Pokud se vyskytne při validaci chyba, ať už validační nebo syntaktická, předá se této metodě proměnná fileData typu string ze třídy InputFile. Pomocí podmínek a cyklů se pak najde správný řádek výskytu chyby a vrátí se v poli typu string spo- lečně s řádkem vyskytujícím se před a za chybou. Celkově se tedy uživateli vypíšou tři řádky kódu, což bylo zvoleno jako kompromis mezi informační hodnotou a velikostí zabraného mís- ta v textovém poli Validation status pro výpis chyb.

4.3.11 Check_URL_status

Metoda check_URL_status slouží pro jednoduché ověření zadaného URL odkazu, zda existu- je. Ověření probíhá tak, že se metoda pokouší o navázání spojení se zadanou URL adresou pomocí WebRequestu. Pokud se spojení podaří navázat, metoda vrátí informace o pozitivní odezvě serveru metodě process_URL.

4.3.12 Btn_clear_click

Tato jednoduchá metoda slouží k vymazání všech textových polí a dalších informačních prv- ků aplikace. Je vyvolána stisknutím tlačítka Clear_all a aplikaci uvede do původního stavu, stejného jako v případě nového načtení stránky. Všechny informace o validaci a přiložených souborech jsou vymazány.

(32)

5 Ukázka webové aplikace v praxi

V této kapitole bude názorně předvedeno, jak validace pomocí této online aplikace probíhá a jaké různé výstupy může uživatel od aplikace dostat. Validace může dosáhnout několika sta- vů, které zde budou rozebrány.

5.1 Validní XML dokument

Uživatel bude často validovat XML dokument, který bude validní. Pokud bude takovýto XML dokument validován podle správně vytvořeného XSD schématu, validátor po skončení validace uživateli vypíše zeleně obarveným písmem, že je daný XML dokument well-formed a validní. Pokud je XML dokument validní podle XSD schématu, znamená to také, že použité XSD schéma má též správnou syntaxi, a je tedy well-formed. Na obrázku 5.1 lze vidět výstup aplikace po validaci validního XML dokumentu.

Obrázek 5.1: Výstup aplikace, když je XML dokument validní

Aplikace tedy uživateli v prvním okně vypsala, že validovaný XML dokument je well-formed, a ve druhém okně, že XML dokument je validní.

5.2 Nevalidní XML dokument

Hlavní funkce této online aplikace je ovšem odhalování syntaktických nebo validačních chyb, takže je důležité uživateli detailně vypsat nalezené chyby, aby je mohl ve svém XML doku- mentu nebo XSD schématu snadno lokalizovat, pochopit a odstranit. Pokud tedy uživatel va- liduje pomocí této aplikace XML dokument, který není validní, jsou nalezené chyby uživateli podrobně popsány červeně obarveným písmem. Jak už bylo dříve zmíněno, XML dokument nemusí být validní, ale zároveň může být well-formed.

(33)

Obrázek 5.2: Ukázka výpisu chyb v případě nevalidního dokumentu

V případě obrázku 5.2 byl validován XML dokument se správnou syntaxí, který vykazuje dvě chyby. Nad Validation status oknem lze vidět celkový počet chyb a varování, které tento XML dokument obsahuje. V samotném textovém poli pak můžeme vidět dvě chyby, které jsou detailně popsány.

Výpis chyby vždy začíná jejím typem, zda se jedná o Error nebo o Warning. Poté se v hranatých závorkách nachází jejich přesné umístění v XML dokumentu. Line Number ozna- čuje číslo řádku s výskytem chyby a Line position označuje, kolikátým znakem v daném řád- ku chyba začíná. Další řádek již obsahuje popis nalezené chyby. V tomto případě je chyba, že element book obsahuje vnořený element author, nicméně by měl podle XSD schématu urče- ného pomocí jmenného prostoru urn:bookstore-schema obsahovat vnořený element title. Ná- sleduje třířádkový výpis chybného XML kódu ohraničeného spojovníky. V tomto výpisu se samotná chyba vyskytuje na prostředním vypsaném řádku a všechny tyto řádky jsou také očís-

(34)

lované. Druhá vypsaná chyba je stejného typu, akorát byl v elementu author očekáván vnoře- ný element first-name, ale místo toho obsahoval vnořený element name.

Během validace se také mohou objevit kromě chyb i varování. Pokud se vyskytne zároveň chyba i varování, text bude vždy obarven červeně a XML dokument nebude validní. Více o varování bude v následující podkapitole.

5.3 Validní XML dokument s varováním

Též může nastat situace, kdy validovaný XML dokument je celkově validní, neobsahuje žád- nou chybu, ale validátor vyhodí jednu nebo několik varování. Varování je upozornění, že ně- co není úplně v pořádku, ale nenarušuje to celkovou validitu XML dokumentu podle použitého XSD schématu. Pokud takováto situace nastane a uživatel nechá validovat XML dokument se schématem, které při validaci vyhodí varování, bude uživateli vypsán žlutě zbar- veným písmem detailní výpis, o jaký typ varování se jedná, společně s číslem řádku varování a kouskem zdrojového kódu, pokud to typ varování umožňuje. Obrázek 5.3 takovýto výpis ukazuje.

Obrázek 5.3: Ukázka výpisu varování

Jak je vidět, validovaný XML dokument je well-formed, ale obsahuje jedno varování. V tomto případě je to proto, že proběhla validace pomocí vnitřního XSD schématu vloženého do XML dokumentu a nemohl být ověřen kořenový element XML dokumentu. Samotný popis varová-

(35)

ní je pak identický s výpisem chyby, pouze je výpis proveden žlutou barvou. Pokud ovšem výpis obsahuje chyby i varování, je výpis vždy obarven červeně.

5.4 Non well-formed XML dokument nebo XSD schéma

Zatím byly popsány stavy, kdy má XML dokument vždy správnou syntaxi. Pokud se validuje XML dokument, který není well-formed, je tato skutečnost a chyba s tím spojená vypsána v okně Syntax check status. Výpis je v červené barvě, a opět má stejný formát jako v případě vypsání chyby při validaci. Chyby syntaxe můžou být například neuzavřené značky, překříže- né značky nebo vložené nepovolené znaky. Pokud není dokument well-formed, nemůže být nikdy validní, a proto se uživateli nevypíše nic o samotné validaci oproti použitému XSD schématu. Tuto situaci lze vidět na obrázku 5.4. V tomto případě validovaný XML dokument má překřížené elementy, a proto na řádku 17 očekává jiný element, než na jaký validátor na- razil.

Obrázek 5.4: Ukázka výpisu chyby při validaci XML dokumentu, který není well-formed

Nastat může také situace, kdy nevykazuje nesprávnou syntaxi XML dokument, ale XSD schéma. Jak již bylo zmíněno, XML Schema je jazyk postavený na XML. Díky tomu se dá snadno ověřit, zda je schéma well-formed, a je to dokonce nutné, aby mohlo být schéma správně načteno. Pokud je tedy schéma nějakým způsobem poškozené, je daná chyba vypsána na stejném místě, kde se vypisují chyby syntaxe XML dokumentu. XSD Schéma se ověřuje na syntaxi jako první, tudíž v případě problému s XSD schématem k ověření XML schématu nedojde. Chyba je pak uživateli vypsána stejným způsobem jako v předchozích případech.

(36)

Obrázek 5.5: Ukázka výpisu chyb v případě, že je poškozené XSD schéma

Na obrázku 5.5 lze vidět konkrétní případ, kdy je nahrané XSD schéma poškozené, a tím pá- dem syntakticky nesprávné. Chyba říká, že XSD schéma neobsahuje deklaraci elementu aut- horName ve jmenném prostoru urn:bookstore-schema. Sedmnáctý řádek pak obsahuje pozici, kde je nedeklarovaný element odkazován. Validační okno pak uživatele informuje o tom, že je jeho XSD schéma poškozené, a nemůže být proto XML dokument validován.

5.5 Validování XML dokumentu s vnořeným (inline) XSD schématem

Uživatel může validovat XML dokument, který má XSD schéma vložené uvnitř XML doku- mentu. Pokud tedy uživatel takto validuje XML dokument, bude mu vždy vypsáno minimálně jedno varování. Vnořené XSD schéma se totiž musí vyskytovat uvnitř kořenového elementu XML dokumentu, a tudíž tento kořenový element nemůže být ověřen pomocí XSD schématu, protože se musí schéma vyskytovat vždy uvnitř.

Obrázek 5.6: Vypsání poznámky uživateli o tom, že inline validace vždy vyhodí minimálně jedno varování

Uživateli je tedy v případě validace pomocí vnitřního schématu vždy vypsána poznámka do textového pole Info, že tímto způsobem nelze ověřit kořenový element XML dokumentu. Vý- sledek validace tedy vždy vygeneruje minimálně jedno varování. Vnitřek XML dokumentu již

(37)

6 Srovnání s ostatními validátory

V současné době již webové XML validátory existují, často ale validují rozdílně a používají pro validaci odlišné knihovny. Zde jsou srovnány první tři služby, které byly vypsány ve vý- sledcích hledání Googlu k datu psaní této práce při použití klíčových slov „online XML vali- dator“ a byla prozkoumána jejich funkčnost. Ve výsledcích lze najít lépe či hůře provedené XML validátory, které se ale často od sebe velmi liší jak kvalitou validace, tak dostupnými možnostmi pro validování.

6.1 W3Schools XML Validator

Validátor na prvním místě byl XML validátor poskytovaný stránkou W3Schools na adrese www.w3schools.com/xml/xml_validator.asp. Tento validátor je velmi jednoduchý, umožňuje ověřit XML dokument pouze na syntaktické chyby. Uživatel může XML dokument vložit buď prostřednictvím textového pole, nebo pomocí URL adresy. Možnost nahrání dokumentu ze souboru chybí.

Obrázek 6.1: W3Schools XML validator

Po validaci pomocí textového pole se objeví malé okno s hláškou říkající uživateli, zda pro- běhla validace úspěšně nebo ne. Pokud ne, je v tomto okně vypsána chyba. Pokud se využije

(38)

validace prostřednictvím URL odkazu na XML dokument, po validaci se objeví nový list pro- hlížeče, kde je vypsána případná chyba.

Validace pomocí této služby je na velice základní úrovni, nemůžete provést validaci pomocí XML schématu, ať už DTD či XSD. Výsledek validace je podán uživateli poměrně nepřívěti- vě. W3Schools je stránka, která se orientuje především na online tutoriály webových techno- logií, jako jsou HTML, CSS, SQL, XML a dalších, takže se dá pouze základní funkcionalita XML validátoru pochopit.

6.2 The W3C Markup Validation Service

Jako druhý validátor se ve výsledcích objevil validátor od samotného konsorcia W3C, které samotnou XML specifikaci vyvinulo a standardizovalo. Validátor se nachází na stránce http://validator.w3.org/ a pro mnohé je známý hlavně především díky validaci HTML či XHTML stránek. Validátor se dá použít i pro XML validaci, protože XHTML jazyk je zalo- žen právě na základu XML [20].

Obrázek 6.2: The W3C Markup Validation Service

XML dokument se může vložit jak URL odkazem, tak vložením do textového pole či nahrá- ním samotného souboru na server. Kontrola probíhá pouze na úrovni kontroly syntaxe, nelze tedy provést validaci oproti XML schématu a navíc zde vždycky vyskočí varování, že u dané- ho XML dokumentu chybí doctype deklarace, protože validátor předpokládá, že budete kon- trolovat webovou stránku a nikoliv XML dokument.

(39)

Zdá se, že W3C konsorcium v minulosti poskytovalo vlastní XML validátor přímo pro XSD schémata, nicméně již byl zrušen [21].

6.3 Www.xmlvalidation.com

Na třetím místě ve výsledcích vyhledávání se nacházela služba s jednoduchým názvem XML validation umístěná na stránkách http://www.xmlvalidation.com/. Tento validátor již umožňu- je validaci pomocí DTD či XSD schématu. Uživatel může vložit XML dokument buď do tex- tového pole, nebo nahrát soubor přímo na server. Pokud však chce uživatel validovat pomocí externího XSD schématu, musí nejdříve ručně zvolit samotný XML dokument pomocí tlačít- ka Procházet v okně pro výběr souboru, poté počkat, než se načte nová stránka, a až poté mů- že zvolit a nahrát XSD schéma stejným způsobem.

Obrázek 6.3: www.xmlvalidation.com

Validace této služby umí poskytnout informace na dobré úrovni a zobrazí i zdrojový kód do- kumentu s vyznačenými chybami, nicméně zdrojový kód se vypíše vždy celý. Pokud má tedy

(40)

uživatelův XML dokument tisíce řádků, aplikace po validaci všechny vypíše, což může za- seknout webový prohlížeč a rozhodně to bude působit velmi nepřehledně.

References

Related documents

Ovšem tehdy jsem to vnímala jako negativní událost, jenž ovlivnila vše, co jsem do té doby dělala, či měla v plánu udělat.. Byl to

Environmentální daň patří mezi ekonomické nástroje politiky životního prostředí, a proto by měla pozitivně působit na změnu chování ekonomických subjektů a tím

Du får inte se hur skakigt jag står Jag orkar inte mer, jag vill att du går Supertydligt nej, det är inget för dig Vers 2. För varje dag som går, gör livet mig rädd Jag räcker

Så att EU-medborgarna får en realistisk bild av hur deras rättigheter och möjligheter i Sverige ser ut, något som respondenterna upplever att dessa människor inte riktigt har då

Dále byly také do vzorníku zařazeny vzory natisknuté na bílém tylu s bílou podkladovou textilií, aby bylo vidět, jak by všechny vzory vypadaly s použitím stejné myšlenky

Zcela nejjednodušší varianta transformátoru [9]. Převod je založen na PHP, detekce chyb téměř chybí a formát nebo odsazení výstupního textu není žádný.

£an lårer mål funna finara fór ftg fjeíf, fiururoíba (jan, antingen í fwfigbranbe af fina ámbets--fPpíbigfjeter i 9Báe*. berg, eKcr t flagornai på Tlpotfjefeí, e(jer i ÜU

Mestadelen av respondenterna ansåg dock att den kunskap de hade, räckte för att de skulle kunna vara delaktiga på Internet, att det därför inte var programmen i sig som var