základy xml strana 1/34 autor: Ilja Kraval

Transkript

1 základy xml strana 1/34 Základy XML Ilja Kraval, r. 2000, dokument podléhá autorskému zákonu. Všechna práva vyhrazena, šíření tohoto dokumentu, resp. jeho částí není bez svolení autora dovoleno a je trestné. Obsah Základy XML 1 Obsah 1 Poznámky...3 Úvodem 3 XML jako řešení problému třívrstvové architektury...3 Příklad 1 - číselník barev zobrazen jako tabulka...7 Příklad 2 - číselník barev zobrazen jako combobox...8 Základní pojmy XML...8 Co je to markup language...8 Co je to meta-jazyk...8 SGML jako nadmnožina XML...8 Tagy, čitelnost XML dokumentů a vztah XML versus HTML...9 Výhody XML...9 Základy struktury dokumentu XML...10 Odkazy na specifikaci standardu XML světovou organizací...10 Elementy...10 Hierarchie elementů v XML...10 Atributy...11 Well-formed XML dokument...11 Otázka...11 Příklad na HTML stránku jako well-formed XML dokument...12 Základy syntaxe XML...12 Instrukce pro řízení procesu...12 CDATA sekce...13 Entity reference...13 Character reference...14 Komentář...14 Co je to DTD - Data Type Definition

2 základy xml strana 2/34 Validovaný dokument XML...15 DTD deklarace a dokument XML...15 Externí zdroj deklarace DTD...15 Atribut standalone...15 Deklarace typu elementu - ELEMENT...15 Speciální znaky pro ELEMENT deklarace...16 Deklarace atributu...16 Deklarace možného typu atributu...17 Atribut deklarovaný jako CDATA...17 Atribut deklarovaný jako typ ID...17 Atribut deklarovaný jako IDREF nebo IDREFS...17 Atribut deklarovaný jako ENTITY nebo ENTITIES...18 Atribut deklarovaný jako NMTOKEN nebo NMTOKENS...18 Atribut deklarovaný jako seznam možných hodnot...18 Implicitní nastavení atributů...18 Deklarace ENTITY...18 Interní entity...19 Externí entity...19 Parametrické entity...19 Deklarace NOTATION...19 Namespaces...20 URI - Uniform Resource Identifiers...21 Namespaces v XML...21 XML Document Object Model - DOM...22 DHTML DOM a XML DOM...22 Základní objekty XML DOM...23 Jak chápat objektový model a zpřístupněné interfacy jádra XML DOM...23 Výčet základních objektů XML DOM...23 XMLDOMDocument objekt...23 Nová instance objektu XMLDOMDocument...23 metody Load a Save XMLDOMDocument...24 Metody.loadXML(string).saveXML(string)...24 Parsovací flagy objektu XMLDOMDocument...24 XMLDOMDocument a informace o dokumentu...24 XMLDOMDocument a výběr node...24 XMLDOMDocument a jak tvořit nové prvky XML dokumentu...25 Objekt XMLDOMNode

3 základy xml strana 3/34 Jak získat property a kolekce objektu...25 Jak získat hodnotu XMLDOMNode...26 Jak procházet stromem XML pomocí metod a property objektu XMLDOMNode...26 Jak pracovat s podřízenými prvky XMLDOMNode...26 Objekt XMLDOMNodeList...27 Jak pracovat s kolekcí Node objektů...27 Objekt XMLDOMNamedNodeMap...27 Transformace XML dokumentů pomocí XSL...27 Transformace XML dokumentů...27 K čemu může sloužit transformace XML dokumentu...28 Co je to XML Schema...28 Přenos dat XML v Internetovských technologíích MS...29 Databinding XML...29 DataIslands v XML...30 HTTP a XML, scénáře složitých HTTP rozhovorů klient-server...31 Poznámky Protože jsou Semináře moderních technologií zaměřeny na MS technologie, upozorňujeme čtenáře na tuto skutečnost obzvlášť v této kapitole o XML. Technologie XML je sice standardizována obecně - například viz stránky na avšak mnohé skutečnosti zde uvedené jsou vztaženy na MS technologie, což se například projeví použitím prvků podporovaných pouze pomocí browseru IE5. Úvodem XML - Extensible Markum Language je moderní rychle se vyvíjející technologií, které je věnována velká pozornost zejména v problematice Internetovských aplikací a přenosu dat po Internetovské síti. Použití XML se však neomezuje pouze na Internet. Výhody XML se projevují v dalších oblastech, zejména u vytváření standardů datových struktur v různých odvětvích, jak technických, průmyslových, vědeckých, softwarových apod. Znalost základů XML se stává pro tvůrce SW již nezbytností a to nejen tvorby aplikací na Internetu. Nově vznikající standardy právě v XML se s největší pravděpodobností dotknou takřka každé oblasti tvorby SW (včetně průmyslových oblastí, bankovnictví atd.). XML jako řešení problému třívrstvové architektury Nejprve nastíníme jeden z problémů třívrstvové architektury a obecně jeden zásadní problém nastávající při spolupráci distribuovaných systémů na síti. Na základě tohoto problému si ukážeme jednu z hlavních příčin vzniku XML. Jedná se samozřejmě o modelový příklad, který osvětluje základní problém přenosu dat ve třívrstvové architektuře. V předešlých skriptech byl zdůrazněn velký význam třívrstvové architektury. Třívrstvovou architekturu můžeme realizovat v podstatě dvěma základními způsoby: 3

