29

XML and XML Schema

30

XML specification• Technical XML spec. describes XML

syntax using Extended Backus-NaurFormat (EBNF), which is– compact– unequivocal– easy to read and interpreted (by computers)– EBNF example:

Operation ::= Integer Symbol IntegerInteger ::= [1- 9]+Symbol ::= '+ ' | '- ' | '* '

Tässä luvussa palautetaan mieliin muutamia XML:n peruskäsitteitä. Lisäksi käydään lyhyesti läpi

miten XML-pohjaisia kieliä määritellään DTD ja XML Schema –kuvauksin. Tarkoitus ei ole antaa

kattavaa kuvausta näistä kielistä. Niiden tarvittava osaaminen edellytetään esitietona. Hyvä

suomenkielinen opas XML-kieleen: Ossi Nykänen, XML, Docendo, 2001.

John Backusin kehitti 1950- ja 1960-lukujen vaihteessa merkintätavan, jota Peter Naur kehitti sitä

edelleen. Näin kehittyi Backus-Naur Form (BNF), jota voidaan käyttää kielioppien ilmaisemiseen ja

määrittämiseen. Naur käytti BNF:ää esimerkiksi Algol 60:n määrittelydokumentissa. ISO ja IEC

standardoivat vuonna 1996 EBNF:n, joka on laajennettu version BNF:stä. Nämä laajennokset

esimerkiksi mahdollistavat valinnaisuuden, toiston, ryhmittelyn ja poikkeustapausten ilmaisemisen.

Lisäksi EBNF sallii kommenttien lisäämisen kieliopin kuvaamiseen.

EBNF:n yksikäsitteisyys on tietyssä mielessä suhteellista. EBNF on luonnollisesti yksikäsitteinen

verrattuna kieliopin sanalliseen määrittämiseen. Yksikäsitteisyys saavutetaan kielen laillisten sanojen

suhteen.

”::=” on niin sanottu tuottosääntö ja se vastaa (mahdollisesti) tutumpaa symbolia ”<-”.

31

EBNF in XML spec.• Characters and strings

– #xN: a character with index N (N is a hexadecimal integer, the number of leading zeros in the #xN form is insignificant)

