Tallinna Pedagoogikaülikool
Matemaatika-informaatika osakond

Laiendatav märgendikeel XML
Proseminaritöö

Juhendaja: Jaagup Kippar
Autor: Liivi Haamer, RIF-31

Tallinn 2001

Sisukord
Sisukord	2
Eessõna	5
XML sissejuhatus	6
Märgendikeelte ajalugu	6
XML-i parserid	7
Redaktorid XML-i kasutamiseks	7
XML-i rakendusvõimalused	7
XML-i eesmärgid	8
XML-i struktuur	9
Loogiline struktuur	9
Proloog	9
XML deklaratsioon	10
XML dokumendi tüübideklaratsioon	10
Dokumendi juurelement	11
XML süntaks	11
Elemendid	11
XML on tõstutundlik:	12
Alam-elemendid	12
Elementide pesitsemine (nesting)	12
Kommentaarid	13
Atribuudid	13
Eriatribuudid	14
XML:space	14
XML:lang	14
Atribuutide kasutamise eripärad	15
CDATA	15
Töötluseeskirjad (PI)	16
XML dokumendi põhireeglid	16
Trimmis (well-formed) XML dokumendid	16
Kehtivad (valid) XML dokumendid	16
XML dokumentide kirjeldamine DTD-ga	17
Sissejuhatus DTD-sse	17
DTD defineerimine	18
DTD struktuur	18
Elementide deklareerimine	20
Reeglid elemendi nimede defineerimisel:	20
Reeglid elementide deklareerimisel	20
Elementide grupeerimine, esinevus ja sümbolid	21
Atribuutide deklareerimine	21
Atribuutide tüübid	21
Olemite (ENTITIES) deklareerimine	23
Üldised (dokumendisisesed) olemid	23
Dokumendivälised olemid	24
Parameetrilised olemid	25
Teised DTD võtmesõnad	26
IGNORE ja INCLUDE	26
Kommentaarid	26
XML dokumentide kirjeldamine skeemidega (XML Schema)	27
Sissejuhatus XML skeemidesse	27
XML skeemi komponendid ja omadused	27
Nimeruumide (Namespace) kasutamine	29
Mitme XML skeemi kasutamine	30
Komplekstüüpide (Complex Type) definitsioonid	31
Eksisteerivate tüübidefinitsioonide kasutamine	32
Lihttüübi definitsioon	32
Piirangud (Facets)	34
Atribuudid	35
Sisuatribuut	35
Grupid	36
Pärinevus	37
Annotatsioonid	38
XML skeemide võrdlus DTD-ga	38
XSL laiendatav stiilide keel	39
XSL sissejuhatus	39
XSL stiililehtede kasutamine	39
XSL stiililehed	41
Andmete leidmine mustrite (pattern) abil	41
Informatsioonimeetodid	42
Operaatorid	43
XSL käsustik	44
Lõppsõna	45
Viited kasutatud materjalidele	46

Eessõna
Aeg-ajalt leiavad arvutitööstuses aset suured entusiasmi ja aktiivsuse puhangud ja seda seoses mõne uue produkti või rakenduse sünniga. Mõne viimase aasta jooksul on selliseks puhanguks põhjust andnud uue standardi XML (Extensible Markup Language – laiendatav märgendikeel) loomine, millest on loodetud abi väga suure hulga tarkvaraliste probleemide lahendamisel. XML-i on peetud universaalseks andmete keeleks, tema sündi loetud WWW kontekstis isegi nn "teiseks Webi revolutsiooniks" (esimeseks peetakse Java sündi).

XML sissejuhatus
Märgendikeelte ajalugu
Ametlik märgendikeelte sünd leidis aset hilistes 60ndates, kui Charles Goldfarb töötades ühe IBM dokumentide automatiseerimisprojekti kallal, defineeris termi "märgendikeel". See inspireeris automatiseeritud dokumentide, kui üldise lähenemise väljatöötamist ning viis SGMLi – standartse üldise märgendikeele loomisele 70ndatel aastatel. SGML on iseenesest meta-keel, mis defineerib märgendikeelte ning dokumendi tüübikirjeldus keelte süntaksi. ISO standardiks sai SGML 1986-l aastal. Sellel perioodil tekkisid ka sellised keeled nagu TEX ja LATEX. 1989 – Webi leiutamise aastal – lõi Tim Berners-Lee HTML-i, mis oli SGMLi struktuuriga ja mille semantika oli inspireeritud LATEXi keskkonnast. Eelmiste dokumendi tüübi definitsioonidega võrreldes, oli HTML-i peamine erinevus linkimise mehhanism, mis võimaldas dokumente ka üle Interneti siduda. Vannevar Bushi ja Theodor Nelsoni töödest tekkis hüperteksti idee, mille Theodor Nelson hiljem defineeris kui termi. Algselt puudus HTML-is täielikult kontroll dokumendi väljanägemise üle, dokumendi küljendus jäi puhtalt WWW sirvija ülesandeks.

Varastel 90ndatel kasvas järsult Webi kasutamine ja samamoodi ka HTML-i kasutamine algselt temale mitte mõeldud kontekstis. Keelele esitatud nõudluse kasvades lisati sellele toetus interaktsioonile, matemaatilisele notatsioonile, metaandmetele, multimeediale ning navigatsioonile. Sellest tulenes HTML-i peamine probleem – dokumendi sisu on segu struktuuri ning esitluse märgistustest, mis aga oli vastuolus SGMLi disaini filosoofiaga. Selge struktuuri puudumine ning peamiselt küljendusele suunatud semantika tegi dokumendi automaatse indekseerimise ning otsimise ebatäpseks. Lisaks vaatamata HTML-i laiendustele ei suutnud keel ikkagi täita temale esitatud nõudeid. WWW arhitektuuri laiemas kontekstis hakkas HTML muutuma takistuseks nii arendamise kui ka inforamtsiooni esitamise ja kommunikeerimise mõttes.
SGMLi keerulisus takistas selle otsest kasutamist Webis ning seetõttu tekkis nõudlus lihtsamate standardite järele. See viiski spetsiaalse projektigrupi loomisele W3Cs, kes andis 1998 aastal välja XML 1.0 spetsifikatsiooni.
Kõige uuemat informatsiooni XML-i kohta saab kodulehelt: http://www.w3c.org/xml.
XML-i parserid
Selleks, et XML dokumenti lihtsalt programmselt töödelda on tarvis XML parserit.
XML-i parserid on valmisprogrammeeritud teegid XML dokumentidega erinevate operatsioonide sooritamiseks. Kasutusel on põhiliselt kaks erinevat lähenemist. Sax (simple api to XML) tüüpi parserid on mõeldud XML dokumendi ridahaaval läbimiseks ning põhinevad sündmustepõhisel objektmudelil. DOM (document object model) tüüpi parserid ehitavad mällu objektmudeli tervest XML dokumendist, mille kasutamine on väga sarnane näiteks HTML dokumendi objektmudelile. DOM mudeli eelisteks on universaalsus ning võimalus dokumenti muuta, miinusteks suur ressursinõudlus.
Redaktorid XML-i kasutamiseks
XML-i kirjutamiseks ja lugemiseks pole vaja põhimõtteliselt enamat kui tavaline tekstiredaktor. Samas pole sellise tööriista kasutamine alati kõige mugavam, seda tõestab erinevate XML-i spetsiifiliste redaktorite järjest kasvav hulk. Tavaliselt võimaldavad need redaktorid XML dokumenti "graafiliselt" ehk siis hierarhilise puu kujuna vaadelda ning redigeerida, kasutusel on graafilised sümbolid elementide, atribuutide, kommentaaride ning andmete tähistamiseks. Arenenumad redaktorid oskavad ka dokumenti valideerida ning kontrollida vastavust DTDle. PC/Windows platvormil võiks nimetada näiteks XML Spy.
XML-i rakendusvõimalused
XMLi kunagisest põhieesmärgist – andmete kirjelduskeel WWW rakenduste jaoks on välja kasvanud universaalse andmekirjeldus ning -edastus keele idee. Ühe enam kasutatakse XMLi ärirakendustes süsteemi erinevate osade vahel informatsiooni vahetamiseks, samuti suhtlemiseks teiste süsteemidega. Arvutimaailma igivana probleem – andmeformaatide mitteühilduvus saab XMLi ning XML skeeme kasutades suhteliselt lihtsa lahenduse. Kuna XML andmeid hoitakse tekstikujul on neid lihtne vahetada paljude erinevate platvormide vahel taskuarvutist suurte serveriteni – tavaline tekstitöötlus on neile kõigile jõukohane.