4 základy xml strana 4/34 buď použijeme zpřístupnění objektů v aplikační vrstvě přes DCOM technologii (například v podnikových systémech lokálních sítí) anebo použijeme technologii Internet Serveru, ASP a HTML, která nám objekty business vrstvy zpřístupní buď přes tvorbu instance pomocí Server.CreateObject ve skriptu ASP anebo pomocí deklarace statického objektu pomocí tagu <OBJECT>. Nejprve k prvému přístupu pomocí DCOM: Představme si tu situaci, kdy takřka odlehčený klient (například VB - EXE aplikace) komunikuje s business vrstvovou v aplikaci typu podniková aplikace na lokální síti. Objekty business vrstvy jsou zpřístupněny pomocí DCOM technologie: 3-vrstvová arch. a STANDARD EXE klient GUI object Textbox Business object OSOBA Property Jmeno Jmeno Data objects (ADO) Field Jmeno Data - file, stream, database, XML etc. obrázek 1 Příklad na DCOM strukturu v aplikaci V předešlém obrázku je znázorněna spolupráce GUI prvku na klientovi (umístěném například v VB aplikaci) s business objektem OSOBA. Obsluha vyplní editační pole a jeho obsah se přenese do objektu Osoba na aplikačním serveru. Základní otázkou v tomto případě je - jak se tento obsah editačního pole z GUI na server - objekt přenese? V tomto případě odpověď dává sama technologie COM - přenos z GUI prvku do objektu business vrstvy pomocí tzv. marshallingu, což je technologie zabalení dat do streamu, odeslání po síti a jeho rozbalení - převzetí na straně druhé. Protože jak marshalling tak zpětný unmarshalling je součástí technologie COM jako jeho vnitřní prvek, uživatel technologie COM se nezajímá, jak toto COM provádí. Přenos dat se děje za scénou. Ve VB může být kód ve formuláři znázorněn například takto: 4

5 základy xml strana 5/34 STANDARD EXE klient a DCOM Form modul... Private Osoba As COsoba DCOM Marshalling... Private Sub cmdok_click Click() Osoba.Jmeno = txtjmeno.text... Osoba.Save End Sub Informační systémy lokálních sítí resp.. distribuované systémy s použitím lokálních sítí obrázek 2 DCOM na lokální síti je schován za scénou a v kódu VB se neprojeví Poněkud odlišná situace je na Internetu resp. Intranetu: HTTP Request Web browser HTTP Response ASP Response.write write() Web server ASP stránka např. default.asp HTML zobrazení HTML kód obrázek 3 Přenos údajů mezi GUI a business vrstvou v ASP V kódu formuláře se vytvářejí položky pro HTTP Request objekt. Pomocí objektu Request v ASP jsou hodnoty převzaty a zpracovány. Pomocí objektu Response jsou opět předány klientovi. 5

6 základy xml strana 6/34 ASP kód tvorby GUI ASP stránka výběr barvy <% Response.Write Write( <SELECT... ) For each it in colbarvy Výstup... business objektu anebo z DB Response.Write Write( <OPTION... ) Response.Write Write(it.text)......%> TAG <...> DHTML Není oddělen obsah informace od stylu zobrazení SCRIPT obrázek 4 ASP a přenos informace z business vrstvy do formuláře Všimněte si, že na stránce ASP dávající odpověď klientovi se vyskytují jak prvky business logiky (v našem případě kolekce barev), tak tagy DHTML kódu, tak skript - tj. ASP kód Není tedy obsah oddělen od stylu, jakým se má zobrazit. Ve svém důsledku to znamená, že tvůrce ASP stránky musí dobře znát jak výstup z business logiky (anebo datové struktury v případě přímých selectů do DB z ASP stránky), tak GUI prvky (tagy DHTML), tak ASP technologii. Základním nedostatkem předešlého přístupu je to, že není oddělen obsah od jeho zobrazení. Nejlépe si tento nedostatek uvědomíme tím, že vyjmenujeme, co vše musí expert tvořící takovouto stránku znát, v čem musí být guru : 1. Musí ovládat business logiku anebo datové struktury u přímých selectů z ASP 2. Musí ovládat skriptovací techniku a ASP 3. Musí ovládat DHTML a tvorbu tagů (formuláře a odpovědi apd.) Je zřejmé, že řešení tohoto problémů míchání technologie GUI, business a jejich vzájemné komunikace je ve způsobu stylizace přenosu dat mezi klientem a serverem. Možné řešení pomocí XML může vypadat takto: 6