– [a-zA-Z] (or [#xN-#xN]) : any character in a given range– [^abc] , [^a-z]: a character other than the one listed– ”string”, ’string’ : literal strings

• Brackets: for structuring, used ”the typical way”• Operators

– A B : B follows A– A | B : A or B, but not both– A – B : A but not B

Esim. XPath spesifikaatio määrittelee seuraavasti:

[174] WhitespaceChar ::= ([#x0009] | [#x000D] | [#x000A] | [#x0020])

(eli rivinvaihto (/r ja /n), tabulointimerkki tai välilyönti)

Jotta esim. attribuuttien arvot voisivat sisältää sekä yksinkertaisia että kaksinkertaisia hipsuja, voidaan

yksinkertainen hipsu (’) esittää merkinnällä &apos; (tulee sanasta ”apostrophy”) ja kaksinkertainen

hipsu (lainausmerkit) merkinnällä &quot;.

32

EBNF in XML spec. (cont’d)• Multipliers

– A ? : A appears either once or not at all– A+ : A appears one or more times– A* : A appears either many times, one time,

or not at all, i.e., ”anything will do”• Other special notations used in the XML spec.

– /* …*/ (comment)– [ wfc: … ] (well-formedness constraint)– [ vc: … ] (validity constraint)

EBNF sisältää sanallisia rajoitteita ([wfc:…] ja [vc:…]), joissa lisävaatimusten avulla määritellään

säännön oikea tulkinta. Alla olevassa esimerkissä hyvinmuodostuneisuusrajoite (wfc) takaa, että

element-säännössä alku- ja lopputagin nimet täsmäävät. Saman esimerkin validisuusrajoite (vc)

puolestaan takaa, että elementin looginen muoto vastaa annettua tyyppimäärittelyä.

Esimerkki VC ja WFC rajoitteista:

[39] element ::= EmptyElemTag | STag content ETag [WFC: Element Type Match]

[VC: Element Valid]

Validity constraint: Element Valid

An element is valid if there is a declaration matching elementdecl where the Name matches the

element type, and one of the following holds:...

Well-formedness constraint: Element Type Match

The Name in an element's end-tag must match the element type in the start-tag.

33

Markups of XML documents• Markup can be

– processing instruction– type definition of a document– start tag of an element (<book>)– end tag of an element (</book>)– an empy element (<xxx/>)– entity reference– character reference– comment (<!-- this is a comment -->)– CDATA block

• Everything else in an XML document is character data• Note: XML is case sensitive

Esimerkki: kolme eri elementtiä sisäkkäin:

<ELEMENTTI>

<Elementti>

<elementti>

...

</elementti>

</Elementti>

</ELEMENTTI>

Seuraavaksi kalvolla mainitut XML-dokumentin osat käydään nopeasti läpi.

34

The basic structure of an XML document

[1] document ::= prolog element Misc*

• prolog

• XML version, coding, etc.

• document type declaration

• instance

• the content of the document

• one mandatory root element and possibly other elements

XML 1.1 spesifikaatio määrittelee prologin seuraavasti (tässä vain osa):

[3] S ::= (#x20 | #x9 | #xD | #xA)+

[22] prolog ::= XMLDecl Misc* (doctypedecl Misc*)?

[23] XMLDecl ::= '<? xml' VersionInfo EncodingDecl? SDDecl? S? '?> ’

[28] doctypedecl ::= '<!DOCTYPE' S Name (S ExternalID)? S? ('[' intSubset ']' S?)? '>'

XML 1.0 spesifikaatio puolestaan määrittelee sen seuraavalla tavalla:

[3] S ::= (#x20 | #x9 | #xD | #xA)+

[22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)?

[23] XMLDecl ::= '<? xml' VersionInfo EncodingDecl? SDDecl? S? '?> ’

[28] doctypedecl ::= '<!DOCTYPE' S Name (S ExternalID)? S? ('[' intSubset ']' S?)? '>'

Toisin sanoen, versiossa 1.0 XML-deklaraatio on optionaalinen! Tämä mahdollistettiin siksi, että

XML tiedostoja voitaisiin käyttää joidenkin SGML- tai HTML-sovellusten (huom! nykyään XHTML

nojautuu puhtaasti XML:ään) kanssa sekoittamatta näitä XML-spesifeillä koodeilla. Versiossa 1.1

XML deklaraatio on kuitenkin pakollinen. Esimerkki:

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

<! DOCTYPE EXAMPLE SYSTEM "hellow. dtd">

<EXAMPLE>

<TITLE> Hello World!</ TITLE>

<CONTENT> <TEXT> my stuff </ TEXT>

<AUTHOR> Tarja </ AUTHOR>

</ CONTENT>

< DATE/> <!-- here is an empty element -->

</ EXAMPLE>

35

Processing instructions (PIs)• Provide information to the processing application• The form: <?name pidata?>, where

– name is called PI target and it is used to identify the application to which the instruction is directed

– pidata is the actual instruction– examples:

• <?xml-stylesheet type=”text/css” href=”hello.css”?>• <?xml version=”1.0”?>

– Note: PI names beginning with ”xml” or ”XML” arereserved for XML standardization

Tarkemmin (XML 1.1 ja 1.0):

[16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'

[17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

Tuotantosääntö [16] sanoo seuraavaa: prosessointiohjeen aloittavaa merkkijonoa ”<?” seuraa

prosessointiohjeen kohteen nimi (PITarget), jonka jälkeen voi tulla tyhjää merkkijonoa (S) seuraten

mitä tahansa merkkejä, lukuunottamatta merkkijonoa ”?>”. Lopuksi merkkijono ”?>” lopettaa

prosessointiohjeen.

Huom! XML spesifikaatio ei määrittele prosessointiohjeiden tulkintaa (paitsi XML-prosessorille

tarkoitetut), vain niiden merkintätavan.

Laillinen prosessointiohje:

<?gcc version=”2.7.2 ” options==”-O4 ”?>

<?Terri Do you think this is a good example?>

Laittomia prosessointiohjeita (miksi?):

<? I have to remember to fix this next part?>

<?Terri This is a good example!>

36

Elements and comments

• Elements are delimited by angle brackets:– start tag: <greeting>– end tag: </greeting>– a short hand notation for an empty element:

<empty/>• Comments

– begin with ”<!--” and end with ”-->”– can contain any data except the literal string ”--”

Kommentti määritellään XML spesifikaatiossa seuraavasti:

[15] Comment ::= '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->‘

Esimerkki hyvin määritellystä kommentista:

<!-- declarations for <head> & <body> -->

Seuraava esimerkki ei puolestaan ole hyvin määritelty. Miksi?

<!-- B+, B, or B--->

37

Scandic characters• From the point of view of the XML 1.0 Spec.,

the following is well-formed:<jäynä>

<:>Hello, World!</:></jäynä>

• In practise, to be on the safe side, use only 7-bit ASCII alfanumeric characters and an underscore in the names of attributes and elements– even though XML applications use Unicode, it is

not guaranteed in practise that all programs usedsupport scandic characters

Esimerkki:

<jäynä>

<:>Hello, World!</:>

</jäynä>

Edellisessä esimerkissä ongelmia saattaa tuottaa sekä ”ä” kirjaimen että kaksoispisteen ( : ) käyttö

elementtien nimissä. Kaksoispistettä esimerkiksi käytetään niminavaruuksien yhteydessä (tästä lisää

myöhemmin). Esimerkki on mukaeltu esimerkistä, joka on esitetty kirjassa Ossi Nykänen, XML,

Docendo, 2001.

38

Attributes• Name-value pairs that occur inside start tags after

the element name– e.g., <test level=”demanding”>– element ”test” has an attribute ”level”, the value of

which is ”demanding”• In XML, all attribute values must be quoted• Two fixed attributes

– xml:space: for defining how white spaces are treated by the processor, two possible values:

• default: XML-application can decide• preserve: all white spaces (empty chars) should be preserved

– xml:lang: for defining the language, no effects on the processor

XML:ssä elementeille voidaan määritellä attribuutteja. XML-dokumentissa näille attribuuteille

annetaan arvot nimi-arvo –pareina elementin alkutagissä. Attribuutin arvot annetaan aina

lainausmerkeissä. XML-prosessorille voidaan antaa ohjeita tyhjien merkkijonojen (S) käsittelemiseksi

attribuutin xml:space avulla. Tämä attribuutti voi saada arvon ”default” tai ”preserve”. Arvo ”default”

tarkoittaa sitä, että sovelluksen oletusmekanismi tyhjien merkkien käsittelemiseksi on riittävä

kyseiselle elementille. Ts., XML-sovellus saa päättää tyhjien merkkien käsittelystä. Arvo ”preserve”

puolestaan indikoi, että sovellus pyrkii säilyttämään tyhjät merkit. Spesifikaatio ei kuitenkaan

mitenkään määrittele ko. arvojen (”default” ja ”preserve”) merkitystä. Käytännössä käsittely riippuu

sovelluksesta. Attribuutilla xml:space (ja attribuutilla xml:lang ) annetaan siis lisäinformaatiota

prosessorin välitettäväksi. Käytännössä sovellus voi tehdä tyhjien merkkien suhteen mitä haluaa.

Attribuutilla xml:lang annetaan elementin kieli esim. muodossa fi, en, en-GB, jne. Nämä muodot

määrittelee [IETF RFC 3066]: IETF (Internet Engineering Task Force). RFC 3066: Tags for the

Identification of Languages, ed. H. Alvestrand. 2001. (Katso http://www.ietf.org/rfc/rfc3066.txt.)

Esimerkki (hieman modifioitu XML 1.1 spesifikaation esimerkistä):

<p xml:lang="en" space="default">The quick brown fox jumps over the lazy dog.</p>

<p xml:lang="en-GB">What colour is it?</p>

<p xml:lang="en-US">What color is it?</p>

<sp who="Faust" desc='leise' xml:lang="de">

<l>Habe nun, ach! Philosophie,</l>

...

</sp>

39

CDATA sections• Can be used to tell the parser to ignore

markup characters• Begin with ” <![CDATA[ ” and end with ” ]]> ”

– between them, all character data is passed directly to the application, without interpretation

– e.g.<![CDATA[

*p = &q; b = (i <= 3);

]]>

Merkkidatalohkojen (CDATA sections) käyttöön saattaa liittyä hienoisia ongelmia, jos sitä

esimerkiksi käytetään ohjelmakoodin kirjoittamiseen. Esimerkiksi sisäkkäisten taulukoiden käyttö

ohjelmakoodissa saattaa aiheuttaa yllätyksiä, koska niissä saattaa esiintyä merkkijono ”]]>”, joka on

merkkijonolohkon lopetusmerkki.

40

Entity references• Each XML document has both a logical and a physical structure.

Physically, the document is composed of units called entities. An entity may refer to other entities to cause their inclusion in the document.

• Some characters (e.g., ”<”) are reserved• Entities are used to

– represent special characters– to refer to often repeated or varying text – to include the content of external files -> allows dividing an

XML document into several files– make the DTD definitions more compact– refer to data that is not in XML format

• Entity references begin with the ampersand and end with a semicolon– e.g., ” &lt;” procudes the left angle bracket (<) and &gt;

produces the right angle bracket (>)

Entiteettiviittaukset (entity references) viittaavat johonkin toisaalla määriteltyyn osaan tai vaikkapa

erikoismerkkiin, esim. ”&lt;” tuottaa vasemman kulmasulun ”<”. Muut varatut erikoismerkit ja niiden

entiteettiviittaukset ovat:

Entiteettiviittaus Vastaava erikoismerkki &amp; &

&lt; <

&gt; >

&apos; ’

&quot; ”

Toisaalla määritelty osa voi olla esimerkiksi jokin vakioteksti (”Tampereen teknillinen korkeakoulu”).

Antamalla ko. vakiotekstille jokin sopiva nimi (esim. TUT), voidaan siihen viitata XML-dokumentin

muista osista. Tämän avulla tuota vakiotekstiä ei sellaisenaan tarvitse kirjoittaa uudelleen eri

paikkoihin, vaan se voidaan antaa yhdessä paikassa ja vain viitata siihen muualta. Tästä on sekin

hyöty, että mikäli tarvetta vakiotekstin muutokseen ilmaantuu (”Tampereen teknillinen yliopisto”),

tarvitsee ko. muutos tehdä vain yhteen paikkaan.

41

Document Type Definition, DTD• The type of a document is a model for

element and attribute structure of the document

• The type can be given as a DTD, externally and internally

• The document type declaration defineshow the type is marked in the document

• Note: document type definition and document type declaration are thusdifferent things!

XML-dokumentin sisäinen tyyppimääritys:

<?xml version=”1.0”?>

<!DOCTYPE greeting [

<!ELEMENT greeting (#PCDATA)>

]>

<greeting>Hello, World!</greeting>

...

XML-dokumentin ulkoinen tyyppimääritys (oletus: elementti ”greeting” on määritelty ulkoisessa

tiedostossa ex.dtd):

<?xml version=”1.0”?>

<!DOCTYPE greeting SYSTEM ”ex.dtd”>

<greeting>Hello, World</greeting>

....

Kuten jo aiemmin (kalvo 23) todettiin, termit ”document type declaration” ja ”document type

definition” eivät tarkoita samaa. ”Document type declaration” on yksi XML-dokumentin pakollinen

osa, josta selviää missä itse kielioppimääritys (document type definition) on annettu. Tämä

kielioppimääritys voi sisältyä myös ”document type declartation” –osaan.

42

DTD• Defines the grammar for an XML language• E.g.,

– the allowed sequence and nesting of tags, attribute values and their types (and defaults)

– the names of external files that may be referenced and whether or not they contain XML,

– the formats of some external (non-XML) data that may be referenced,

– the entities that may be encountered

DTD:n avulla voidaan määritellä kielioppi halutulle XML-kielelle. Sen avulla voidaan siis määritellä

sanasto eli käytettävät XML-elementit ja niiden sallitut järjestykset, näiden elementtien sallitut

attribuutit ja mahdollisesti niiden oletusarvot, viitattavien ulkopuolisten tiedostojen nimet ja niiden

tyypit, entitetit jne.

Tällä kurssilla ei perehdytä DTD-määrittelyihin tarkemmin. Lisäinformaatiota löytyy esim. kirjasta

Ossi Nykänen, XML, Docendo, 2001.

43

<!ELEMENT collection (description,recipe*)>

<!ELEMENT description ANY>

<!ELEMENT recipe (title,ingredient*,preparation,comment?)>

<!ELEMENT title (#PCDATA)>

<!ELEMENT ingredient EMPTY>

<!ATTLIST ingredient name CDATA #REQUIRED

amount CDATA #IMPLIED

unit CDATA #IMPLIED>

<!ELEMENT preparation (step*)>

<!ELEMENT step (#PCDATA)>

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

<!DOCTYPE collection SYSTEM "recipes.dtd"><collection>

<description>Some of my favourite recipes

</description><recipe>

<title>Spoon cookies</title><ingredient name="raspberry jam"/><preparation>

<step>Take some time to bake these!

</step>...

</preparation></recipe><recipe>...

</collection>

An example DTD (recipes.dtd): An example XML document:

44

Schema languages• XML Schema Definition Language

– W3C Architecture Domain– XML Schema Part 0: Primer

(http://www.w3.org/TR/xmlschema-0/)– XML Schema Part 1: Structures– XML Schema Part 2: Datatypes

• Regular Language Description for XML (RELAG)• RELAX NG• Schematron• Document Schema Definition Language (DSDL)• XML-Data (XDR)• Document Content Description (DCD)• ...

Miksi uusia skeemakieliä tarvitaan DTD:n ohella?

DTD on periaatteessa suunniteltu tekstidokumenttien kirjoittamiseen. XML:n käyttöalueita on sen

sijaan paljon muitakin. Useissa niistä on tarve asettaa tarkempia vaatimuksia tiedon täsmällisyydelle.

Sellaisia käyttöalueita ovat esimerkiksi: elektroninen kaupankäynti (tilaus- ja laskutustieto),

metatiedon määrittely, tietoverkkojen hallintatieto jne. DTD:ssä on melko rajoitetut mahdollisuudet

tiedon määrittelylle: sen avulla voidaan elementtien osalta määrittää ainoastaan, että elementti sisältää

tekstiä ja toisia elementtejä tietyssä järjestyksessä. Elementtien attribuutit sisältävät joko tekstiä tai

tietoa, jota prosessorin ei oleteta jäsentävän. Perustyyppien puuttuminen DTD:stä on (vain) yksi sen

ongelmista. Periaatteessa siinä on käytössä vain yksi perustyyppi: ”string”.

Tällä kurssilla tarkastellaan useista eri vaihtoehtoisista tavoista määritellä XML-kieliä ehdottomasti

yleisimmin käytettyä vaihtoehtoa: XML Schema Definition Language –kieltä. Kaikki XML-

prosessorit käytännössä tukevat sekä DTD että XML Schema –määrityksiä (validoivat jäsentäjät).

45

XML Schema• An XML-based format for defining XML languages• Example advantages over DTD

– XML-based syntax– OO features (e.g., inheriting predefined structures,

abstract document types)– groups (all, choice, sequence)– datatypes– user defined types– namespaces– include & import

XML Schemalla on useita etuja DTD-kieleen verrattuna. Ensinnäkin XML Schema on XML-kieli

itsessään. Se tarkoittaa esimerkiksi sitä, että XML Schema määrityksiä voidaan käsitellä samoilla

työkaluilla (editointi, kyselyt, jäsennys jne.) kuin mitä tahansa XML-dokumentteja. Toisaalta tämä

käytännössä tekee myös kielioppimäärityksistä verbooseja. Sama kielioppi voidaankin määritellä

DTD:n avulla tyypillisesti huomattavasti kompaktimmin. Koska XML Schema on XML-kieli, on sille

itselleen määritelty kielioppi – sekä DTD:n että XML Scheman avulla. XML Schema Part 1 antaa

nämä ”DTD for XML Schema” ja ”XML Schema for XML Schema” määritykset liitteenä.

XML Scheman yksi huomattavimmista eduista DTD:hen verrattuna ovat perustietotyypit (float,

double, integer, boolean, string,...), joita XML Schemassa on yli 30. DTD:ssä on periaatteessa vain

yksi tyyppi: string. Tämän lisäksi XML Scheman määriteltyjä attribuuttityyppejä (ID, IDREF,

IDREFS, ENTITY,..) on kahdeksan. Lisäksi XML Schemassa on useita erilaisia

ryhmittelymekanismeja ja tietyssä mielessä ”oliopiirteitä”. XML Schema sallii esimerkiksi

tyyppimääritysten erikoistamisen olemassa olevista tyyppimäärityksistä joko laajentamalla tai

rajoittamalla niitä. XML Schema antaa myös DTD:tä paremman tuen nimiavaruuksien käytölle sekä

määrittelyjen modularisoimiseksi.

Seuraavaksi käydään läpi XML Scheman tärkeimpiä ominaisuuksia.

46

XML Schema basics

• Element types and attributes are definedcorrespondingly to DTD definitions

• Elements are of either complex or simple type– complex type: elements may include other

elements and attributes– simple type: may only include text, cannot have

attributes nor element content• There are 40 built-in simple types in XML Schema (see

XML Schema spec.), including decimals, dates, etc.• Attributes are always of simple type

Uusia rakenteisia tyyppejä voidaan määritellä elementin complexType avulla (XML Schema Part 0):

<xsd:complexType name="USAddress" >

<xsd:sequence>

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

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

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

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

<xsd:element name="zip" type="xsd:decimal"/>

</xsd:sequence>

<xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>

</xsd:complexType>

Tässä esimerkissä “NMTOKEN” tarkoittaa tunnistemerkkijonoa ja se on yksi kahdeksasta

perusattribuuttityypistä. Prefixin “xsd” merkitystä käsittelemme seuraavaksi.

Oletetaan, että elementti “billTo” on määritelty “USAdress”-tyyppiseksi esimerkiksi seuraavalla

tavalla: <xsd:element name="billTo" type="USAddress"/> . Tällöin edellä esitetyn kieliopin osan

mukainen XML-dokumentti voisi sisältää vaikkapa alla olevan rakenteen (XML Schema Part 0):

<billTo country="US">

<name>Robert Smith</name>

<street>8 Oak Avenue</street>

<city>Old Town</city><state>PA</state><zip>95819</zip>

</billTo>

47

XML Schema basics (cont’d)<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="purchaseOrder" type="PurchaseOrderType"/> <xsd:complexType name="PurchaseOrderType">... ...</xsd:complexType><xsd:element name="comment" type="xsd:string"/> ...

</xsd:schema>

• <xsd:schema> opens the schema definition and </xsd:shema> closes it• Prefix xsd is associated with the XML Schema namespace through the declaration, xmlns:xsd="http://www.w3.org/2001/XMLSchema", that appears in the schema element. The prefix “xsd” is used by convention to denote the XML Schema namespace, although any prefix can be used. • Element purchaseOrder is defined as a complex type and element comment as a simple type

XML Scheman määrittelemiä tyyppejä voidaan käyttää ottamalla XML Scheman nimiavaruus

käyttöön. Esimerkiksi elementtiä ”element” voidaan käyttää määriteltäessä uusi elementtityyppi

XML-kieleen. Vastaavasti elementtiä ”attribute” voidaan käyttää määriteltäessä attribuutti jollekin

tähän XML-kieleen kuuluvalle elementille. Myös käytettäessä XML Scheman perustyyppejä (string,

boolean, integer, date,...) tulee viitata XML Scheman nimiavaruuteen. Nimiavaruus otetaan käyttöön

”xmlns” (xml namespace) määreen avulla. Koska samassa XML Schema määrittelyssä voi olla - ja

usein onkin – käytössä useita nimiavaruuksia, ne identifioidaan prefixien (xxx:) avulla. Edellä

esitetyssä esimerkissä on käytetty ”xsd:”-prefiksiä viitattaessa XML Schema nimiavaruuteen. Tämä on

myös yleinen käytäntö. Käyttäjä voi tosin valita prefiksiksi jonkin muunkin haluamansa merkkijonon.

48

Element occurance• Specifying occurences of elements are defined using

attributes– minOccurs: the minimum number an element may occur

(default value:1)– maxOccurs: the maximum number an element may occur

(default value: 1)– e.g., <xsd:element name="item" minOccurs=“3"

maxOccurs=“5">

+minOccurs=1 maxOccurs=unbounded

1 or more

*minOccurs=0 maxOccurs=unbounded

0 or more

?minOccurs=0 maxOccurs=10-1

leftundefined

left undefined orminOccurs=1 maxOccurs=1

1DTDXML SchemaOccurance

Elementtien sallitut esiintymiskerrat XML-dokumentissa annetaan määreiden minOccurs ja

maxOccurs avulla. Mikäli esiintymiskertojen minimi- ja maksimimääriä ei erikseen ilmoiteta, on

elementin esiintymiskertojen määrä 1. XML Schema sallii minkä tahansa positiivisella

kokonaisluvulla määriteltävän arvon antamisen minOccurs ja maxOccurs attribuuteille. Pidä kuitenkin

huolta siitä, että attribuutin maxOccurs arvon tulee olla suurempi kuin attribuutin minOccurs arvo.

Erityisen huolellinen tulee olla silloin, kun ko. attribuuteille ei ole määritelty erikseen arvoa eli kun

käytetään niiden oletusarvoa 1. Esimerkiksi jos määräät arvon vain attribuutille minOccurs, niin sen

tulee olla 0 tai 1. Jos taas määräät arvon vain attribuutille maxOccurs, niin sen tulee olla vähintään 1.

49

Global and local types• A local type:

<xsd:element name=“recipe”><!--define locally the type of ”recipe” -->

</xsd:element>– local elements are not direct children of the schema element, they

are nested further inside the schema structure• A global type:

<xsd:element name=“recipe” type=“recipeType”/><xsd:complexType name=“recipeType”>

<!-- define here the type ”recipeType --></xsd:complexType>

– global elements are children of the root schema element

Note: global types can be used by other elements

Globaalit elementit määritellään juurielementin lapsina. Määriteltyihin globaaleihin elementteihin

voidaan viitata myöhemmin yhdestä tai useammasta toisesta elementeistä käyttäen ref attribuuttia.

Lokaaleja tyyppejä puolestaan käytetään esimerkiksi kun halutaan antaa tietylle tyypille eri

merkityksiä eri kontekstissa: eri elementeille voidaan antaa samannimisiä lokaaleja tyyppimäärityksiä.

Alla on esimerkki globaalista tyyppimäärityksistä (XML Schema Part 0). Siinä globaalisti

määriteltyyn elementtiin comment viitataan myöhemmin ref-attribuutin avulla. Attribuutin ref arvon

tulee olla aina globaali elementti. Viittauksesta seuraa, että XML-dokumentissa elementti comment voi

esiintyä elementin PurchaseOrder alielementtinä ja sen sisällön tulee olla tyyppiä string.

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

<xsd:element name="purchaseOrder" type="PurchaseOrderType"/>

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

<xsd:complexType name="PurchaseOrderType">

<xsd:sequence>

<xsd:element name="shipTo" type="USAddress"/>

<xsd:element name="billTo" type="USAddress"/>

<xsd:element ref="comment" minOccurs="0"/>

<xsd:element name="items" type="Items"/>

</xsd:sequence>

<xsd:attribute name="orderDate" type="xsd:date"/>

</xsd:complexType>

<xsd:complexType name="USAddress">…</xsd:complexType>

...

</xsd:schema>

50

Namespaces

Note: namespaces allowsdistinguishing elements withsimilar names belonging to different namespaces

abc.xsd

namespace

<tagName>xyz.xsd

namespace

<tagName>

xmlns:a=”abc.xsd”xmlns:x=”xyz.xsd”

<x:tagName>

<a:tagName>

XML Schema Part 0:”A schema can be viewed as a collection (vocabulary) of type definitions and element declarations whose names belong to a particular namespace called a target namespace. Target namespaces enable us to distinguish between definitions and declarations from different vocabularies.”

Nimiavaruuksia voidaan hyödyntää XML Schema -määrityksissä monella eri tavalla. Niiden avulla

voidaan ”modularisoida” määrityksiä eri ”pakkauksiin”. Lisäksi koska samassa XML Schema –

dokumentissa voidaan käyttää eri nimiavaruuksiin kuuluvia elementtejä, nimiavaruuksien käyttö sallii

esimerkiksi samannimisten elementtien käytön: nimiavaruuteen viittaavan prefiksin ansiosta ne ovat

kuitenkin yksikäsitteisesti identifioitavissa. Toisaalta kahden eri sanaston (eri skeemojen) samojen

sanojen käyttöä eri merkityksissä tulisi välttää. Tätä kutsutaan törmäykseksi (collision). ”Namespaces

in XML” (http://www.w3.org/TR/xml-names11/) käsittelee esimerkiksi sanastojen

nimeämiskäytäntöjä tavoitteena tällaisten törmäysten välttäminen.

Nimiavaruuksiin palataan myöhemmin tällä kurssilla esimerkiksi Web-palveluja ja erityisesti SOAP-

viestejä käsiteltäessä.

51

• namespaces are set using the xmlns attribute• default namespace declaration does not introduce any prefix

-> unprefixed types and elements are associated with it• targetNamespace attribute lets you define, independently from the

namespace declarations, the URI reference of the namespace of this schema

• Note1: in pox.xsd global elements have a namespace name equivalent to that of the target namespace of the schema, while local elements have no namespace name

• Note 2: in pox.xsd, prefix ”po” is associated with the target namespace

Example, pox.xsd:

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:po="http://www.example.com/PO1" targetNamespace=”http://www.example.com/PO1”>

<element name="purchaseOrder" type="po:POType"/><element name="comment" type="string"/> ...</schema>

Nimiavaruudet otetaan käyttöön määreen xmlns (xml namespace) avulla. Nimiavaruuksiin kuuluviin

elementteihin viitataan prefiksin avulla, joka annetaan xmlns-määreen käytön yhteydessä. Mikäli

tällaista prefiksiä ei anneta, on kyseessä oletusnimiavaruus (default namespace).

Oletusnimiavaruuteen kuuluviin tyyppeihin ja elementteihin voidaan itse XML-dokumentissa viitata

ilman prefiksiä. Edellä annetussa esimerkissä (pox.xsd) oletusnimiavaruus on

http://www.w3.org/2001/XMLSchema ja siihen kuuluvat ”element” ja ”string”. Lisäksi esimerkissä

käytetään nimiavaruutta http://www.example.com/PO1, johon kuuluu esimerkiksi “POType”.

Kohdenimiavaruus (target namespace) mahdollistaa rakennettavan skeeman URI-viittauksen

määrittelemisen nimiavaruusdeklaraatioista riippumattomasti. Se myös spesifioi nimiavaruuden niille

elementeille ja attribuuteille, jotka tämä kyseinen skeema määrittelee. Vaikka XML Schema

spesifikaatio ei pakota targetNamespace-attribuutin käyttöä, sen käyttöä yleisesti suositellaan. Sen

pois jättäminen (nk. chameleon schema ) voi aiheuttaa esimerkiksi tulkintaongelmia validoitaessa.

52

”Inheritance”• for defining new types, two ways to inherit

– by restriction (differs from class inheritance in OO!)• using element restriction and attribute base• restriction of a simple type typically restricts the range of simple

type's values Example:

<xsd:simpleType name="myInteger"> <xsd:restriction base="xsd:integer">

<xsd:maxInclusive value="99999"/> </xsd:restriction>

</xsd:simpleType>

• restriction of a complex type typically involves type's declarations – by extension

• using element extension and attribute base• e.g., new elements are added to an existing complex type

XML Schema sallii tyyppien määrittelemisen käyttäen olio-ohjelmoinnistakin tuttua perinnän

käsitettä. Perintä voidaan suorittaa laajentamalla perittävää tyyppiä tai rajoittamalla sitä. Rajoittamalla

periminen poikkeaakin oliokielistä tutusta perinnästä: sen avulla voidaan perittävän tyypin jokin

ominaisuus sulkea pois. Oliokielissä tämä ei ole suoraan mahdollista.

Yksinkertaisen tyypin periminen rajoittamalla koskee yleensä perittävän tyypin mahdollisien arvojen

rajoittamista. Kompleksista tyyppiä voidaan puolestaan periä sekä rajoittamalla että laajentamalla

monella eri tavalla. Perinnällä tällöin tyypillisesti pyritään muuttamaan perittävän tyypin rakennetta.

Alla on esitetty esimerkki kompleksisen tyypin laajentamalla perimisestä (modifioitu esimerkki, XML

Schema part 1: Structures). Tässä complexContent-elementtin käyttö indikoi, että uusi tyyppi on

kompleksinen (sisältää elementtejä).

<xs:complexType name="personName">

<xs:sequence>

<xs:element name="forename" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="surname"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="extendedName">

<xs:complexContent>

<xs:extension base="personName">

<xs:sequence>

<xs:element name="title" minOccurs="0"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

Yo. Määrittely extendedName voidaan asettaa esimerkiksi elementin addressee tyypiksi ja käyttää

esimerkiksi seuraavalla tavalla:

<addressee>

<forename>Albert</forename>

<forename>Arnold</forename>

<surname>Gore</surname>

<title>student</title>

</addressee>

Yksinkertaista tyyppiä voidaan myös laajentaa perimällä:

<xsd:element name="internationalPrice">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:decimal">

<xsd:attribute name="currency" type="xsd:string"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

Yo. esimerkissä simpleContent-elementtin käyttö indikoi, että uudessa tyypissä käytetään vain

merkkipohjaista tietoa eikä siis sisällä elementtejä. Tässä laajennoksessa decimal-tyyppiä laajennetaan

tyypiksi internationalPrice siten, että laajennetulla tyypillä on myös attribuutti name. Huom! Koska

tässä esimerkissä lisätään attribuutti yksinkertaiselle tyypille, ko. yksinkertainen tyyppi itse asiassa

laajennetaan kompleksiseksi tyypiksi.

53

Model groups• A model group has the following properties

– particles• A sequence of particles corresponding to all the items among the

children, in order – an item is one of the following: <all>, <choice>, <sequence>, <any>,

<group>, or <element>– compositor

• sequence: correspond, in order, to the specified particles• choice: correspond to exactly one of the specified particles • all: correspond to all the particles, allows each element in particles

to appear once (but not more!) or not at all. The elements may appear in any order

• default: the elements must appear in the same sequence (order) in which they are declared

– Annotation• An annotation corresponding to <annotation> element, optional

• Note: model groups can be nested

Malliryhmässä (model group) voidaan käyttää neljää eri tapaa (sequence, choice, all, default) ryhmän

sisältävien ”partikkeleiden” (particles) ryhmittelemiseksi. Nämä neljä tapaa kuvaavat ko. ryhmän

sisältävien ”partikkeleiden” sallitut esiintymisjärjestykset (ja jossain määrin myös esiintymiskerrat).

Itse ”partikkelit” voivat olla tavallisia suunnittelijan määrittelemiä elementtejä tai vaikkapa edellä

mainittuja ryhmittelijöitä. Näin ollen malliryhmät voivat sisältää myös sisäkkäisiä malliryhmiä.

Esimerkki (XML Schema, Part 0):

<xsd:complexType name="PurchaseOrderType">

<xsd:sequence>

<xsd:choice>

<xsd:group ref="shipAndBill"/>

<xsd:element name="singleUSAddress" type="USAddress"/>

</xsd:choice>

<xsd:element ref="comment" minOccurs="0"/>

<xsd:element name="items" type="Items"/>

</xsd:sequence>

<xsd:attribute name="orderDate" type="xsd:date"/>

</xsd:complexType>

<xsd:group name="shipAndBill">

<xsd:sequence>

<xsd:element name="shipTo" type="USAddress"/>

<xsd:element name="billTo" type="USAddress"/>

</xsd:sequence>

</xsd:group>

54

DTD vs. XML Schemapros and cons

• If you want to define data types, use XML Schema– DTD has essentially only one data type: string

• If you want to use namespaces, use XML Schema• Note: practically all XML processors support both

DTDs and XML Schemas• Although XML Schema is more verbose than DTD, it

gives more flexibility for datamodel/document evolution and maintenance

• Compared to DTD, Schema is more difficult to work with (and sometimes to understand)

DTD tarjoaa tavan määritellä ”peruskielioppeja” XML-pohjaisille kielille. Tämän lisäksi XML

Schema tarjoaa yksityiskohtaisemman ja kontrolloidumman tavan määritellä mitä XML-

dokumenteissa voi ja mitä siinä ei voi esiintyä. Näin ollen XML Schema vaikuttaa paremmalta

vaihtoehdolta ja onkin sitä useissa tapauksissa. On kuitenkin tilanteita ja syitä, miksi DTD:tä kannattaa

käyttää XML Scheman sijaan.

Joidenkin järjestelmien rajapintojen DTD-määrittelyt saattavat olla olemassa historiallisista syistä.

Näiden mahdollisesti suurten ja kompleksisten määrittelyjen uudelleen kirjoittaminen XML Scheman

avulla ei aina ole vaivan arvoista ja/tai tarkoituksenmukaista. Skeeman käyttö saattaa myös olla

tehotonta. koska XML Schema on XML-dokumentti, on määrittelyt usein hyvin pitkiä. Lisäksi skeema

tyypillisesti viittaa tiettyihin nimiavaruuksiin. Kun jäsentäjä prosessoi (validoiden) dokumenttia, se

voi joutua linkittämään tämän informaation, tarkistamaan, että nimiavaruusdeklaraatioissa käytetyt

prefiksit ovat laillisia (ei esim. kahta samannimistä prefiksiä) ja validoimaan skeeman varsinaisen

XML-dokumentin jäsentämisen lisäksi.

55

Design guidelines• For Schemas: (See: http://www.xfront.com/BestPracticesHomepage.html)

– Examples:• Create extensible schemas

– E.g. by type substitution: instead of fixing the structure of <Book>, define <BookType> and use that as a type for <Book> elements….you might later on want to extend <BookType>

– by using <any> elements...well, this has downsides, too– extend schemas without touching them using import/include

• Postpone decisions as long as possible-> flexibility-> reusability

Nämä suositukset ovat hyviä useimmissa tapauksissa mutta eivät välttämättä aina. Tapaus- ja

tarkoituskohtaisesti kannattaa siis harkita muitakin ratkaisuja. Esimerkiksi id-attribuuttien käyttö (tätä

ei kuitenkaa pidä pitää samana kuin ID-tyyppisten attribuuttien käyttöä) ei kaikissa tapauksissa ole

mielekästä, vaikka se tarjoaakin nimiavaruuksia hienojakoisemman tavan identifioida elementtejä.

XML Schema -määrittelyt tulisi myös suunnitella laajennettaviksi varautuen myöhempiin kieliopin

ylläpito- ja muutostarpeisiin. Yksi tapa varautua laajennettavuuteen on <any>-elementtien ja ”##any”–

tyyppisten attribuuttien käyttö. Niiden avulla voidaan ”staattisista” määrittelyistä tehdä ”dynaamisia”.

Haittapuolena on se, että skeeman määrittelijä ei voi mitenkään varautua siihen, millaista

informaatiota XML-dokumentin kirjoittaja voi tai haluaa kirjoittaa ko. variaatiokohtiin. Toinen tapa

varautua laajennettavuuteen on korvata fiksatut elementin rakennemäärittelyt tyyppimäärityksillä, joita

ko. elementti käyttää. Esimerkiksi elementin <Book> rakenne voidaan antaa erillisenä <BookType>-

tyyppinä ja <Book>-elementtiä määritettäessä viitata siihen:

<xsd:element name=“Book” type=“BookType” maxOccurs=“unbounded”/>.

Yksi XML Schema –määrittelyjen suunnitteluperiaatteista on: ”tee päätökset niin myöhään kuin

mahdollista”. Tällaista ”laiskaa päätöksentekoperiaatetta” tulisi soveltaa esimerkiksi tietyn

komponentin sitomisessa nimiavaruuteen. Tarkoituksena yleisestikin on pyrkiä tekemään sidonnat

vain tarvittaessa välttäen tarpeettomia sitomisia.

56

Design guidelines• Elements or attributes?

(see e.g http://www.oasis-open.org/cover/elementsAndAttrs.html)– put metadata in attributes and content in elements– attributes are more suitable for enumerated data,

elements are logical units of information– use attribute for computer manipulated values– properties and relations are expressed as attributes– attributes are atomic characteristics of an

element/object that have no identity themselves, their meaning may change on element described

Attribuuttien ja elementtien suhdetta käsiteltiin jo edellä. Yhtenä perusperiaatteena valintaa tehtäessä

on se, että metainformaatio annetaan attribuuttien avulla kun taas itse sisältö annetaan elementtien

avulla. Yksi hyvä tapa erottaa onko kyseessä metainformaatio vai informaatio, on kysyä: ”Jos poistan

tämän informaation, niin muuttuisiko käsitykseni sisällöstä?” Jos vastaus on ”ei”, niin kyseessä on

metainformaatio. Metainformaatiolle on toisaalta sopivampiakin esitystapoja, joita käsitellään

myöhemmin.