XMLi skeemide suuri keskseid andmebaase kasutades saame lahenduse ka teisele igivanale probleemile – isegi kui me suudame erinevate platvormide ning rakenduste vahel andmeid vahetada on rakendustel raskusi "üksteise mõistmisega". Pole kindlaks määratud andmete semantika ning seetõttu tuleb tihtipeale iga kord kahe andmeid vahetava süsteemi jaoks kirjutada spetsiaalsed transleerijad mis on suuresti sõltuvad konkreetse rakenduse andmemudelist.
XML-i eesmärgid
•	XML peab olema hõlpsasti loetav nii inimesele kui arvutile. 
•	XML rakenduste ampluaa peab olema võimalikult lai: sisestamine, lehitsemine, otsing, infotöötlus, sisutöötlus.
•	XML dokumentide töötlemise programme peab olema lihtne kirjutada.
•	XML dokumentide disainimise protsess ei tohi olla pikk. 
•	XML disain peab olema formaalne ja kompaktne.
•	XML dokumentide genereerimine peab olema lihtne. Kuigi XML dokumentide koostamiseks kasutatakse enamasti spetsiaalseid redaktoreid, peab nende tekitamine olema võimalik mistahes redaktoriga.
•	XML märgistuse napisõnalisuse nõue pole tähtis.

XML-i struktuur
Igal XML dokumendil on loogiline ja füüsiline struktuur. Loogilist struktuuri võib kirjeldada kui dokumendi kirjeldavat raamistikku (framework). Füüsiline struktuur on määratud andmetega, mida XML dokument sisaldab.
Loogiline struktuur
Iga XML dokument koosneb kolmest loogilisest osast: proloogist, dokumendi elemendist ja epiloogist, millest viimane leiab harva kasutamist.
XML dokument lõppeb sulgeva juurmärgendiga, st eraldi märgendit dokumendi lõpu märkimiseks pole.
XML dokumendi näide:

<?xml version="1.0"?>
<!DOCTYPE CONTACT_INFO SYSTEM "Contacts.dtd">
<CONTACT_INFO>
<CONTACT TYPE="bussiness">
	<NAME>
		<FIRST_NAME>Ott</FIRST_NAME>
		<LAST_NAME>Karu</LAST_NAME>
	</NAME>
	<ADDRESS>
		<STREET_INFO>Metsa puiestee 6</STREET_INFO>
		<CITY>Tallinn</Tallinn>
		<ZIP>10111</ZIP>
	</ADDRESS>
	<PHONE>666-6666</PHONE>
</CONTACT>
</CONTACT_INFO>
Proloog
Proloogi kasutamine on rangelt soovituslik, kuna selle eesmärgiks on anda XML parserile informatsiooni dokumendi ja selle sisu kohta. Proloog koosneb kahest osast: XML deklaratsioonist ja dokumendi tüübi deklaratsioonist (eelnevas näites kaks esimest rida). XML deklaratsioon ütleb parserile, et tegu on XML dokumendiga. Dokumendi tüübi deklaratsioon viitab täiendavatele erireeglitele, mis võivad olla vajalikud dokumendi andmetele. Dokumendi tüübideklaratsioon on aluseks dokumendi kehtivaks tunnistamisel. Proloog võib sisaldada ka atribuute.
XML deklaratsioon
XML deklaratsioon määrab kasutatava XML versiooni.

<?xml version="1.0"?>

Tema asukoht on dokumendi kõige esimesel real. Atribuut "version" on alati nõutav. Kasutatakse ainult väikeseid tähti ja atribuudi sisu ei tohi sisaldada tühikuid. Ka XML deklaratsiooni eraldajad on tavapärastest erinevad <?…?/>. XML deklaratsioonis võib lisaks versiooni atribuudile leiduda veel täiendavaid atribuute: 

<?xml version="1.0" encoding="UTF-16" standalone="yes"?>

encoding – ütleb parserile millist unicode formaati kasutada. Vaikimisi kasutatakse "UTF-8".
standalone – edastab parserile kas dokument on tunnistatud kehtivaks iseseisvalt või nõutav väline DTD või XML skeem (Schema).
XML dokumendi tüübideklaratsioon
XML dokumendi tüübideklaratsioon sätestab kogu dokumendiklassi grammatika, mida nimetatakse dokumendi tüübidefinitsiooniks ehk DTDks (document type definition). Tema asukoht on vahetult peale XML deklaratsiooni ja kindlasti enne dokumendi juurelementi. 

<?xml version="1.0"?>
<!DOCTYPE CONTACT_INFO SYSTEM "Contacts.dtd">
<CONTACT_INFO>

Tuleb tähele panna, et tüübideklaratsioonis kasutatakse samuti erinevaid eraldajaid <!…>.
Näites leiduv võtmesõna DOCTYPE ütleb parserile, et dokumendi elemendi nimi on Contacts ja tüübidefinitsioon asub lokaalses süsteemis failis nimega Contacts.dtd (sellele viitab sõna SYSTEM).
Dokumendi juurelement
XML doukmendi andmed sisalduvad kõik ühes juurelemendis. Dokumendil saab olla ainult üks juurelement, kuid see võib omada kui palju tahes alamelemente. Näites on juurelemendiks <CONTACT_INFO>. Viimane rida defineerib juurelemendi lõpu </CONTACT_INFO>.
XML süntaks
•	XML kasutab sarnaselt HTML-i ja SGML-ga eraldajatena märke (<…>)
•	Iga avamärgendiga kaasneb sulgemismärgend
•	Atribuutide väärtused on jutumärkide vahel
•	XML elemendid on tõstutundlikud
•	Elementide ja atribuutide nimed peavad algama tähe või alakriipsuga.
Elemendid
Nagu juba varem mainitud on XML dokumendil üks ja ainuke juurelement, mis on ülemelemendiks kõikidele teistele elementidele.
Elemendid piirnevad algus- ning lõpumärgenditega ja koosneb kolmest osast: algusmärgend, sisu, lõpumärgend. 

<NAME>Ott</NAME>

Element, mis ei oma sisu koosneb ainult algus ja lõpumärgendist või ainult algusmärgendist, mis lõppeb kurakaldkriipsuga:
 
<NAME/>

Elemendi nimi sisaldab vähemalt ühte tähte: a kuni z, A kuni Z. Suured ja väikesed tähed loetakse erinevaks. Nimi võib alata ka sümboliga (_) või (:). Algustähele (või alajoonele) võib järgneda üks või mitu tähte, numbrit, sidekriipsu, punkti, unicode tähte. Nimel peaks olema tähendus. Kõik XML elemendid peavad olema esitatud õiges järjekorras:

<B><I> Bold and Italic </I></B>

XML on tõstutundlik:
<NAME>Ott</name> - ebakorrektne
<NAME>Ott</NAME> - korrektne

Alam-elemendid
Iga element, mis hargneb juurelemendist on alamelement.
Alamelemendid võivad olla nelja erinevat tüüpi, kus elemendi sisu koosneb:
ainult alamelementidest, ainult tekstist, alamelementide ja teksti kooslusest või on tühi.
Elementide pesitsemine (nesting)
XML elemendid võivad pesitseda teiste XML elementide sees, millest kokku moodustub XML dokumendi "puu". Reeglid, pesitsemise järjekorra kohta on väga rangelt määratletud. 

Korrektne järjestus:

<tree>
	<branch>
		<nest>
<bird>
	<feather>…</feather>
	<feather>…</feather>