7 základy xml strana 7/34 Přenos pomocí XML Web klient ASP / HTML stránka FORM XML Objekt business nebo DB obrázek 5 XML může napomoci standardně přenést data a oddělit tak business objekt od GUI Uveďme si příklad takovéhoto přístupu (poznámka: výklad je omezen na použití IE5) Příklad 1 - číselník barev zobrazen jako tabulka Zaveďme soubor s příponou XML (viz /priklad1/barvy.xml) s tímto textovým obsahem... <barva id="1" kod="2001" text="bílá" /> <barva id="2" kod="2002" text="černá" /> <barva id="3" kod="2003" text="modrá" /> <barva id="4" kod="2004" text="červená" /> <barva id="5" kod="2005" text="žlutá" /> <barva id="6" kod="2006" text="zelená" /> <barva id="7" kod="2007" text="fialová" /> <barva id="8" kod="2008" text="hnědá" /> <barva id="9" kod="2009" text="šedá" /> <barva id="10" kod="2010" text="oranžová" /> </barvy>... Všimněte si, že aniž bychom nějakým způsobem rozebírali podstatu tohoto dokumentu, je dobře čitelný. Jedná se o zápis dat číselníku barev, každá barva má id, kod a text. V každém z řádků jednotlivých barev můžeme přímo číst odpovídající hodnoty. Pokud otevřete soubor /priklad1/ barvy.xml pomocí IE5, zobrazí se data jako tabulka (ve stejném adresáři musí existovat také soubor barvy.xsl) 7

8 základy xml strana 8/34 Příklad 2 - číselník barev zobrazen jako combobox Podobně v druhém příkladu při otevření /priklad2/barvy2.xml se data zobrazí jako prvek SELECT (tj. combobox). Oba příklady zřetelně demonstrují oddělení business logiky (vedoucí k vytvoření XML souboru) od přenášených dat (xml) a prezentace (xsl). Obsah je oddělen od způsobu zobrazení. Základní pojmy XML Co je to markup language XML je tzv. markup language určený pro dokumenty obsahující strukturované informace. Pojem markup language znamená, že jazyk obsahuje nějakým způsobem zavedený mechanismus pro identifikaci nejenom samotných hodnot v dokumentu, ale také významu dat - tj. sloučeno dohromady obsahuje obsah + význam strukturovaných dat. Co je to meta-jazyk XML patří také do rodiny tzv. meta-jazyků. Pojem meta obecně kdekoliv znamená povýšení abstrakce o jednu úroveň. Pojem meta vyjadřuje obecný vztah mezi možnou abstrakcí a implementací této abstrakce. Např. meta třída v OOP je třída tříd, meta-model je nad-model, jehož jednou z možných implementací je daný model. Příklad meta: model modelu tříd v objektovém modelování obsahuje věty typu každá třída obsahuje atributy apod. Zatímco model modelu tříd (tj. meta-model) zajímá tvůrce CASE nástrojů (tj. ty pracovníky, kteří tvoří CASE nástroj), samotný model tříd zajímá jejich uživatele. Protože jazyk je možné chápat jako souhrn pravidel, potom meta-jazyk je nějakým konkrétním souhrnem pravidel pro tvorbu jazyka, tj. jazyk jazyka. XML jako meta-jazyk deklaruje možnou syntaxi pomocí tzv. tagů. Protože XML umožňuje vytvořit (podle svých pravidel) libovolný tag a tím dává možnost vytvářet libovolné struktury, je chápán jako metajazyk. SGML jako nadmnožina XML XML je podmnožinou tzv. SGML jazyka (což je ještě obecnější metajazyk než XML). SGML je zkratkou Standard Generalized Markup Language definovaný normou ISO SGML je jazykem nezávislým na podpůrných prostředcích a byl vyvinut před XML pro účely práce se obecnými strukturovanými dokumenty ve své době a tedy nezávisle na pozdějších požadavcích na Internetovské technologie. Složitost a v důsledku i velké možné zobecnění SGML je však překážkou pro použití v Internetovské technologii. SGML by ve svém použití na Internetu poskytlo příliš velkou variabilitu a následnou složitost pro práci s obecnými dokumenty. Na Internetu se vyžaduje o mnoho jednodušší a také striktnější přístup než poskytuje obecné SGML. Z toho důvodu se zavedla určitá omezení, tj. vyňala se podmnožina z SGML jako speciální případ části SGML a tato podmnožina se stala základem pro XML. Protože XML je podmnožinou SGML, znamená to, že XML dokument splňuje požadavky kladené na SGML dokument. XML lze tedy chápat jako pouze určitá část SGML (speciální případ) a proto má XML velmi dobrý teoretický základ. Teorie SGML je totiž již léta vypracovávána a to i na akademické půdě. To je dobrý zdroj pro teoretický rozvoj XML jako jeho podmnožiny. Poznámka: Opravdu XML je verzí 1.0 a přesto je opravdu překvapivě dobře propracováno 8

