xml and xml schema
TRANSCRIPT
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ä ' (tulee sanasta ”apostrophy”) ja kaksinkertainen
hipsu (lainausmerkit) merkinnällä ".
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., ” <” procudes the left angle bracket (<) and >
produces the right angle bracket (>)
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.
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.