XML and XML Schema 29

XML specification Technical XML spec. describes XML syntax using Extended Backus-Naur Format (EBNF), which is compact unequivocal easy to read and interpreted (by computers) EBNF example: Operation ::= Integer Symbol Integer Integer ::= [1-9]+ Symbol ::= '+ ' '- ' '* ' 30 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 <-.

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 31 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ä ' (tulee sanasta apostrophy ) ja kaksinkertainen hipsu (lainausmerkit) merkinnällä ".

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) 32 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.

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 () CDATA block Everything else in an XML document is character data Note: XML is case sensitive 33 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.

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 34 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/>  </ EXAMPLE>

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 are reserved for XML standardization 35 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!>

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  can contain any data except the literal string -- 36 Kommentti määritellään XML spesifikaatiossa seuraavasti: [15] Comment ::= ' Esimerkki hyvin määritellystä kommentista:  Seuraava esimerkki ei puolestaan ole hyvin määritelty. Miksi?

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 used support scandic characters 37 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.

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 38 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ä): the quick brown fox jumps over the lazy dog. what colour is it? what color is it? <sp who="faust" desc='leise' xml:lang="de"> <l>habe nun, ach! Philosophie,</l>... </sp>

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); ]]> 39 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.

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., < procudes the left angle bracket (<) and > produces the right angle bracket (>) 40 Entiteettiviittaukset (entity references) viittaavat johonkin toisaalla määriteltyyn osaan tai vaikkapa erikoismerkkiin, esim. < tuottaa vasemman kulmasulun <. Muut varatut erikoismerkit ja niiden entiteettiviittaukset ovat: Entiteettiviittaus Vastaava erikoismerkki & & < < > > ' " 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.

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 defines how the type is marked in the document Note: document type definition and document type declaration are thus different things! 41 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.

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 42 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.

An example DTD (recipes.dtd): An example XML document: <!ELEMENT collection (description,recipe*)> <?xml version="1.0" encoding="utf-8"?> <!ELEMENT description ANY> <!DOCTYPE collection SYSTEM "recipes.dtd"> <!ELEMENT recipe <collection> (title,ingredient*,preparation,comment?)> <description> <!ELEMENT title (#PCDATA)> Some of my favourite recipes </description> <!ELEMENT ingredient EMPTY> <recipe> <!ATTLIST ingredient name CDATA #REQUIRED <title>spoon cookies</title> <ingredient name="raspberry jam"/> amount CDATA #IMPLIED <preparation> unit CDATA #IMPLIED> <step> Take some time to bake these! <!ELEMENT preparation (step*)> </step> <!ELEMENT step (#PCDATA)>... </preparation> </recipe> <recipe>... </collection> 43

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)... 44 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 XMLprosessorit käytännössä tukevat sekä DTD että XML Schema määrityksiä (validoivat jäsentäjät).

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 45 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.

XML Schema basics Element types and attributes are defined correspondingly 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 46 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>

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. ElementpurchaseOrder is defined as a complex type and element comment as a simple type 47 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.

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"> Occurance XML Schema DTD 1 left undefined or minoccurs=1 maxoccurs=1 left undefined 0-1 minoccurs=0 maxoccurs=1? 0 or more minoccurs=0 maxoccurs=unbounded * 1 or more minoccurs=1 maxoccurs=unbounded + 48 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.

Global and local types A local type: <xsd:element name= 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 >  </xsd:complextype> global elements are children of the root schema element Note: global types can be used by other elements 49 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>

Namespaces namespace abc.xsd <tagname> namespace xyz.xsd <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. xmlns:a= abc.xsd xmlns:x= xyz.xsd <a:tagname> <x:tagname> Note: namespaces allows distinguishing elements with similar names belonging to different namespaces 50 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 SOAPviestejä käsiteltäessä.

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> 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 51 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.

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 52 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.

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 53 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>

DTD vs. XML Schema pros 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) 54 DTD tarjoaa tavan määritellä peruskielioppeja XML-pohjaisille kielille. Tämän lisäksi XML Schema tarjoaa yksityiskohtaisemman ja kontrolloidumman tavan määritellä mitä XMLdokumenteissa 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.

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 55 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.

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 56 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.