9 základy xml strana 9/34 Tagy, čitelnost XML dokumentů a vztah XML versus HTML XML dokument je uložen jako textový dokument a lze jej přímo číst libovolným textovým editorem. Struktura dat je v tomto dokumentu velmi dobře čitelná a lidsky srozumitelná. V XML se význam dat označuje pomocí tagů < >. Například u cenného papíru můžeme zavést tag ISIN takto: <ISIN>CZ </ISIN> Sémanticky je přístup pomocí tagů podobný přístupu v HTML, ale existuje tu oproti HTML jeden velký rozdíl: Zatímco HTML je jazykem, XML je meta-jazykem. Znamená to, že HTML má omezenou (i když stále se rozšiřující) množinu možných tagů, tj. syntaxe tohoto jazyka je dána výčtem těchto tagů a jejich možností. Pokud zavedeme v HTML tag, který není dohodnut, interpret HTML jej buď ignoruje anebo nahlásí chybu. Protože se u HTML jedná o jazyk, kterému musí rozumět browser, každé nové zavedení dalšího tagu do HTML (tj. nová dohoda ve standardu) musí být promítnuta i do funkcionality browseru. Oproti tomu XML nemá množinu tagů omezenu a navíc dopředu nepředjímá význam těchto tagů. Oproti tomu v HTML je význam tagu již dán dopředu, například v HTML dokumentu je <IMG> označením pro vložený obrázek do dokumentu. V daném konkrétním XML dokumentu může mít <IMG> jiný význam (například imaginární část čísla) a záleží pouze na interpretaci. Zatímco HTML je řečí o specifické množině tagů, XML je řečí o tom jak je možné tagy tvořit. Uvedené vztahy ukazuje následující obrázek: Poloha metajazyků SGML, XML a jazyka HTML Metajazyky Jazyky SGML implementace HTML XML podmožina CML CDF SMIL obrázek 6 Vztah XML a SGML Výhody XML 1. Dokumenty XML umístěné na Internetu mohou být jednoduše čitelné přímo pomocí browseru (viz předešlý příklad) bez dodatečných prostředků - tj. bez dalších složitých aplikací 2. XML se stává standardem a proto struktura dokumentů XML bude zpracovatelná stále větším množstvím spolu jinak nesouvisejících distribuovaných aplikací od různých dodavatelů 3. XML je kompatibilní s SGML. Protože již nyní existuje spousta standardů strukturovaných dat pro různé oblasti v SGML (průmysl, bankovnictví atd.), budou se odtud tyto dohody přenášet do XML jako do jeho podmnožiny. 9

10 základy xml strana 10/34 4. Napsat aplikaci spolupracující s dokumentem XML je jednoduché díky již existujícím parserům 5. XML je definováno striktně bez odchylek, což zamezuje možné nekompatibilitě 6. Dokumenty XL jsou lidsky čitelné (a pokud nejsou rozsáhlé, tak i kontrolovatelné) přímo z textového editoru bez nutnosti parsovat dokument složitou aplikací Například toto je jedna z velkých výhod oproti EDIFACT technologiím. Základy struktury dokumentu XML Odkazy na specifikaci standardu XML světovou organizací Přesnou specifikace standardů pro XML technologii naleznete na adresách: Extensible Markup Language (XML) 1.0 XML Pointer Language (XPointer) a XML Linking Language (XLink) Extensible Style Language (XSL) Elementy Jeden element je základním prvkem XML dokumentu. Je tvořen pomocí zahajovacího a ukončovacího tagu a uvnitř mezi tagy nese element svůj obsah: <význam> obsah </význam> příklad elemntu: <ISIN>CZ </ISIN> Je povolen prázdný element s žádným obsahem a s možnou dvojí syntaxí: <význam></význam> je ekvivalentní se zápisem <význam /> Element musí mít jak své zahájení, tak své ukončení elementu, což obecně v HTML neplatí. Například v HTML je častý zápis <BR> a přitom v dokument neobsahuje odpovídající ukončovací tag </BR>, podobně tag <IMG> apod. Z hlediska syntaxe XML by bylo správnější napsat tento element takto <BR />. Hierarchie elementů v XML Je umožněno vkládat element do elementu: <význam1> obsah1 <význam2> obsah2 </význam2> </význam1> Je možné však pouze vkládat úplný element (zahájený a ukončený) podobně jako při závorkování v algebře. Z toho plyne přísná hierarchie vztahu mezi elementy a tedy přísná hierarchie dokumentu. Tento požadavek také vede k nutnosti existence jednoho prvku jako root elementu. Chybné vložení může vypadat například takto: <P> Tady bude <STRONG> tučný text 1 </P> a taky text 2 </STRONG> 10