</bird>
			</nest>
		</branch>
	</tree>
Ebakorrektne järjestus:

<tree>
	<branch>
		<nest>
<bird>
	<feather>…</feather>
	<feather>…
</nest>
	</feather>
			</branch>
				</bird>
	</tree>	
Kommentaarid
<!—- kommentaari algus
--> kommentaari lõpp

Kommentaare võib paigutada igale poole väljaspool märgendeid. Kommentaari ei tohi panna stringi.
Atribuudid
XML elemendid võivad omada atribuute, mis kaasatakse algusmärgendisse. Neid kasutatakse elementide täiendavaks kirjeldamiseks või varustamiseks lisainformatsiooniga. Atribuutide väärtused peavad alati olema kas apostroofide või jutumärkide vahel.

<CONTACT TYPE="bussiness">
	<NAME>
		<FIRST_NAME>Ott</FIRST_NAME>
		<LAST_NAME>Karu</LAST_NAME>
	</NAME>
</CONTACT>

Kui on vajadus kasutada jutumärke teksti sees, siis on lubatud selleks kasutada apostroofe, kuid kõige kindlam on need siiski kirjeldada koodina:

‘"Rich&apos;s string must escape the apostrophy", he said’ 

Atribuudid varustavad tihti vajaliku infoga XML-i grammatiliselt analüüsivat aplikatsiooni, elemendisiseste andmetega neil side tavaliselt puudub, st atribuut kirjeldab elementi, mitte tema sisu. Selline info võib olla kasulik aplikatsioonile, mis elementide endaga opereerib. Näiteks:

<file type="gif">computer.gif</file>
Eriatribuudid
XML:space
XML-dokumentide toimetamisel on sageli vajadus käsitleda "tühiruumi" (tühikuid, tabulaatoreid, tühje ridasid) eraldi märgistusest. Et tühiruum edastavas dokumendiversioonis säiluks, võib lisada erilise xml:space atribuudi. 
XML:lang
Dokumendi töötlemisel on sageli kasulik identifitseerida sisu kirjutamiseks kasutatud loomulik keel. Kehtivas dokumendis peab see atribuut, nagu mistahes teine atribuut, olema tema kasutamise korral deklareeritud. Keele koodi on kombeks esitada väiketähtedega, riigi koodi suurtähtedega. Erinevalt teistest XML-dokumendi nimedest, on need väärtused tõstutundetud. Deklareering rakendub kõigile atribuutidele ja elemendi sisule, kus ta on spetsifeeritud, kuni ta pole üle defineeritud antud elemendi sisus paikneva mingi teise elemendi xml:lang eksemplariga.

	<systemPrompt>
		<color xml:lang="en-GB">Choose a colour</color>
		<color xml:lang="en-US">Choose a color</color>	</systemPrompt>

Siiski tuleb xml:lang atribuudi kasutamisel olla ettevaatlik, kuna XML rakendused ei ole kohustatud seda realiseerima.
Atribuutide kasutamise eripärad 
•	Atribuudid ei tohi sisaldada mitut väärtust (elemendid võivad) 
•	Atribuute ei ole kerge laiendada
•	Atribuudid ei kirjelda struktuuri (alam-elemendid kirjeldavad) 
•	Atribuute on programmikoodi poolt natukene raskem kasutada 
•	Kui kasutada atribuute andmete hoidmiseks, viib see tavaliselt raskesti loetavate ning hallatavate dokumentideni, nagu võib näha järgnevas näites:

<note day="15" month="03" year="01"
to="Ott" from="Triinu" heading="Greeting"
body="Hello Ott!" />
CDATA
CDATA-sektsioonid võivad esineda kõikjal, kus võib esineda märkandmeid (näit "<" või "&" programmikoodis). Kõik, mis sisaldub seespool CDATA sektsiooni ignoreeritakse parseri poolt. CDATA-sektsioonid algavad stringiga  "<![CDATA[" ja lõpevad stringiga "]]>". Siit lähtuvalt ]]> kombinatsiooni CDATA ise sisaldada ei tohi.