11 základy xml strana 11/34 Atributy Atributy mohou nést další informace spojené s elementem. Atributy jsou dvojice název-hodnota, které se objevují uvnitř startovacího tagu elementu s použitím rovnítka: <význam atribut= hodnota atributu > obsah </význam> Jak vidět, jedná se opět o určitou podobu s atributy tagů v HTML, například: <DIV class= titulek >... avšak existují tyto rozdíly: nejenom že v XML můžeme definovat libovolný tag, můžeme definovat libovolný atriut, a omezení je v tom, že hodnota atributu musí být na rozdíl od syntaxe HTML uzavřena v (anglických) uvozovkách. Well-formed XML dokument Ne každý strukturovaný dokument s tagy splňuje požadavky kladené na XML dokument. Pokud daný dokument požadavky na XML strukturovanost splňuje, nazývá se well-formed XML dokumentem. Tyto požadavky lze shrnout do možných chyb, které dokument nesplní a nestane se tak well-formed dokumentem: Start a end tagy nesouhlasí Elementy se překrývají a chybně se vnořují do sebe XML je case sensitive, rozlišuje malá a velká písmena Neukončení tagů (např. prázdných) Reservované znaky < > & se musí nahradit jiným způsobem Root element (vrcholový element dokumentu) musí vždy existovat Otázka Cvičná otázka pro posluchače semináře a čtenáře skript: Lze obecně dokument HTML považovat za well-formed dokument XML? Odpověď: Nikoliv. Protože HTML syntaxe není tak přísná, mohou existovat HTML dokumenty, které nejsou wellformed XML dokumenty. Například HTML povoluje použít neukončené elementy (<HR> <BR> <IMG> apod.). Z druhé strany však platí, že každou HTML stránku lze za stejné funkcionality přepsat tak, aby byla well-formed XML dokumentem. Je tedy otázkou pouze vnitřní přísnosti autora, zda se rozhodne psát stránky HTML splňující požadavky na well-formed XML dokumenty (a zda to má pro daný případ smysl). 11

12 základy xml strana 12/34 Příklad na HTML stránku jako well-formed XML dokument Příklad 3 (adresář 3) ukazuje na HTML stránku, která má nedostatky z hlediska XML. Ukažme, jak se změní na well formed XML dokument. 1. stránka html seminare99.htm je v browseru IE5 funkční jako HTML stránka 2. soubor xml NotPerfect_seminare99.xml je přesnou kopií tohoto HTML souboru, pouze se změnila extense na xml. Otevřete tento soubor pomocí IE5. Objeví se chybové hlášení. Můžete postupně odstraňovat chyby až do okamžiku zobrazení správného xml souboru. 3. Soubor xml Perfect_seminare99.xml je již upraveným well-formed XML dokumentem. 4. Všimněte si, že i tento soubor po změně extense zpět na HTML bude jako HTML funkční. Základy syntaxe XML Existuje celkem 6 druhů prvků XML dokumentu: Element (pojednáno v předešlé kapitole) Instrukce pro řízení procesu (processing instruction) CDATA sekce Reference na entity (entity reference) Reference na znaky (character reference) Komentáře (comments) Instrukce pro řízení procesu Processing instruction (označované jako PI s) nejsou přímo součástí obsahu dokumentu podobně jako komentáře. XML processor přebírá informace z těchto instrukcí a řídí jimi svoji činnost. PI mají tvar : <?Aplikace instrukce?> Kde výraz aplikace je názvem aplikace, pro kterou je určena instrukce. Název aplikace xml je rezervován jako standard XML. Pro rezervované slovo xml se používají standardně tyto dvě instrukce: jedna informuje XML parser o verzi XML (nyní platí verze 1.0): version= 1.0 a použité kódování: encoding= Windows-1250 (pro češtinu) První tag XML dokumentu (v našich krajích) tedy bude vypadat takto: <?xml version= 1.0 encoding= Windows-1250?> 12

13 základy xml strana 13/34 (viz příklad 3, kde první chybové hlášení je způsobeno právě chybějící PI pro nastavení kódování) CDATA sekce Tato sekce slouží k přenosu informace v rámci XML dokumentu bez parsování podle markup znaků, tj. je to obdoba příkazů pro binary data v jiných technologiích. Pomocí této sekce tedy můžete vložit libovolný výraz do XML dokumentu, i takový výraz, který obsahuje rezervované znaky. Pokud bychom zavedli element pro název zbraně například takto: <nazev> Smith & Wesson </nazev> potom parser by se snažil interpretovat rezervovaný znak & uvedený v obsahu elementu a zřejmě neúspěšně, protože tento znak nemá význam rezervovaného znaku, ale je součástí řetězce. Proto je v této a podobné situaci třeba použít sekci CDATA, která dává parseru na vědomí, že tato část obsažená v sekci, se nemá interpretovat. Syntaxe CDATA sekce je následující: <![CDATA[ řetězec ]]> Všimněte si zahajovacího vykřičníku a dvojí hranaté závorky, první závorka uzavírá vše v tagu, druhá uzavírá obsah za CDATA výrazem. V našem příkladu s coltem Smith & Wesson bychom měli použít konstrukci: <nazev><![cdata[smith & Wesson]]></nazev> Entity reference Reference na entitu vnutí parseru dosadit namísto reference určitá data. Existují dva základní důvody použití entity reference: Dosazení znaků, které je složité vložit - například je nelze přímo typovat Odkaz na jiné XML data jinde a tím dosáhnout pomocí odkazu výrazného zpřehlednění dokumentu. Syntaxe pro zavedení entity reference je jednoduchá, zahajuje se znakem & a ukončuje znakem ;, tj.. &refrence; V HTML se používají znaky, které nemají přímo vyjádření v kódu, ale existuje odkaz pomocí dvojice znaků & a ;. Patří sem: < < > > & & &apos; " Tyto odkazy jsou implicitní, kromě nich existuje možnost zavést své vlastní pomocí DTD (viz dále). 13

14 základy xml strana 14/34 Character reference Character reference - tj. odkaz na znak umožňuje vložit takřka libovolný znak a to i takový, který není na klávesnici, ale vyskytuje se v seznamu normy ISO/IEC Seznam znaků této normy je možné nalézt na HTML stránce: anebo pomocí FTP: ftp://ftp.unicode.org/public/unidata/unicodedata-latest.txt Pokud se má použít character reference, je třeba znát pořadové číslo tohoto znaku v uvedeném seznamu. Potom lze vložit znak pomocí syntaxe: &#číslo například &#163 je vloženým znakem pro anglickou libru. Komentář Syntaxe pro komentář je stejná jako v HTML syntaxi: <!-- comment --> Protože XML je přísné a striktní na syntaxi, není dovoleno použít dvě pomlčky v komentáři, tj. <!-- toto -- není dovoleno --> na rozdíl od čehož v HTML je takováto konstrukce povolena. Častou chybou je konstrukce čárky v kódu pomocí pomlček: <! > což samozřejmě v XML není povoleno. Namísto toho lze například použít syntaxi s rovnítkem: <!-- =================== --> Co je to DTD - Data Type Definition Výhodou XML je možnost vytvářet své vlastní tagy a definovat tak potřebné hierarchické struktury dat. Tato libovůle se může stát překážkou v případech, kdy je třeba provádět kontroly, zda dokument, který používáme, odpovídá svou strukturou dohodnuté definici. Představme si, že dostaneme do,aplikace XML dokument z jiné aplikace, který údajně nese informace o kurzovním lístku ČNB. Znamená to, že nad tvarem a strukturou tohoto dokumentu musí být nějaká dohoda co kde může být. Navíc tato dohoda by neměla být pouze abstraktní nebo ústní, protože aplikace by potřebovala nějakým způsobem verifikovat syntaktickou správnost dokumentu. K tomu slouží zobecnění přístupu k povolené syntaxi dokumentu a zavedení jednotného postupu při této verifikaci pomocí Data Type Definition - DTD. Poznámka: Existuje ještě možnost zavést tzv. XML Schema, které však není standardem, viz dále. Díky DTD nemusíme vytvářet dohody nad strukturami dokumentu případ od případu nějakými nestandardními jinými prostředky. DTD je tedy návoedem jak definovat omezení pro XML dokumenty. 14

15 základy xml strana 15/34 Validovaný dokument XML Zmíněný proces verifikace správnosti dokumentu vůči dohodě o jeho strukturách se provádí pomocí definice v DTD. Tento proces se nazývá se validace dokumentu a pokud dokument souhlasí s jeho definicí v DTD, potom se nazývá validovaný dokument Je třeba podotknout, že zavedení DTD definice pro dokument není povinná. Je to však velmi výhodné z důvodu možnosti validace dokumentu a odstranění případných chyb a nekompatibilit. DTD deklarace a dokument XML Deklarace DTD se může vyskytovat buď uvnitř dokumentu XML, který má tyto definice splňovat, anebo se z dokumentu XML na definice DTD provádí odkaz. Deklarace DTD resp. odkaz následuje v dokumentu XML hned za PI instrukcí <?xml...?>. Deklarace DTD je vždy zahájena příkazem DOCTYPE tagu: <!DOCTYPE název_root_element [ ]> přičemž název_root_element musí souhlasit s názvem rootu elementu XML dokumentu. Poznámka: název root elementu musí mít také deklaraci typu v ELEMENT deklaraci (viz dále) Externí zdroj deklarace DTD V hranaté závorce za názvem root elementu (viz předešlý odstavec) může být vložena deklarace DTD všech prvků anebo odkaz na jiný DTD dokument jako zdroj. Druhý případ má pochopitelnou výhodu možného sdílení DTD dokumentů několika XML dokumenty. V případě odkazu se používá následující syntaxe: <!DOCTYPE název_root_element SYSTEM název_souboru> např. : <!DOCTYPE barvy SYSTEM barvy.dtd > Atribut standalone V souvislosti s připojením DTD k dokumentu XML je důležité znát funkci atributu standalone. V některých případech je povaha zavedeného DTD taková, že bez něj dokument XML ztrácí smysl - nemá totiž bez DTD plnohodnotné informace. Problém je v tom, že DTD nejenom že deklaruje typy (což se dá při zpracování XML dokumentu oželet jako můžeme oželet kontrolní funkci), ale navíc DTD může obsahovat takové prvky, které do XML dokumentu vnášejí přímo informace. Jedná se například o implicitní nebo fixní hodnoty atributů. V tom případě dokument XML nemůže být použít korektně, protože aplikace by s těmito hodnotami počítala a očekával by jejich relevantní hodnoty nastavené implicitně nebo fixně. Z toho důvodu se zavádí atribut standalone, jehož nastavení na hodnotu yes znamená, že dokument XML ke své interpretaci nepotřebuje DTD dokument, i když je na něj odkazováno. Atribut standalone se umisťuje do úvodního PI tagu <?xml... standalone= yes...?> Deklarace typu elementu - ELEMENT Deklarace typu elementu identifikuje možný (a povinný) název elementu v XML dokumentu spolu s možnostmi jeho obsahu a spolu s následnou hierarchií podřízených elementů. 15