Lubamaks atribuutide väärtustes erimärkide sisaldumist, võib ülakoma (') esitada kujul "&apos;" , jutumärki (") kujul "&quot;" ja ampersandi (&) kujul "&amp;" 

Näide, kus "<greeting>" ja "</greeting>" tuvastatakse märkkandmetena mitte märgenditena: 

<![CDATA[<greeting>Hello, world!</greeting>]]>

Töötluseeskirjad (PI)
Töötluseeskirjad PI (processing instructions) lubavad dokumentides anda rakendustele eeskirju nende töötlemiseks.
PId ei ole osa dokumendi märkandmetest, aga nad peab antama üle rakendusele. PId algavad sihtmärgiga, mis identifitseerib rakenduse, millele see eeskiri on suunatud. Standariseerimise eesmärkidel on käesoleva spetsifikatsiooni praeguses või tulevikuversioonides sihtmärgi nimed "XML", "xml" ja teised sarnased reserveeritud. PI sihtmärgi formaalseks deklareerimiseks võib kasutada XML-notatsiooni mehhanisme.
XML dokumendi põhireeglid
Kokkuvõtvalt võib öelda, et andmeobjekt on XML dokument, kui ta on trimmis. Trimmis XML dokument võib olla lisaks kehtiv, kui ta vastab kindlatele lisapiirangutele.
Trimmis (well-formed) XML dokumendid
•	Dokument järgib XML struktuuri põhireegleid
•	Dokument tervikuna vastab XML süntaksi reeglitele.
•	Dokument arvestab kõiki trimmisuse piiranguid. 
•	Iga analüüsitud üksus (parsed entities), millele viidatakse vahetult või kaudselt dokumendis, on trimmis.
Kehtivad (valid) XML dokumendid
•	Dokument on trimmis
•	Dokument vastab XML dokumendi tüübideklaratsiooni reeglitele
•	Ta sisaldab ühte või mitut elementi
•	Eksisteerib üks ja ainult üks element, mida nimetatakse juurelemendiks.

XML dokumentide kirjeldamine DTD-ga
Sissejuhatus DTD-sse
Nagu juba eelnevast teame, viitab või sisaldab XML dokumendi tüübideklaratsioon dokumendi tüübidefinitsioonile (DTD-le), millega määratakse kogu dokumendiklassi garmmatika. Dokumendi tüübidefinitsioon võib viidata välisele märgendite deklaratsioone sisaldavale alamhulgale, sisaldada deklaratsioone vahetult sisemises alamhulgas või ta või esitada mõlemate mooduste kombinatsiooni. Dokumendi DTD moodustavad mõlemad alamhulgad kokkuvõetuna. Need deklaratsioonid on spetsiaalsed märgid, mis defineerivad XML dokumendi struktuuri, st määravad kindlaks millised elemendid on nõutavad ja milline on elementide järjestuse kord. Kui XML dokument on vastavuses loodud tüübidefinitsiooni spetsifikatsiooniga, siis on XML dokument ka kehtiv.

Järgnevalt näited, kus esimeses kasutatakse sisemist DTD-d ja teises viidatakse välisele tüübidefinitsioonile:
Sisene:

<?xml version="1.0"?>
<!DOCTYPE greeting [
	<!ELEMENT greeting (#PCDATA)>
]>

<greeting> Hello World! </greeting>

Väline:
<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "HELLO.DTD">

<greeting> Hello World! </greeting>
DTD defineerimine
Tuletame meelde XML dokumendi struktuuri, kus dokument algab on proloogiga ja alles seejärel tulevad dokumendi juurelement ja alamelemendid. 
Proloogist leiame olemi DOCTYPE, mis võib olla privaatne või avalik. Privaatsele tüübile viitab võtmesõna SYSTEM, avalikule tüübile võtmesõna PUBLIC.

<?xml version="1.0"?>
<!DOCTYPE Presidents SYSTEM "Prez.DTD">

<!DOCTYPE AutoParts PUBLIC "-//AutoCo//DTD//EN"
	"http://xmlserver.AutoCo.com/dtd/AotoParts.dtd">

Dokumendi sisest tüübidefinitsiooni kasutatakse väiksemates süsteemides ja testimise või arendusfaasis. Dokumendi väline DTD on tavaliselt kasutusel juhul, kui erinevad süsteemid peavad XML andmeid vahetama. Seda võidakse kasutada ka paljudes, juba töös olevates aplikatsioonides, kus kontseptsiooni ja komponentide eraldamine hõlbustab dokumenteerimist ja süsteemi hooldust.
Kui sisene ja väline DTD on korraga kasutusel, töödeldakse kõigepealt sisemist DTD-d, ning temas sisalduv tüübikirjeldus on välise DTD kirjeldusest prioriteetsem.
DTD struktuur
DTD põhistruktuur on ülalt-alla hierarhiaga erinevate XML dokumentide erinevate elementide kirjeldus. St, et DTD-d töödeldakse ülalt-alla ja ülemelemendid, mis sisaldavad alamelemente, peavad olema defineeritud enne alamelemente. Iga element esineb elemendi deklaratsioonis järgmises formaadis:

<!ELEMENT elementname rule>

Järgnevalt vaatame ühte lihtsat XML dokumenti ja sellega kaasnevat DTD-d

XML:
<?xml version="1.0"?>
<!DOCTYPE ARTICLE SYSTEM "example1.dtd">

<ARTICLE>
<HEADLINE>
	<MAIN_HEAD>Main headline goes here</MAIN_HEAD>
	<SUB_HEAD>A subheadline goes here</SUB_HEAD>	</HEADLINE>
<BYLINE>
	<AUTHOR>Triinu Lepa</AUTHOR >
	<TITLE>Reporter</TITLE>
</BYLINE>
<STORY_DATE>20. märts 2001</STORY_DATE>
<BODY>
	Content of story goes here…
</BODY>
</ARTICLE>

DTD:
<!ELEMENT ARTICLE (HEADLINE, BYLINE, STORY_DATE, BODY)>
<!ELEMENT HEADLINE (MAIN_HEAD, SUB_HEAD)>
<!ELEMENT MAIN_HEAD (#PCDATA)>
<!ELEMENT SUB_HEAD (#PCDATA)>
<!ELEMENT BYLINE (AUTHOR, TITLE)>
<!ELEMENT AUTHOR (#PCDATA)>
<!ELEMENT TITLE (#PCDATA)>
<!ELEMENT STORY_DATE (#PCDATA)>
<!ELEMENT BODY (#PCDATA)>

Nagu näitest võib näha, sisaldab juurlement ARTICLE komadega eraldatuna nelja alamelementi:

<!ELEMENT ARTICLE (HEADLINE, BYLINE, STORY_DATE, BODY)>

Mõned neist alamelementidest sisaldavad omakorda alamelemente:

<!ELEMENT HEADLINE (MAIN_HEAD, SUB_HEAD)>

Need elemendid, mis sisaldavad ainult andmeid, deklareeritakse veidi erinevalt:

<!ELEMENT MAIN_HEAD (#PCDATA)>
Elementide deklareerimine
Iga element, mis esineb elemendi deklaratsioonis peab olema defineeritud DTD-s.
Reeglid elemendi nimede defineerimisel:
•	Elemendi nimi peab algama tähe või alakriipsuga
•	Elemendi nimi ei tohi alata stringiga XML (ei väikeste ega suurte tähtedega)
•	Elemendi nimi võib sisaldada numbreid, tähti, alakriipse, kaldkriipse jne
•	Elemendi nimi ei tohi sisalda tühikuid
•	Koolon XML elemendi nimes on reserveeritud eksperimentideks nimeruumiga. Tema tähendus kavatsetakse standardiseerida mingil tulevikuhetkel, millest alates need dokumendid, mis sisaldavad eksperimentaaleesmärkidel koolonit, võivad vajada uuendamist. Praktikas tähendab see seda, et koolonit XML nimedes kasutada ei tohiks, XML parserid peaksid koolonit nimemärgina aktsepteerima.
Reeglid elementide deklareerimisel
•	Deklaratsioon ANY – element võib sisaldada ükskõik mida või ka mitte midagi
•	Deklaratsioon EMPTY – elemendid ei tohi sisaldada andmeid, kuid võivad sisaldada atribuute
Segadeklaratsioon (Mixed) – sisaldab loetelu valikutest, eraldajatena kasutatakse püstkriipsu
•	Mitmikdeklaratsioon (Multiple) – lubab alamelementide esinemist, kusjuures oluline on järjekord. Loetelu vahel kasutatakse komasid.
•	Deklaratsioon #PCDATA – elemendid võivad sisaldada tavalist teksti, kuid mitte spetsiaalseid XML märke, näit "<".

Elementide grupeerimine, esinevus ja sümbolid
Elementide deklareerimise juures kasutatakse mitmeid sümboleid ja operaatoreid. Mõningad neist on järgnevas tabelis:

Sümbol	Kirjeldus	Näide	
Sulud (  )	Sulustab elementide jada või alternatiivid	(ElementA | #PCDATA)	
Koma ,	Elementide jada eraldaja, tähtis järjekord	(ElementA, ElementB)	
Püstkriips |	Eraldab alternatiivseid elemente	(ElementA | #PCDATA)	
Küsimärk ?	Element võib esineda 0 või 1 kord	ElementA?	
Tärn *	Element võib esineda 0 või mitu korda	ElementA*	
Pluss +	Element võib esineda 1või rohkem korda	ElementA+	
Ilma sümbolita	Element võib esineda ainult 1 kord	ElementA	

Näiteks deklareerime elemendi EMAIL:

<!ELEMENT EMAIL (To+, From, CC*, Subject?, Body?)>
Atribuutide deklareerimine
Nagu juba eelnevast teame võivad atribuudid esineda kõikjal DTD-s. Mõistlik on hoida nad samas piirkonnas elementidega, kuna see parandab loetavust ning kergendab paranduste tegemist. 
Süntaks atribuutide defineerimisel on järgmine:

<!ATTLIST element-name attribute-name attribute-type default-value>
Atribuutide tüübid
Tüüp	Kirjeldus	
CDATA	Väärtus on teksti tüüpi	
ENTITY	Väärtus peab viitama välisele olemile ja olema deklareeritud DTD-s	
ENTITIES	Loetelu välitest olemitest, mis on eraldatud tühikutega	
ID	Unikaalse elemendi identifikaator	
IDREF	Unikaalse ID väärtus	
IDREFS	Sama, mis eelmine. Väärtused peavad olema eraldatud tühikutega	
NMTOKEN	Väärtus vastab XML nime standardile	
NMTOKENS	Loetelu XML kehtivatest nimedest, mis on eraldatud tühikutega	
NOTATION	Väärtus peab viitama noteeritud deklaratsioonile DTD-s	
ENUMERATED	Atribuut on varustatud võimalike väärtuste loeteluga, muid väärtusi atribuudile omistada ei tohi.	

Deklareerimisel saab määrata vaikimisi väärtust, kui kasutada järgnevaid võtmesõnu:

Tüüp	Kirjeldus	
#REQUIRED	Atribuudi väärtus peab olema spetsifitseeritud	
#IMPLIED	Atribuudi väärtus on soovitatav	
#FIXED value	Atribuudi väärtus peab olema fikseeritud, kasutaja seda muuta ei tohi	
Default	Atribuudi väärtus on vaikimisi määratud	

Näited fikseeritud, vaikimisi ja loetletud väärtuste kohta
Fikseeritud:

<!ELEMENT EMAIL (To+, From, CC*, Subject?, Body?)>
…
<!ELEMENT BCC (#PCDATA)>
<!ATTLIST BCC Hidden CDATA #FIXED "TRUE">
…
Vaikimisi:

	<!ATTLIST Address country CDATA "US">
	<!ATTLIST BoilingPoint scale CDATA ‘C’>

Loetletud:

<!ATTLIST Employee gender (male | female) #REQUIRED>

Atribuutide juures tuleb ka arvestada järgmist:
•	Kui atribuut on defineeritud rohkem kui üks kord, arvestatakse ainult esimest defineerimist
•	Kuna atribuutide andmeid ei töödelda, kasutatakse tüüpi CDATA mitte PCDATA
•	Erinevalt elementidest ei oma atribuutide järjekord mingit tähtsust.
Olemite (ENTITIES) deklareerimine
XML sisaldab mõningaid juba eelnevalt defineeritud olemeid märkide asenduseks.
DTD-s on võimalus neid vajaduse korral ka ise juurde luua. Süntaks olemite deklareerimiseks on järgnev:

<!ENTITY entityname entitydefinition>

Olemid on eraldatud ampersandi (&) ja semikooloniga (;).
Järgnevalt mõned eeldefineeritud olemid:

Olem	Märk	
&amp;	&	
&lt;	<	
&gt;	>	
&quot;	"	
&apos;	‘	
Üldised (dokumendisisesed) olemid
Üldine olem asendab nime eelnevalt defineeritud stringiga. Teda kirjeldatakse järgmisel kujul: 
	<!ENTITY name replacementCharacters>
	
Näiteks võib defineerida lihtsa olemi, kopeerimiskeelu (copyright) © märgi kuvamiseks:

<!ENTITY copyright "&#xA9">

Näites määratakse, et olem ‘copyright’ asendatakse unicode märgiga mille kood kuueteistkümnendsüteemis on A9.
Sellist olemit võib kasutada XML-is:

<copyrightNotice>
	&copyright; 2000 by TPU
</copyrightNotice>

Olemi definitsioonid võivad sisaldada ka viiteid teistele, juba defineeritud olemitele.
Dokumendivälised olemid
Dokumendivälised olemid võimaldavad dünaamiliselt kaasata XML dokumente erinevatest allikatest. Allikaks võib olla ka näiteks aadress veebiserveris asuvale XML dokumendile. 
Järgnevalt näide, kus kaasatakse kahest erinevast veebiserverist tihti muutuvaid andmeid.

<!ENTITY weatherA SYSTEM "http://myserver1/London/current.xml">
<!ENTITY weatherB SYSTEM "http://myserver2/NewYork/current.xml">

XML dokument, kus eelnevat kasutatakse:

<WeatherReport>
	<Title> The Current Weather Report </Title>
	&weatherA;
	&wetaherB;
</WeatherReport>

Andmed, mis leiduvad failis ‘current.xml’ töödeldakse XML parseri poolt. Nii on võimalik tõmmata XML dokumenti erinevaid andmeid väga erinevatest allikatest.

Mõningad andmetüübid, nagu näit binaarkujul olevad pildid, ei ole parseri poolt töödeldavad. Kui me tahame kasutada binaarkujul olemeid, siis peavad nad DTD-s olema defineeritud NDATA tüüpi.

<!ENTITY Image1 SYSTEM "MapOfLondon.gif" NDATA GIF>
<!ENTITY Image2 SYSTEM "MapOfNewYork.gif" NDATA GIF>

Vastav XML dokument:

<WeatherReport>
	<Title> The Current Weather Report </Title>
	<map src="Image1;"/>
&weatherA;
<map src="Image2;"/>
	&wetaherB;
</WeatherReport>
Parameetrilised olemid
Parameetrilised olemid on sarnased üldistele olemitele, kuid neid kasutatakse ainult DTD siseselt. Parameetriliste olemite eesmärgiks on vältida DTD-s palju korduvat teksti ning nad peavad olema defineeritud enne nende kasutamist.
Parameetriliste olemite üldine sünataks on:
	
	<!ENTITY % name "replacementCharacters">

Tuleb jälgida, et märgi % eel ja järel oleks tühik.

<!ENTITY % ng "NDATA GIF">

Teised DTD võtmesõnad
IGNORE ja INCLUDE
Neid kahte DTD direktiivi on hea kasutada DTD testimiseks. Nad võimaldavad kaasata ja välja lülitada erinevaid plokke. IGNORE ja INCLUDE süntaks on:

<![ IGNORE [
	DTD plokki ei töödelda
]]>

<![ INCLUDE [
	DTD plokk töödeldakse
]]>
Kommentaarid
DTD kommentaarid on sarnased HTML-is kasutatavatele. 
Näide:
	<!--  See on kommentaar -->

XML dokumentide kirjeldamine skeemidega
(XML Schema)
Sissejuhatus XML skeemidesse
Algselt olid XML skeemid soovitatavad Microsofti poolt, kuid nüüdseks W3C poolt. XML skeemid pakuvad oluliselt rikkamaid võimalusi kui DTD-d ning on erinevalt 
DTD-st välja töötatud spetsiaalselt XML dokumentide tarbeks.
XML skeemi komponendid ja omadused
XML skeeme kasutatakse sarnaselt DTD-ga kirjeldamaks XML andmedokumentide sisu ja struktuuri. Kui me kasutame XML skeeme, on alati tgemist kahe dokumendi mudeliga:
dokumendi realisatsioon ja dokumendi skeem.

XML skeem kirjeldab XML dokumendi klassi ja tegelik XML andmedokument on selle klassi realisatsioon. 
Järgnevalt vaatame XML dokumendi näidet, mis sisaldab infot ühe ajalehe artikli kohta:

<?xml version="1.0"?>
<article>
<headline section="bussiness">
	<MainHead>Main headline goes here</MainHead>
	<SubHead>A subheadline goes here</SubHead>	</headline>
<ByLine>
	<Author>John Doe</Author >
	<title>Reporter</title>
</ByLine>
<Dateline>April 30, 2000</Dateline>

<body>
	Content of story goes here…
</body>
		
		<stats>
			<submitted>2000-02-18</submitted>
			<wordCount>1532</wordCount>
			<bureauID>D-54</bureaID>
		</stats>
</article>

Kui vaatame XML dokumenti, märkame mitmeid erinevaid kihte, elemendid võivad sisaldada teisi elemente ja need omakorda järgmisi elemente. Nii mitu kihti sügavuti, kuid varem või hiljem jõuame ikkagi tegeliku informatsioonini. Kui element sisaldab alamelemente või atribuute, siis on see komplekstüüpi element (<ByLine>). Kui element sisaldab ainult numbreid või stringi, siis on ta lihttüüpi (<Dateline>). Atribuudid on alati lihttüüpi, kuna nad ei saa sisaldada alamelemente ega ka teisi atribuute.
Vaatame nüüd XML skeemi, mis kirjeldab eelneva näite dokumenti:

<schema targetNamespace="http://www.MyComapny.com/news"
xmlns:news="http://www.MyComapny.com/news"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<element name="article" type="news:articleType" />
<element name="dateline" type="xsd:date" />
<element name="body" type="xsd:string" />

<complexType name="articleType">
<element name="headline" type="news:headlineType" />
<element name="ByLine" type="news:ByLineType" />
<element ref="dateline" minOccurs="0" />
<element name="body" type="xsd:string" />
<element name="stats" type="xsd:statsType" />
<attribute name="section" type="xsd:string" />
	</complexType>

<complexType name="headlineType">
<element name="MainHead" type="xsd:string" />
<element name="SubHead" type="xsd:string" />
	</complexType>

<complexType name="ByLineType">
<element name="Author" type="xsd:string" />
<element name="title" type="xsd:string" />
	</complexType>

<complexType name="statsType">
<element name="submitted" type="xsd:date" />
<element name="wordCount" type="xsd:decimal" />
<element name="bureauID" type="news:BureauIDType" />
	</complexType>

<simpleType name="BureauIDType"> base="xsd:string">
<pattern value="[A-Z]-d{2}" />
	</simpleType>

Paneme tähele järgnevaid omadusi XML skeemi juures:

•	XML skeem on trimmis XML dokument, mida võib kontrollida XML parseriga
•	XML skeemid salvestatakse üldlevinult .xsd laiendiga failidena ning samuti on xsd ka XML skeemi nimeruum. Soovituslik W3 organisatsiooni XML skeemide nimeruum ja dokumendi tüübidefinitsioon asuvad internetiaadressil: xmlns:xsd="http://www.w3.org/1999/XMLSchema"
•	Elemendid, mis algavad sõnaga news, kuuluvad skeemi autori sõnastikku. xmlns:news="http://www.MyComapny.com/news"
•	Elemendid on deklareeritud, seejärel defineeritud
Nimeruumide (Namespace) kasutamine
Skeemi dokumendi loomisel võib talle määrata nimeruumi. Nimeruum võib olla antud  skeemi spetsiifiline. Identisfitseerimaks elemente ja atribuute skeemi dokumendis, võime me kasutada järgmist deklaratsiooni:

	xmlns:xsd="http://w3.org/1999/XMLschema"

Realisatsiooni dokumendis kasutame aga järgmist nimeruumi deklaratsiooni:

	xmlns:xsi="http://w3.org/1999/XMLschema/instance"

Kuid ainuüksi nimeruumi URI pole parserile kehtivuse kontrolliks piisav. Lisaks tuleb kasutada schemaLokation direktiivi. 
Näiteks võib skeemi dokument olla järgmine:

	<schema targetNamespace="urn:schemas-tradingCompany:trades"
xmlns:xsd="http://w3.org/1999/XMLschema">
	<!—- schema for <trades> and <accounts> -->
	</schema>

XML dokument aga järgmine:

	<tradedata xmlns="http://www.myCompany.com"
		xmlns:trd="urn:schemas-tradingCompany:trades"
		xmlns:xsi="http://w3.org/1999/XMLschema/instance"
		xsi:schemaLocation="urn:schemas-tradingCompany:trades
http://www.myCompany.com/trade.xsd">
<trd:trades />
<trd:accounts />
	</tradedata>
Mitme XML skeemi kasutamine
Kasutades direktiivi "schemaLocation" võime kas importida või kaasata ühe skeemi teise. Kaasamist võib kasutada juhul, kui nimeruum on ühtiv nii peadokumendil kui ka kaasataval dokumendil. Kui märgitud nimeruum on dokumentidel erinev, tuleks kasutada skeemi importimist. 

<schema targetNamespace="http://www.helloWorld.org"
xmlns="http://www.w3.org/1999/XMLSchema"

<import Namespace="urn:some-other-space:foo"
schemaLocation="http://www.someOther.com/schemas/foo.xsd" />
<include schemaLocation="http://www.helloWorld.org /schemas/MyType.xsd" />

Nagu näitest näha võib on kaasatud skeemi nimeruum ühtiv peadokumendi nimeruumiga imporditud skeemil aga erinev. 
Komplekstüüpide (Complex Type) definitsioonid
Komplekstüüp on konteineriks enamusele skeemis esinevatele elementidele. Komplekstüübid defineeritakse complexType elemendi abil. Enamik komplekstüüpe sisaldavad mitme elemendi ja atribuudi definitsioone, kuigi miski ei takista defineerida komplekstüüpi ka üheainsa elemendiga.

Järgnevas näites on defineeritud, et XML dokument sisaldab komplekstüüpi "articleType", mis koosneb neljast stringi tüüpi alamelemendist. Lisaks on defineeritud mittekohustuslik element "dateline", millel on atribuut "minOccurs".

<complexType name="articleType">
<element name="headline" type="news:headlineType" />
<element name="ByLine" type="news:ByLineType" />
<element ref="dateline" minOccurs="0" />
<element name="body" type="string" />
<element name="stats" type="news:statsType" />
<attribute name="section" type="string" />
	</complexType>

XML elementide tüübid, mis komplekstüübiga defineeritakse võivad olla edasikasutuses teiste elemenditüüpide deklareerimiseks.

Eksisteerivate tüübidefinitsioonide kasutamine
Sageli on vajalik kasutada juba deklareeritud ja eksisteerivaid tüübidefinitsioone. Selleks kasutatakse ref= atribuute. Viide peab olema globaalne element, st et ta peab olema deklareeritud dokumendi alguses kui skeemi juurelemendi otsene alamelement.
Elemendi esinemiste arvu saab määrata atribuutide minOccurs ja maxOccurs abil.

minOccurs väärtus	maxOccurs väärtus	Kirjeldus	
0	1	Valikuline atribuut või element, 
maksimaalne esinemiste arv 1	
0	*	Valikuline atribuut või element, 
maksimaalne esinemiste arv pole piiratud	
1	1	Tohib esineda täpselt ühe korra	
1	*	Peab esinema vähemalt ühe korra	
Lihttüübi definitsioon
Vaadates veekord XML skeemi näidet, siis näeme, et seal on mõned elemendid deklareeritud otseselt ja skeemi lõpus näeme simpleType definitsiooni

<simpleType name="BureauIDType"> base="xsd:string">
<pattern value="[A-Z]-d{2}" />
	</simpleType>

Lihttüüp on skeemi alus. Lihttüüp võib olla kas skeemi definitsioonis juba olemasolevat tüüpi või olla sellest pärinev.

Lihttüüp	Põhitüüp või
päritud tüüp	Kirjeldus / näide	
string	Põhitüüp	"see on string"	  	
float	Põhitüüp	Ühekordse täpsusega ujukoma arv	
double	Põhitüüp	Kahekordse täpsusega ujukoma arv	
boolean	Põhitüüp	true, false 1, 0	
binary	Põhitüüp	01000111	
byte	Päritud tüüp	-1, 126 	
unsignedByte	Päritud tüüp	0, 126 	
integer	Päritud tüüp	-126789, -1, 0, 1, 126789 	 	
positiveInteger	Päritud tüüp	1, 126789 	
negativeInteger	Päritud tüüp	-126789, -1 	
nonNegativeInteger	Päritud tüüp	0, 1, 126789 	
nonPositiveInteger	Päritud tüüp	-126789, -1, 0 	
int	Päritud tüüp	-1, 126789675 	
unsignedInt	Päritud tüüp	0, 1267896754 	
long	Päritud tüüp	-1, 12678967543233 	
unsignedLong	Päritud tüüp	0, 12678967543233 	
short	Päritud tüüp	-1, 12678 	
unsignedShort	Päritud tüüp	0, 12678 	
time	Päritud tüüp	13:20:00.000, 13:20:00.000-05:00	
duration	Päritud tüüp	P1Y2M3DT10H30M12.3S 	
date	Päritud tüüp	1999-05-31	
Name	Päritud tüüp	XML 1.0 nimetüüp 	
QName	Päritud tüüp	XML 1.0 nimeruum	
NCName	Päritud tüüp	XML 1.0 nimeruum	
anyURI	Põhitüüp	http://www.example.com/	
language	Päritud tüüp	en-GB, en-US, fr	
ID	Põhitüüp	XML 1.0 ID atribuudi tüüp	
IDREF	Põhitüüp	XML 1.0 IDREF atribuudi tüüp	
IDREFS	Põhitüüp	XML 1.0 IDREFS atribuudi tüüp	
ENTITY	Põhitüüp	XML 1.0 ENTITY atribuudi tüüp	
ENTITIES	Põhitüüp	XML 1.0 ENTITIES atribuudi tüüp	
NOTATION	Põhitüüp	XML 1.0 NOTATION atribuudi tüüp	
NMTOKEN	Päritud tüüp	XML 1.0 NMTOKEN atribuudi tüüp	
NMTOKENS	Päritud tüüp	XML 1.0 NMTOKENS atribuudi tüüp	

Piirangud (Facets)
Lihttüüpide saab muuta, seades neile piiranguid. Osad piirangud on loodud numbriliste,  osad tekstiliste andmete määrtlemiseks.
Näiteks:

	<!---Taken from a hospitalsystem -->
	<simpleType name="patienAges" base="double">
		<minInclusive value=‘0’ />
<maxInclusive value=‘150’ />
	</simpleType>

Struktuuri piirang:

<simpleType name="BureauIDType" base="xsd:string">
<pattern value="[A-Z]-d{2}" />
	</simpleType>

Loetelu piirang:

<simpleType name="gender" base="string">
<enumeration value="male" />
<enumeration value="female" />
	</simpleType>

Numbriline piirang:

<simpleType name="attack" base="decimal">
<enumeration value="1" /> <!—-By Land -->
<enumeration value="2" /> <!—-By Land -->
	</simpleType>

Atribuudid
Atribuute kasutatakse XML-s tihti eesmärgiga selgitada mõne elemendi aspekti.
Kui XML elementidel peavad atribuutide väärtused olema õiges järjestuses, siis sarnaselt DTD atribuutidega, ei oma ka skeemide atribuutidel järjekord mingit tähtsust.
Atribuutide kasutamine skeemi juures nõuab selle defineerimist komplekstüübina.

	<element name="weight">
<complexType base="decimal" derivedBy="extension">
<attribute name="units" type="string" />
		</complexType>
	</element>

Toodud näites kasutame me koplekstüübi atrbuut derivedBy, sellest täpsemalt allpool.
Juhul kui komplekstüüp ei sisalda mitte midagi muud peale atribuutide, võime me kasutada näiteks järgmist deklaratsiooni:

	<weight units="lbs" amount="24.5" />
Sisuatribuut
Komplekstüübil on skeemi definitsiooni kohaselt sisuatribuut. See atribuut kirjeldab deklareeritava elemendi sisumudeli. Atribuudi vaikeväärtus on elementOnly. See määrab, et komplekstüp võib sisalada ainult elemente ja atribuute kuid ei või sisaldada teksti. Sisu atribuudi võimalikud väärtused on:

Tüüp	Kirjeldus	
elementOnly	Võib sisalda ainult elemente	
empty	Ei tohi sisaldada midagi	
mixed	Võib sisaldada nii teksti kui elemente	
textOnly	Tohib sisaldada ainult teksti	

Grupid
Tavaliselt on väga paljud elemendid kopmplekstüüpi. Kui iga element, mis on skeemis defineeritud peab eksisteerima ka realisatsiooni dokumendis, siis nimetatakse sellist elementide gruppi jadaks. Viimase skeemidefinitsiooni standardi kohaselt pole see ainus võimalus, vaid lihtsalt vaikeväärtus:

	<complexType name=‘Data54’>
		<group order="sequence">
			<element name="firstname" type="string">
			<element name="lastname" type="string">
		</group>
	</complexType>

Komplekstüübi korral on võimalik ette kujutada ka stsenaariumi, kus nõutud elementide hulk võib varieeruda. Hea näide sellest võiks olla internatsionaliseerimine. Võib olla juhtumeid, kus ühe dokumendi realisatsioonis on postikood tekstiformaadis, samas kui mõne teise maa aadressi sisaldav dokumendi realisatsioon peab postikoodi defineerima numbrilises formaadis. Sellisel juhul kasutatakse valikulisi gruppe:

<complexType name=‘Data54’>
		<group order="choice">
			<element name="zipcode" type="decimal">
			<element name="postalcode" type="string">
		</group>
	</complexType>

On võimalik kasutada gruppe, mille realistasioonis peavad esinema kõik grupis deklareeritud elemendid, kuid esinemise järjekord pole tähtis:

<complexType name="TradeData">
		<group order="all">
			<element name="symbol" type="string">
			<element name="tradedate" type="date">
<element name="price" type="decimal">
<element name="amount" type="decimal">
		</group>
	</complexType>
Pärinevus
Uue andmetüübi loomisel peame määrama kahe atribuudi väärtused: baastüüp, mida me kasutame ning selle pärinevus. Baastüüp peab olema üks eelpool toodud põhitüüpidest või olla defineritud skeemi looja poolt. Uue komplekstüübi pärinevus võib olla määratud derivedBy atribuudiga, mille väärtuseks saab olla kas extension või restriction. Kui pärinevus on deklareeritud kui extension, siis uued deklaratsioonid lisatakse baastüübile. See võimaldab lisada elemente või atribuute, mida baastüüp ei sisalda. Kui me defineerime pärinevuse kui restriction, siis muudame me eksisteeriva baastüübi piiranguid:

<schema targetNamespace="myURI" xmlns:myns="myURI"
xmlns:xsd="http://www.w3.org/1999/XMLSchema/datatypes">
<complexType name="newsfeed">
<element name="headline" type="xsd:string" minOccurs="0" />
<element name="author" type="xsd:string" minOccurs="0" /> <element name="dateposted" type="xsd:date" />
<element name="body" type="xsd:string" />
<element name="artIncluded" type="xsd:boolean" />
		<!—Additional elements here -->
	</complexType>

<complexType name="story" base="myns:newsfeed" derivedBy="restriction">
	<restrictions>
<element name="headline" type="xsd:string" minOccurs="1" />
<element name="author" type="xsd:string" minOccurs="1" /> <element name="dateposted" type="xsd:date" />
<element name="body" type="xsd:string" />
<element name="artIncluded" type="xsd:boolean" />
		<!—Additional elements here -->
	</restrictions>
	</complexType>
</schema>

Antud näites esimene tüüp (newsfeed) kirjeldab kõiki erinevaid artiklitüüpe, paljud nendest on informatsiooniliselt vähetähtsad ning ei sisaldu lõplikus artiklis. Sellisel kujul artiklil ei pruugi veel olla määratud autorit, aga kui uudis on valmis publitseerimiseks, peavad realisatsiooni dokumendist puuduvad elemendid olema määratud. 
Annotatsioonid
Ametliku dokumentasiooni kohaselt: "Skeemi või tema komponentide annotatsioon on mõeldud kas inimesele või arvutile skeemi dokumentatsioni lisamiseks ning võib esineda skeemi põhielementides või skeemi alguses."

Spetsifikatsioon ei määratle kuidas peaks parser annotatsioone töötlema, seega sõltub kõik parseri realisatsioonist. 
Järgmises näites kasutatakse annotatsiooni lihttüübi dokumenteerimiseks:

<simpleType name="compoent" base:"xsd:uri-reference"
	<annotation>
		<documentation>
			Use this only in test conditions.
		</documentation>
	</annotation>
	<!-- Other declarations here -->
</simpleType>
XML skeemide võrdlus DTD-ga
Tõenäoliselt asendavad XML skeemid üsna peatselt DTD-d. Selleks on üsna mitmeid põhjusi – XML skeemid on kergemini õpitavad, laiendatavad, palju suuremate kasutamisvõimalustega, kirjutatud iseenesest juba XMLis, andmetüüpide ning nimeruumide toega.
XSL laiendatav stiilide keel
XSL sissejuhatus
Kuna XML on mõeldud andmete kirjeldamiseks, puudub seal võimalus määratleda andmete esitlust. XML andmete esitluseks ja viimiseks ühelt kujult teisele on W3C välja pakkunud XSL standardi. XSL sisaldab keerukat, algoritmilistele programmeerimiskeeltele sarnast käsustikku, mis on orienteeritud XML andmete töötlusele. Hetkel on XSL jaotatud mitmeks iseseisva funktsionaalsusega loogiliseks osaks:

•	XSL stiililehed (stylesheets) –  määravad ära XML dokumendi stiilid.
•	XSLT – keel transformeerimaks XML dokumenti ühest formaadist teise.
•	XPath – keel, mis kirjeldab kuidas leida XML dokumendist spetsiifilisi elemente.
•	XLink – keel kirjeldamaks, kuidas omavahel siduda erinevaid XML dokumente
•	XPointer – keel kirjeldamaks, kuidas omavahel siduda ühe ja sama XML dokumendi erinevaid osasid.
XSL stiililehtede kasutamine
Olgu meil järgmine XML dokument:

<?xml version="1.0"?>

<CONTACT_INFO>
<CONTACT>
	<NAME>Ott Karu</NAME>
	<PHONE>666-6666</PHONE>
</CONTACT>
<CONTACT>
	<NAME>Triinu Lepa</NAME>
	<PHONE>655-5555</PHONE>
</CONTACT>
<CONTACT>
	<NAME>Mari Mustika</NAME>
	<PHONE>644-4444</PHONE>
</CONTACT>
</CONTACT_INFO>

Nagu näha on tegu väga lihtsa osaga telefoniraamatust, kus dokumendi juurelement on CONTACT_INFO, ta sisaldab CONTACT elemente, mis omakorda koosnevad kahest alamelemendist NAME ja PHONE. Oletame, et seda kontaktide nimekirja on vaja kuvada veebibrauseris. 

Järgmine XSL viib antud XML dokumendi HTML kujule:

<?xml version="1.0"?>
<xsl:template xmlns:xsl="http://www.w3.org/TR/WD-xsl">
	<HTML>
	<BODY>
	<xsl:for-each select="CONTACT_INFO/CONTAC">
	<DIV>
	<xsl:value-of select="NAME"/>
	</DIV>
	</xsl:for-each>
	</BODY>
	</HTML>
</xsl:template>

Vaadeldes seda XSL stiililehte, võib täheldada, et tegu on trimmis XML dokumendiga, mis vastab XSL DTD-le. Antud näite tulemuseks on järgmine HTML väljund:

	<HTML>
		<BODY>
			<DIV>Ott Karu</DIV>
<DIV>Triinu Lepa</DIV>
<DIV>Mari Mustika</DIV>
		</BODY>
	</HTML>
XSL stiililehed
XSL stiilileht koosnevad ühest või rohkemast mallist. Nagu ka nimi viitab on mall väljunddokumendi mingi osa mudeliks. Juhul kui malle on XSL stiililehel mitu, peab olema määratud milline mallidest valida. Selleks on võetud kasutusele mallide mustrimäärang (pattern matching). Näiteks järgmine mall rakendatakse XML dokumendi juurelemendile st käivitakse parseri poolt esimesena:

<xsl:template match="/">
	<HTML>
	<BODY>
	<xsl:for-each select="CONTACT_INFO/CONTAC">
	<DIV>
	<xsl:value-of select="NAME"/>
	</DIV>
	</xsl:for-each>
	</BODY>
	</HTML>
</xsl:template>

Toodud näites match="/" on malli mustrimäärang, kus "/" on XPathi avaldis, mis määrab, et malli rakendatakse XML dokumendi juurelemendi esinemisel.
Andmete leidmine mustrite (pattern) abil
XPathi mustreid ei kasutata mitte üksnes mallide rakendamise määramiseks. Tegu on palju üldisema vahendiga XML dokumendi erinevate elementide leidmiseks. XPath võimaldab määrata elementide asukohta XML dokumendis sarnaselt failisüsteemile – näiteks /CONTACTS/CONTACT instrueerib parserit valima juurelemendist lähtuvalt CONTACTS elemendi jooksva alamelemendi CONTACT.

Järgnev tabel kirjeldab mustrisobitamisel defineeritud erimärke:

/	Otsese alamelemendi operaator. Kui muster algab selle operaatoriga valitakse elemendid alates dokumendi juurelemendist.	
//	Rekursiivse alamelemendi operaator, valitakse kõik sobivad elemendid ning neis omakorda sisalduvad sobivad alamelemendid. Kui muster algab selle operaatoriga, siis valitakse kõik dokumendis olevad sobivad elemendid sõltumata nende asukohast.	
.	Aktiivse elemendi sisuoperaator.	
*	Metamärk mis sobib kõikide elementidega.	
@	Atribuudi valiku operaator, atribuudi nimi peab koheselt sellele operaatorile järgnema.	
@*	Valib kõik aktiivse elemendi atribuudid.	
:	Nimeruumi operaator.	
!	Rakendab informatsioonimeetodi aktiivsele elemendile.	
(  )	Grupeeringu märkimiseks.	
[ ]	Rakendab mustri filtri	
[ ]	Võimaldab viidata hulgast elementidest kindla indeksiga elemendile.	

Informatsioonimeetodid
XSL mustrites on võimalik kasutada informatsioonimeetodeid – spetsiaalseid funktsioone elementide käsitlemisel. Järgnevalt on ära toodud põhilised:

date	Konverteerib väärtusi kuupäeva formaati.	
end	Tagastab tõese väärtuse kui on valitud hulga viimane element.	
index	Tagastab hulga aktiivse elemendi indeksi.	
nodeName	Tagastab valitud elemendi nime.	
nodeType	Tagastab valitud elemend tüübi.	
text	Tagastab valitud elemendi sisu tekstina.	
value	Tagastab valitud elemendi sisu ilma seda tekstikujule konverteerimata.	

Operaatorid
Mustrifiltrites saab kasutada lisaks võrdlusele ka hulga teisi loogilisi operaatoreid. 
Nendeks on:

Operaator	Lühivorm	Seletus	
$and$	&&	Loogiline konjunktsioon	
$or$	||	Loogline disjunktsioon	
$not$		Loogiline eitus	
$eq$	=	Võrdsus	
$ieg$		Tõstutundetu võrdsus	
$ne$	!=	Mittevõrdus	
$ine$		Tõstutundetu mittevõrdus	
$lt$	<	Vähem kui	
$ilt$		Tõstutundetu vähem kui	
$le$	<=	Vähem võrdne	
$ile$		Tõstutundetu vähe võrdne	
$gt$	>	Rohkem kui	
$igt$		Tõstutundetu rohkem kui	
$ge$	>=	Suurem võrdne	
$ige$		Tõstutundetu suurem võrdne	
$all$		Tagastab tõese kui tingimus kehtib kõigile hulga elementidele	
$any$		Tagastab tõese kui tingimus kehtib vähemalt ühele hulga elemendile	

XSL käsustik
XSL parseri juhtimiseks on välja töötatud programmeerimiskeelele sarnane käsustruktuur mis sisaldab ka näiteks vookontrolli ning tsüklisust. Käsud on järgmised:

XSL element	Tähendus	
xsl:apply-templates	Instrueerib parserit valima järgmist sobivat malli	
xsl:attribute	Lisab aktiivsele elemendile atribuudi	
xsl:choose	Valib hulgast loogilistest tingimustest tõese. Sarnane programmeerimiskeeltest tuntud case lausele	
xsl:comment	Lisab väljundisse kommentaari	
xsl:copy	Kopeerib aktiivse elemendi või elemendid väljundisse	
xsl:element	Lisab väljundisse elemendi	
xsl:for-each	Iteratiivne hulga elementide valik	
xsl:if	Tingimuse konroll	
xsl:otherwise	Määrab mida täidetakse juhul kui xsl:choose ükski tingimus pole tõene	
xsl:pi	Lisab väljundisse töötlusinstruktsiooni	
xsl:stylesheet	Dokumendi element mitme malliga XSL stiililehele	
xsl:template	Malli deklaratsioon	
xsl:value-of	Lisab väljundisse valitud väärtuse	
xsl:when	xsl:choose elemendi üks loogiline tingimus	

Lõppsõna
Käesolev ülevaade XML-st ja temaga seotud tehnoloogiatest andis loodetavasti piisava ettekujutuse XML-i olemusest ning tema kasutuspotentsiaalist. Kuna tegu on väga kiirelt areneva tehnoloogiaga, mis tõotab kujuneda järgmise põlvkonna tarkvara üheks põhistandarditest, siis tuleks XML-i kasutamise vajalikkust kaaluda iga uue loodava tarkvaraprojekti raames.

Viited kasutatud materjalidele
1.	M. Baartse, R. Blair, L. Bolognese, D. Dalvi, S. Hahn, C. Haines, A. Homer, B. Kropog, B. Loesgen, S. Mohr, J. Slater, K. Williams, M. Zucca.
"Professional ASP XML"  Wrox Press Ltd, 2000

2.	Extensible Markup Language (XML), 11 märts 2001
http://www.w3.org/XML/

3.	Welcome to XML School, 23 veeb. 2001
http://www.w3schools.com/xml/

4.	Welcome to XML School, 24 veeb. 2001
http://www.w3schools.com/xsl/

5.	Welcome to XML School, 24 veeb. 2001
http://www.w3schools.com/dtd/

6.	Welcome to XML School, 24 veeb. 2001
 http://www.w3schools.com/schema/