16 základy xml strana 16/34 Syntaxe deklarace typu elementu: <!ELEMENT název (obsah)... > kde název označuje možný (povolený a přitom povinný) název elementu v XML dokumentu, obsah označuje buď seznam názvů následných podřízených prvků anebo označení pro ukončení hierarchie (list stromu). Pokud již nemá mít element další podřízené prvky a má pouze svůj text, do závorky obsah se umisťuje výraz #PCDATA. Například takto deklarovaný prvek titul nemá mít již další podřízené prvky: <!ELEMENT titul(#pcdata)> a oproti tomu <!ELEMENT barvy(barva)*> značí, že element barvy má obsahovat N elementů barva Speciální znaky pro ELEMENT deklarace Existují speciální znaky pro vztah parent a child elementů: apostrof - striktní pořadí? optional + jeden nebo více * nula nebo více jeden z několika ( ) skupina Příklad <!ELEMENT kniha(titul,autor,cena?,..)> znamená, že element cena jako child element elementu kniha není povinným podřízeným elementem elementu kniha. Deklarace atributu Deklarace atributu umožňuje identifikovat: které elementy mají atributy jaké atributy tyto elementy mají jaké hodnoty mohou tyto atributy mít a jaké jsou implicitní hodnoty těchto atributů Deklarace atributu obsahuje tyto části: název elementu název atributu typ atributu 16

17 základy xml strana 17/34 a implicitní hodnotu Syntaxe deklarace atributu je následující: <!ATTLIST název_element název_atribut typ implicit...> Například kniha má atribut titul <!ATTLIST kniha titul...> Jako příklad deklarace atributu pro HTML kód bychom mohli uvést klasický element tagu A - odkazu: <!ELEMENT A(#PCDATA)> <!ATTLIST A HREF...> čímž jsme vyjádřili, že tag - tj. element A je konečným elementem bez podřízených elementů a element A má atribut HREF. Možný povolený element A v XML dokumentu (který nevede k error při validaci XML dokumentu): <A HREF= default.htm >domů</a> Deklarace možného typu atributu Existuje 6 možných typů atributů: CDATA ID IDREF nebo IDREFS ENTITY nebo ENTITIES NMTOKEN nebo NMTOKENS Seznam možných hodnot Atribut deklarovaný jako CDATA Atribut deklarovaný v DTD jako CDATA může v XML dokumentu obsahovat libovolný string. Atribut je určen pouze pro informaci hodnoty tohoto stringu. (příklad barva má svůj kód jako atribut) Atribut deklarovaný jako typ ID Atribut deklarovaný v DTD jako typ ID nese jednoznačný název - identifikátor vůči všem jiným atributům v celém dokumentu (unikátní vůči úplně všem ID v celém dokumentu). Element díky atributu typu ID může získat jednoznačný identifikátor mezi všemi ostatními elementy. Poznámka: Metoda objektu XML dokumentu DOM umožňuje přístup k elementu přes tento identifikátor. Příklad: <!ATTLIST kniha kniha_id ID> elementy kniha budou mít atribut typu ID s názvem kniha_id Atribut deklarovaný jako IDREF nebo IDREFS Atribut deklarovaný jako IDREF musí obsahovat jednu z hodnot atributů, který byl deklarován jako ID kdekoliv jinde. IDREF tedy zprostředkovává odkaz na jeden z elementů pomocí hodnoty atributu typu ID. V HTML je tento přístup podobný pomocí odkazu názvu elementu A tj. atributu name. Viz příklad 5. 17

18 základy xml strana 18/34 Pokud je deklarován atribut jako IDREFS, může obsahovat několik odkazů oddělených mezerou. Poznámka: DTD takto umožňuje v dokumentu zavádět vazby mezi elementy a to jedna k jedné (ID a IDREF) a jedna ku N (ID a IDREFS).Význam ID a IDREF je podobný jako je použití systémového klíče ID ve vazbách v tabulkách, pouze se chápe,jako jednostranný vztah (IDREF ukazuje hodnotou na element, který má ID s hodnotou IDREF) Příklad: <!ATTLIST kniha nakladatel_id IDREF...> V atributu knihy nakladatel_id musí být umístěn nějaké ID deklarované jinde (v tomto případě bude mít nakladatel své ID a daná kniha má jeho ID přes IDREF). Atribut deklarovaný jako ENTITY nebo ENTITIES Hodnota atributu typu ENTITY musí být jedna z deklarovaných v tzv. ENTITY deklaraci - tato deklarace viz dále. Tímto se váže daný ELEMENT k dané ENTITY, resp. několika ENTITIES (oddělovačem u několika ENTITIES je mezera). Atribut deklarovaný jako NMTOKEN nebo NMTOKENS Atribut takto deklarovaný má hodnotu stringu, ale jeho možná hodnota je omezena na jednoduché slovo. Atribut deklarovaný jako seznam možných hodnot Deklarace obsahuje seznam možných hodnot atributu a případně implicitní hodnotu. Seznam možných hodnot se umisťuje za název atributu do závorky, oddělovačem je svislice. Případná implicitní hodnota se umístí za závorku do uvozovek: <!ATTLIST název_element název_atribut ( hodnota hodnota...) implicit hodnota > Příklad <!ATTLIST cena měna (Kč Sk) Kč > Implicitní nastavení atributů Existují čtyři možné default nastavení pro vlastnosti atributu: #REQUIRED - atribut musí mít přiřazenu hodnotu v dokumentu, není přípustný stav nezadán #IMPLIED - atribut není vyžadován a také nemá default hodnotu #FIXED hodnota - atribut není sice vyžadován, avšak pokud se vyskytne, musí mít konstantní hodnotu. Deklarace ENTITY Deklarace ENTITY umožňuje propojit určitý název s určitou nějakou jinou obsahovou částí. Touto obsahovou částí může být Kousek textu Kousek DTD deklarace Jiný externí soubor obsahující text nebo binární data Existují tří druhy ENTITY 18

19 základy xml strana 19/34 Interní entity Interní entity umožňují provést odkaz na určitý text: <!ENTITY OBJECON "Object Consulting"> umožňuje kdekoliv použít odkaz pomocí &OBJECON; a na toto místo dojde k dosazení hodnoty textu Object Consulting Externí entity Externí entity značí odkaz na externí soubor obsahující buď text anebo binární data. Syntaxe je <!ENTITY název SYSTEM zdroj NDATA typ_dat > Pokud zdroj (soubor) obsahuje text a část deklarace NDATA se nevyskytuje, potom dojde k dosazení tohoto textu na místo odkazu. Takto lze jednoduchým způsobem sdílet části XML dokumentů (obdoba include). Pokud zdroj obsahuje binární data, potom v části NDATA je deklarována informace o typu dat (bude pojednáno dále). Důležité je, že název ENTITY s binárním zdrojem se může použít pouze přes odkaz tj. jako hodnota atributu typu ENTITY (viz kapitola atribut deklarovaný jako ENTITY). Parametrické entity Existuje ještě možnost sdílení deklarací pomocí tzv. parametrických entit. Syntaxe pro zavedení parametrické entity je pomocí znaku %: <!ENTITY %nazev_par_entity...> Pokud zavedeme takto parametrickou entitu, můžeme element deklarovat pomocí parametrické entity, tj. odkázat se na ni v deklaraci takto: <!ELEMENT nazev (%nazev_par_entity;)*> a tím využít již hotové deklarace. Několik různých elementů s různými názvy může být deklarováno pomocí jedné parametrické entity (mají až na název stejnou deklaraci). Deklarace NOTATION Deklarace NOTATION slouží k identifikaci speciálních typů externích binárních souborů. Syntaxe <!NOTATION nazev_notation SYSTEM typ> Podobně jako u binární entity, kde název této entity mohl vystupovat v referenci přes atribut, také zde se název daného notation objeví jako hodnota některého z atributu typu NOTATION. Příklad: <!ELEMENT logo EMPTY> <!NOTATION gif SYSTEM file:///c:/...iexplore.exe > 19

20 základy xml strana 20/34 <!NOTATION jpg SYSTEM file:///c:/...iexplore.exe > <!ATTLIST logo img ENTITY #REQUIRED format NOTATION (gif jpg) #REQUIRED> <!ENTITY obr.gif SYSTEM http...gif NDATA gif> Popis příkladu - je deklarováno že existuje element logo a je prázdným že existují typ binárních dat gif a jpg že element logo bude mít atributy img typu ENTITY a atribut format typu NOTATION a že nakonec existuje ENTITY obr.gif se zdrojem (souborem) na cestě a v implementaci v XML dokumentu konkrétně vyhovuje takovýto element: <logo img= obr.gif format= gif /> Poznámka: Příklad je pro vysvětlení názorný, je třeba si uvědomit, že takto zaveden je vztah mezi logem, názvem obrázku, zdrojem v konečné implementaci je takříkajíc natvrdo Namespaces Uveďme si příklad, který objasňuje nutnost zavést tzv. namespaces: V jednom XML dokumentu se objeví následující část dokumentu: <kniha> <titul>základy OOP<titul>... </kniha> a v druhém XML dokumentu <osoba> <titul>rndr.<titul>... </osoba> Je zřejmá kolize v chápání různých elementů které však mají stejný název - titul. Pokud bychom sloučili informace z těchto dvou dokumentů, nastala by kolize. Je zřejmé, že pokud by oba dokumenty psala tatáž osoba resp. kolegové ze stejného týmu, potom by se této kolizi dalo vyvarovat. Je nemožné se však takto vyvarovat této kolizi na Internetu - nelze totiž dopředu předjímat kdo a kdy jaké elementy použije. Řešení tohoto problému spočívá v zavedení tzv. namespaces a ty souvisí s pojmem URI - Uniform Resource Identifiers. 20