Validisuusrajoitukset (XML)

Dokumenttielementin tyyppi (Root Element Type)

Selitys: Rakenne-esittelyssä annettu rakennemäärittelyn nimi on oltava täsmälleen sama kuin dokumenttielementin tyyppi.

Esimerkkejä:

<!DOCTYPE kirja PUBLIC ".." >
<kirja>
        <tekija>Suuri kirjailija</tekija>
...
</kirja>

Edellisessä esimerkissä rakennemäärittelyn nimeksi annettiin 'kirja', joka rajoituksen mukaisesti on myös dokumenttielementin tyyppi. Toinen samanlainen esimerkki on HTML-dokumentista:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
               "http://www.w3.org/TR/REC-html40/strict.dtd">
<HTML>
<HEAD>
...
</HEAD>
<BODY>
...
</BODY>
</HTML>

Koskee sääntöä: doctypedecl (28)

Elementin validisuus (Element Valid)

Selitys: Tämä rajoitus määrää elementin validisuuden. Koska koko dokumentin validisuus riippuu suurelta osin elementeistä ja niiden validisuudesta, voidaan (vähän liioitellen) sanoa tämän rajoituksen määräävän koko dokumentin validisuuden.

Elementti on validi, kun on olemassa vastaava elementtityypin esittely, joka täyttää elementdecl-säännön. Vastaavuudella tarkoitetaan, että elementin nimi (Name-sääntö) vastaa jotain elementtityypin nimeä. Lisäksi jonkin seuraavista kohdista on pidettävä paikkansa:

Elementtityypi on esittelyssä määrätty EMPTY-tyyppiseksi ja elementillä itsellään ei ole lainkaan sisältöä. Kyseessä on siis tyhjä elementtityyppi, jonka ilmentymien on oltava tyhjiä elementtejä.
Elementtityypin esittelyssä määrätty sisältö vastaa children-sääntöä ja elementin lapsielementit vastaavat esittelyssä määrättyä sisältömallia niin nimiensä kuin järjestyksensäkin puolesta. Lapsielementtien välissä saa olla vain S-säännön täyttäviä erotinmerkkejä.
Elementtityypin sisältö on esitelty Mixed-säännön mukaisesti ja elementti sisältää merkkitietoa ja alielementtejä. Alielementtien on kuuluttava elementtityypin esittelyssä määriteltyyn sisältömalliin.
Elementtityyppille on esittelyssä määrätty ANY-tyyppinen sisältö ja elementti sisältää rakennemäärittelyssä määriteltyjä elementtityyppejä. Eli elementin sisällä voi olla mitä tahansa elementtejä missä järjestyksessä tahansa, kunhan ne on esitelty.

Yhteenvetona ylläolevista säädöksistä voisi yksinkertaisesti sanoa, että elementin on oltava jonkin esittelyn mukainen.

Esimerkki:

<!ELEMENT kirja       (nimi, sarja?, tekija, isbn, tiivistelma)>
<!ELEMENT nimi        (#PCDATA | alaindeksi | ylaindeksi)* >
<!ELEMENT alaindeksi  (#PCDATA)>
<!ELEMENT ylaindeksi  (#PCDATA)>
<!ELEMENT sarja       (#PCDTA) >
<!ELEMENT tekija      (#PCDATA)>
<!ELEMENT tiivistelmä ANY >
<!ELEMENT isbn        EMPTY >
<!ATTLIST isbn
          isbn        CDATA  #REQUIRED >

Ylläolevaa 'kirja.dtd'-rakennemäärittelyä on käytetty seuraavassa dokumentissa.

<?xml version="1.0" ?>
<!DOCTYPE kirja SYSTEM "kirja.dtd">
<kirja>
    <nimi>Lasten kuvitettu XML-opas</nimi>
    <nimi>
        Kuinka opastat lapsesi 
        <tarkea>rakenteisten dokumenttien</tarkea> 
        ihmeelliseen maailmaan!
    </nimi>
    <isbn isbn="xxx">xxx</isbn>
    <tiivistelma>
        Tämä on <kohderyhma>lapsille</kohderyhma> 
        suunnattu kuvakirja.
   </tiivistelma>
</kirja>

Dokumentti rikkoo kaikkia tämän rajoituksen kohtia vastaan:

'kohderyhma' ja 'tarkea'-elementtejä ei ole esitelty lainkaan.
'isbn'-elementillä on sisältöä, vaikka se on esitelty tyhjäksi elementiksi.
'kirja'-elementtityypin sisältö on children-säännön mukainen, mutta elementti ei toteuta määrättyä sisältömallia: sillä on ylimääräinen 'nimi'-elementti ja 'tekija'-elementti puuttuu kokonaan.
Jälkimmäisen 'nimi'-elementin sisällä on 'tarkea'-elementti, jota ei ole ensinnäkään esitelty ja jota ei elementtityypin esittelyn mukaan saa olla 'nimi'-elementin sisällä.
'tiivistelma'-elementin sisällä olevaa 'kohderyhma'-elementtiä ei ole lainkaan esitelty.

Koskee sääntöä: element (39)

Elementtityypillä vain yksi esiintymä yhdistelmäsisällössä (No Duplicate Types)

Selitys: Mikäli elementtityypille määrätään yhdistelmäsisältö, saa sisällön esittelyssä elementtityyppi esiintyä ainoastaan yhden kerran. Rajoite on varsin luonnollinen, sillä yhdistelmäsisällössä mainitut elementtityypit voivat esiintyä elementissä missä järjestyksessä tahansa ja kuinka monta kertaa tahansa. Tällöin saman elementtityypin lisäämisellä sisältömalliin toiseen kertaan ei ole mitään vaikutusta.

Esimerkki:

<!ELEMENT kirja (#PCDATA | hinta | tekija | nimi | hinta)*>

Edellisessä 'kirja'-elementtityypin esittelyssä 'hinta' esiintyi kahdesti, mikä ei ole rajoituksen mukaan sallittua.

Koskee sääntöä: Mixed (51)

Elementtityypillä vain yksi ID-tyyppinen määrite (One ID per Element Type)

Selitys: Elementtityypille on sallittu vain yksi ID-tyyppinen määrite. Käsittääkseni rajoitus periytyy SGML:stä.

Esimerkki:

<!ATTLIST kirja
          sivumaara        CDATA  #IMPLIED
          isbn             ID     #REQUIRED
          sisainen_tunnus  ID     #IMPLIED>

Esimerkin kirja-elementtityypillä on rajoituksen vastaisesti kaksi ID-tyyppistä määritettä: 'isbn' ja 'sisainen_tunnus'.

Koskee sääntöä: TokenizedType (56)

Elementtityypillä vain yksi notaatiotyyppinen määrite (One Notation per Element Type)

Selitys: Notaatiotyyppisen määritteen tarkoituksena on välittää XML-jäsentimelle tieto miten kyseisen elementin sisältö pitäisi tulkita tai millä sovelluksella sitä pitäisi käsitellä. Rajoituksen tarkoituksena on puolestaan pakottaa yksikäsitteinen tulkinta elementin sisällössä käytetylle formaatille. Tämän vuoksi elementtityypille on sallittua esitellä vain yksi notaatiotyyppinen määrite.

Esimerkki:

<!ATTLIST  sisalto
           formaatti       NOTATION (ps | rtf) #IMPLIED
           vara_formaatti  NOTATION (pdf)      #IMPLIED 
           viite           CDATA               #IMPLIED >

Esimerkin rakennemäärittelyn katkelmassa 'sisalto'-elementtityypille esitellään kaksi notaatiotyyppistä määritettä, mikä ei ole sallittua.

Koskee sääntöä: NotationType (58)

Elementtityypin yksilöllisyys (Unique Element Type Declaration)

Selitys: Elementtityypin saa esitellä vain kerran - toisin kuin määritteitä tai entiteettejä.

Esimerkki:

<!ELEMENT kirja  (tekija, nimi, hinta)>
<!ELEMENT tekija (#PCDATA)>
<!ELEMENT nimi   (#PCDATA)>
<!ELEMENT kirja  (nimi, tekija, kustantaja, hinta)>
<!ELEMENT hinta  (#PCDATA)>

Esimerkin DTD on virheellinen, sillä siinä 'kirja'-elementtityyppi on esitelty kahdesti, mikä tämän rajoituksen mukaan on kielletty.

Koskee sääntöä: elementdecl (45)

Entiteetin oltava esitelty (Entity Declared)

Selitys: Dokumentissa, jonka

riippumattomuusesittelyssä annettu arvo on "no", ja
johon on liitetty rakennemäärittelyn ulkoinen osajoukko tai ulkoisia parametrientiteettejä,

täytyy entiteettiviittauksen nimen vastata jotain entiteettien esittelyissä ilmoitettua nimeä.

Lisäksi parametrientiteetti on aina esiteltävä ennen kuin siihen viitataan rakennemäärittelyssä. Samoin yleisentiteetti on esiteltävä ennen viittausta, mikäli viittaus on oletusarvossa määritteen esittelyssä.

Jos dokumentin halutaan varmasti olevan yhteensopiva SGML-järjestelmien kanssa, täytyy amp, lt, gt, apos ja quot -entiteetit esitellä seuraavalla tavalla [ks. XML-määrittelyn luku 4.6]:

    <!ENTITY lt     "&#38;#60;">
    <!ENTITY gt     "&#62;">
    <!ENTITY amp    "&#38;#38;">
    <!ENTITY apos   "&#39;">
    <!ENTITY quot   "&#34;">

Yksinkertaistetusti sanottuna kaikki entiteetit, joihin dokumentissa viitataan, on esiteltävä. Lisäksi esittelyn on sijaittava ennen ensimmäistä viittausta.

Katso myös vastaavan nimistä hyvinmuodostuneisuusrajoitusta, joka täydentää tätä rajoitusta.

Esimerkkejä: Alla oleva rakennemäärittelyn ulkoinen osajoukko on tallennettu 'tilasto.dtd'-tiedostoon (lisäksi osajoukossa viitataan 'trakenne.ent'-tiedostoon, joka ei ole tässä näkyvillä).

<!ENTITY % tilastorakenne  SYSTEM  "./trakenne.ent" >
<!ELEMENT  tilastot        (tilasto+) >
<!ATTLIST  tilastot
           %lpmaarite;>
<!ELEMENT  tilasto         (%tilastorakenne;) >
<!ATTLIST  tilasto
           %lpmaarite;
           tekija          CDATA  #REQUIRED >
<!ENTITY % lpmaarite       "luontipaiva CDATA #IMPLIED" >

Osajoukossa on yksi tämän validisuusrajoituksen rikkova virhe: 'lpmaarite'-parametrientiteettiin viitataan ennen kuin se on esitelty. Seuraavassa dokumentissa käytetään 'tilasto.dtd'-tiedostoa:

<?xml version="1.0" standalone="no" ?>
<!DOCTYPE     tilastot SYSTEM  "tilasto.dtd" [
    <!ATTLIST tilasto
              vuosi    CDATA   "&vuosi;" >
    <!ENTITY  vuosi    "1999" >
]>
<tilastot luontipaiva="10.9.1999">
     <tilasto vuosi="1999" luontipaiva="10.9.1999" tekija="Timo Tilastonikkari">
        <nimi>Entiteettien esiintymätilasto</nimi>
	    &tilasto1999;
    </tilasto>
    <tilasto vuosi="1998" luontipaiva="10.9.1999" tekija="Timo Tilastonikkari">
        <nimi>Entiteettien esiintymätilasto</nimi>
	    &tilasto1998;
    </tilasto>
</tilastot>

Sisäisessä osajoukossa on samankaltainen viittausvirhe kuin ulkoisessakin: 'vuosi'-yleisentiteettiin viitataan määritteen esittelyssä oletusarvona, mutta se esitellään vasta viittauksen jälkeen.

Itse dokumentti-ilmentymässä viitataan kahteen jäsennettyyn yleisentiteettiin: 'tilasto1999' ja 'tilasto1998'. Kumpaakaa entiteettiä ei ole esitelty tässä näytetyissä rakennemäärittelyn osajoukoissa. Mikäli niitä ei ole esitelty 'trakenne.ent'-tiedostossakaan, tekevät viittaukset dokumentista epävalidin.

Koskee sääntöjä: EntityRef (68), PEReference (69)

ENTITY- ja ENTITIES-tyyppisten määritteiden arvot (Entity Name)

Selitys: ENTITY-tyyppisen määritteen arvon on oltava Name-säännön mukainen. Samoin ENTITIES-tyyppisen määritteen arvon on oltava Names-säännön mukainen. Jokaisen ENTITY-tyyppisen määritteen arvon ja jokaisen ENTITIES-tyyppisen määritteen arvon osan on vastattava jotain rakennemäärittelyssä esitellyn jäsentämättömän entiteetin nimeä.

Esimerkki:

<?xml version="1.0" ?>
<DOCTYPE kirjailijat [
    <!NOTATION gif       PUBLIC "-//CompuServe Information Services, Inc.//NOTATION Graphics Interchange Format (GIF)//EN" >

    <!ENTITY kuva1       SYSTEM "images/Kunto1.gif"      NDATA gif>
    <!ENTITY kuva2       SYSTEM "images/Kunto2.gif"      NDATA gif>
    <!ENTITY kuva3       SYSTEM "images/Kunto3.gif"      NDATA gif>
    <!ENTITY kansiMR     SYSTEM "images/Mrakenteet.gif"  NDATA gif>

    <!ELEMENT kirjailijat (nimi, historia)+>
    <!ELEMENT nimi       (#PCDATA)>
    <!ELEMENT historia   (#PCDATA | kuva | kuvat | teos)*>
    <!ELEMENT kuva       EMPTY>
    <!ATTLIST kuva
              tiedosto   ENTITY    #REQUIRED >
    <!ELEMENT kuvat      EMPTY >
    <!ATTLIST kuvat
              tiedostot  ENTITIES  #REQUIRED >
    <!ELEMENT teos       (#PCDATA) >
]>
<kirjailijat>
    <nimi>Kunto Kirjailija</nimi>
    <historia>
		Kunto Kirjailijasta tiedetään vain vähän. Jälkipolville hänestä ovat
		säästyneet vain kolme kuvaa: 
        <kuvat tiedostot="kuva1 kuva2 kuva3"/>

        Hänen tunnetuin teoksensa oli 
        <teos>Maailman rakenteet</teos>
        <kuva tiedosto="kansikuva"/>
    </historia>
</kirjailijat>

Ylläolevassa esimerkissä 'kuvat'-elementillä on 'tiedostot'-määrite, joka on ENTITIES-tyyppinen. Kaikki määritteen arvossa luetellut nimet täyttävät Name-säännön ja arvo kokonaisuudessaan täyttää Names-säännön. Lisäksi jokaista nimeä vastaava jäsentämätön entiteetti on esitelty rakennemäärittelyssä. Eli näiltä osin dokumentti noudattaa rajoitusta.

Sen sijaan 'kuva'-elementin 'tiedosto'-määritteelle annettu arvo rikkoo rajoitusta vastaan. Arvo noudattaa Name-sääntöä, mutta vastaavan nimistä entiteettiä ei ole esitelty rakennemäärittelyssä.

Koskee sääntöä: TokenizedType (56)

ID-tyyppisen määritteen arvo (ID)

Selitys: ID-tyyppisen määritteen arvon on toteutettava Name-sääntö. Arvo ei saa esiintyä kahdesti ID-tyyppisessä määritteessä samassa dokumentti-ilmentymässä. Toisin sanoen ID-tyyppisen määritteellä on oltava yksikäsitteinen arvo koko dokumentin alueella.

Rajoituksen takana on ajatus elementin tunnistamisesta sen ID-tyyppisen määritteen avulla. Mikäli kahdella elementillä olisi sama arvo, eivät ohjelmat esimerkiksi kykenisi erottamaan kumpaan elementtiin hypertekstilinkki osoittaa.

Esimerkki:

<?xml version="1.0"?>
<!DOCTYPE tekijat [
    <!ELEMENT tekijat     (kirjoittaja, kuvittaja)+ >
    <!ELEMENT kirjoittaja (#PCDATA)>
    <!ATTLIST kirjoittaja
              hetu        ID  #REQUIRED>
    <!ELEMENT kuvittaja   (#PCDATA)>
    <!ATTLIST kuvittaja
              hetu        ID  #REQUIRED>   
]>
<tekijat>
    <kirjoittaja hetu="120364-546X">
        <nimi>Aimo Kirjailija</nimi>
    </kirjoittaja>
    <kuvittaja hetu="120364-546X">
        <nimi>Kosti Kuvataiteilija</nimi>
    </kuvittaja>
<tekijat>

Esimerkissä oleva 'hetu'-määrite on ID-tyyppinen, jolloin sama arvo esiintyy virheellisesti kahdessa ID-tyyppisessä määritteessä saman dokumentin sisällä.

Koskee sääntöä: TokenizedType (56)

ID-tyyppisen määritteen luokka (ID Attribute Default)

Selitys: ID-tyyppinen määrite voi olla joko valinnainen (#IMPLIED) tai pakollinen (#REQUIRED). ID-tyyppisen määritteen on tarkoitus toimia elementin yksikäsitteisenä tunnuksena, joten on luonnollista, ettei sille saa antaa kiinteätä oletusarvoa (#FIXED).

Mikäli elementtityypille määrättäisiin jokia oletusarvo, koskisi se jokaista tyypin mukaista elementtiä, jolle ei erikseen olisi annettu uutta arvoa. Tällöin kahdella (tai useammalla) elementillä voisi rakennemäärittelyn mukaan olla sama arvo, mikä puolestaan tuhoaisi ID-tyyppisen määritteen yksikäsitteisyyden.

Esimerkkejä: Sallitut ID-tyypisen määritteen esittelyt:

<!ATTLIST kirja
          isbn ID #REQUIRED>

<!ATTLIST kirjoittaja
          hetu ID #IMPLIED>

Koskee sääntöä: TokenizedType (56)

IDREF(S)-tyyppisen määritteen arvo (IDREF)

Selitys: IDREF-tyyppisen määritteen arvon on oltava Name-säännön mukainen, samoin kuin IDREFS-tyyppisen määritteen arvon on oltava Names-säännön mukainen.

Jokaisen IDREF-tyyppisen määritteen arvon on myös vastattava samassa dokumentti-ilmentymässä olevan ID-tyyppisen määritteen arvoa. Sama koskee myös IDREFS-tyyppisen määritteen arvon osia, eli jokaista osaa, joka vastaa Names-säännön osina olevia Name-sääntöjä.

Esimerkki:

<?xml version="1.0"?>
<!DOCTYPE kirjasto [
    <!ELEMENT kirjasto   (kirja+)>
    <!ELEMENT kirja      (teos, tiivistelma)>
    <!ATTLIST kirja 
              tunniste   ID     #REQUIRED>
    <!ELEMENT teos       (#PCDATA)>
    <!ELEMENT tiivistema (#PCDATA | viite)*>
    <!ELEMENT viite      (#PCDATA)>
    <!ATTLIST viite
              teos       IDREF  #REQUIRED>
]>
<kirjasto>
    <kirja tunniste="4367s">
        <teos>Tunnisteiden tunnistaminen</teos>
        <tiivistelma>
            Kirja kertoo keinot XML-tunnisteiden havaitsemiseen.
        </tiivistelma>
    </kirja>
    <kirja tunniste="4390s">
        <teos>Tunnisteiden tunnistaminen, osa 3</teos>
        <tiivistelma>
            Teos jatkaa 
            <viite teos="4367s">osan 1</viite> ja
            <viite teos="4385s">osan 2</viite> 
            perinteitä ja tarjoaa innokkaalle tunnistebongarille uusia 
            välineitä tunnisteiden havaitsemiseen.
        </tiivistelma>
    </kirja>
</kirjasto>

Esimerkissä esiintyy kaksi IDREF-tyyppistä määritettä 'viite'-elementeissä. Määritteistä ensimmäinen noudattaa rajoitusta, sillä se saa arvokseen 'kirja'-elementin 'tunniste'-määritteen arvon, joka on ID-tyyppinen. Sen sijaan jälkimmäisen 'teos'-määritteen arvo ei ole sallittu, sillä dokumentissa ei esiinny yhtään ID-tyyppistä määritettä, jolla olisi sama arvo.

Koskee sääntöä: TokenizedType (56)

Kiinteäarvoisen määritteen arvo (Fixed Attribute Default)

Selitys: Jos määritteen luokka on #FIXED, on sen ilmentymissä saaman arvon oltava sama kuin esittelyssä mainittu arvo.

Esimerkki: 'kortti'-elementille on määrätty 'valmistaja'-määrite, jonka kiinteä arvo on 'Korttitalo Oy'. Dokumentti-ilmentymässä määritteen ensimmäisen esiintymän arvo on oikein, sillä se on sama kuin kiinteä arvo. Sen sijaan toisen 'valmistaja'-määritteen saama arvo on eri kuin kiinteäksi määrätty arvo, mistä syystä dokumentti ei täytä tätä validisuusrajoitusta.

<?xml version="1.0" ?>
<!DOCTYPE [
    <!ELEMENT korttivalikoima (kortti+) >
    <!ELEMENT kortti          (nimi, hinta) >
    <!ATTLIST kortti
              valmistaja      CDATA     #FIXED "Korttitalo Oy" >
    <!ELEMENT nimi            (#PCDATA) >
    <!ELEMENT hinta           (#PCDATA) >
    <!ATTLIST hinta
              yksikko         (mk | e)  #REQUIRED >
]>
<korttivalikoima>
    <kortti valmistaja="Korttitalo Oy">
        <nimi>Kesätuulahdus</nimi>
        <hinta yksikko="mk">10.50</hinta>
    </kortti>
    <kortti valmistaja="Korttihuijarit Oy">
        <nimi>Kesäpulahdus</nimi>
        <hinta yksikko="e">10.50</hinta>
    </kortti>
</korttivalikoima>

Koskee sääntöä: DefaultDecl (60)

Luetellun määritteen arvot (Enumeration)

Selitys: Luetellun määritteen arvon on oltava jokin kyseisen määritteen esittelyssä ilmoitetuista arvoista. Jokaisen esittelyssä luetellun arvon on puolestaan noudatettava Nmtoken-sääntöä.

Esimerkki:

<?xml version="1.0"?>
<!DOCTYPE teoskokoelma [
    <!ELEMENT teoskokoelma (teos+) >
    <!ELEMENT teos         (nimi, tekija) >
    <!ATTLIST teos
              tyyppi       (kirja | maalaus | runo | veistos)  #REQUIRED >
    <!ELEMENT nimi         (#PCDATA) >
    <!ELEMENT tekija       (#PCDATA) >
]>
<teoskokoelma>
    <teos tyyppi="kirja">
        <nimi>Taitavan kirjoittamisen opas</nimi>
        <tekija>Taitava Kirjailija</tekija>
    </teos>
    <teos tyyppi="piirros">
        <nimi>Intiaanikesä</nimi>
        <tekija>Suti Kynänen</tekija>
    </teos>
</teoskokoelma>

Lueteltu määrite 'tyyppi' esiintyy esimerkissä kahdesti. Ensimmäisessä esiintymässä määritteen saama 'kirja'-arvo on rajoituksen mukainen, sillä se on ilmoitettu määritteen esittelyssä. Jälkimmäisen 'tyyppi'-määritteen saama 'piirros'-arvo sen sijaan rikkoo rajoitusta vastaan, sillä se ei esiinny määritteen esittelyssä.

Jokainen 'tyyppi'-määritteen esittelyssä mainituista arvoista noudattaa Nmtoken-sääntöä

Koskee sääntöä: Enumeration (59)

Määritteen oletusarvon säännönmukaisuus (Attribute Default Legal)

Selitys: Kaikessa yksinkertaisuudessaan rajoitus tarkoittaa, että määrittelyn oletusarvoksi annetun arvon on noudatettava siihen liittyviä sääntöjä. Esimerkiksi arvossa ei saa olla '<'-merkkiä tai ID-tyyppisen määritteen arvon ensimmäisen merkin on oltava kirjain, '_' tai ':', jne.

Esimerkki:

<?xml version="1.0" ?>
<!DOCTYPE testidokumentti [
    <!ELEMENT testidokumentti (testi*) >
    <!ELEMENT testi           (#PCDATA) >
    <!ATTLIST testi
              koe             ID  #REQUIRED >
]>
<testidokumentti>
    <testi koe="ensimmäinen määrite">
        Tämä dokumentti on tehty vain testausta varten. Kiitos mielenkiinnostanne.
    </testi>
    <testi koe="2. määrite">
        Tämä dokumentti on tehty vain testausta varten. Kiitos mielenkiinnostanne.
    </testi>
</testidokumentti>

Esimerkin dokumentti ei ole validi. Validisuuden rikkoo jälkimmäinen 'koe'-määrite. 'koe' on ID-tyyppinen, jolloin määritteen arvo ei saa alkaa numerolla kuten jälkimmäisessä ilmentymässä.

Koskee sääntöä: DefaultDecl (60)

Määritteen validisuus (Attribute Value Type)

Selitys: Perusajatukseltaan tämä rajoitus on määritteille vastaava kuin Elementin validisuus -rajoitus on elementeille. Eli rajoitus määrittelee validin määritteen - tosin paljon lyhyemmin kuin elementtien vastaava rajoitus, sillä suurin osa määritteihin liittyvistä rajoituksista on yhdistetty muihin sääntöihin.

Täyttääkseen tämän rajoituksen, on määritteen oltava esitelty rakennemäärittelyssä ja sen arvon tyypin on oltava sama kuin mitä esittelyssä on määrätty.

Esimerkki:

<!ELEMENT kirja     (nimi, kansikuva)>
<!ELEMENT nimi      (#PCDATA)>
<!ELEMENT kansikuva EMPTY >
<!ATTLIST kansikuva
          kuva        ENTITY  #REQUIRED >

Yllä esitellyn 'kirja.dtd'-rakennemäärittelyn mukaan 'nimi'-elementtityypillä ei ole lainkaan määritteitä ja 'kansikuva'-elementtityypillä 'kuva'-määrite saa arvokseen entiteetin. Alla olevassa dokumentissa on kuitenkin virheellisesti annettu 'luokka'-määrite 'nimi'-elementille sekä URL-osoite entiteetin nimen sijaan 'kuva'-määritteelle. Jäsennin ei tunnista URL-osoitetta entiteetiksi (todennäköisesti jäsennin tulkitsee URL:n CDATA-tyyppiseksi arvoksi), joten 'kuva'-määrite saa vääräntyyppisen arvo.

<?xml version="1.0"?>
<!DOCTYPE kirja SYSTEM "kirja.dtd">
<kirja>
    <nimi luokka="lastenkirjat" >Lasten oma XML</nimi>
    <kanskuva kuva="http://www.kuva.koti/kansikuva.png" />
</kirja>

Koskee sääntöä: Attribute (41)

NMTOKEN(S)-tyyppisten määritteiden arvot (Name Token)

Selitys: NMTOKEN-tyyppisen määritteen arvon on noudatettava Nmtoken-sääntöä. Vastaavasti NMTOKENS-tyyppisen määritteen on noudatettava Nmtokens-sääntöä.

Esimerkki:

<?xml version="1.0"?>
<!DOCTYPE tilaus [
    <!ELEMENT tilaus       (paketti+, toimitustapa)+ >
    <!ELEMENT paketti      (#PCDATA) >
    <!ATTLIST paketti
              luokitus     NMTOKEN   #REQUIRED >
    <!ELEMENT toimitustapa (#PCDATA) >
    <!ATTLIST toimitustapa
              luokitukset  NMTOKENS   #IMPLIED >
]>
<tilaus>
    <paketti luokitus="5">
        XML-kirjoja
    </paketti>
    <paketti luokitus="10e">
        Jälkitilaus XSL-kirjoja
    </paketti>
    <toimitustapa luokitukset="5 6 10e 12e">
        Pikkupaketissa rahtina.
    </toimitustapa>
</tilaus>

Kaikki esimerkin määritteiden arvot ovat rajoituksen mukaisia. 'luokitus'-määrite on NMTOKEN-tyyppinen ja noudattaa Nmtoken-sääntöä, jonka mukaan arvo saa alkaa numerolla. 'luokitukset'-määrite on puolestaan NMTOKENS-tyyppinen ja sen saama arvo on Nmtokens-säännön mukainen.

Koskee sääntöä: TokenizedType (56)

Notaation oltava esitelty (Notation Declared)

Selitys: Jos entiteetti on notaatiotyyppinen, on siinä ilmoitettua notaation nimeä vastaavan notaation oltava esitelty.

Esimerkki: Ensimmäisen entiteetin esittely on sallittu, sillä sen notaatioksi on ilmoitettu 'gif', joka on esitelty. Sen sijaan jälkimmäisen esittelyn 'png'-nimistä notaatiota ei ole esitelty, mikä rikkoo dokumentin validisuuden.

<!NOTATION gif   PUBLIC  "-//CompuServe Information Services, Inc.//NOTATION Graphics Interchange Format (GIF)//EN">
<!ENTITY   pic1  SYSTEM  "./pics/logo.gif"     NDATA  gif>
<!ENTITY   pic2  SYSTEM  "./pics/biglogo.png"  NDATA  png>

Koskee sääntöä: NDataDecl (76)

Notaatiotyyppisen määritteen arvot (Notation Attributes)

Selitys: Notaatiotyyppiselle määritteelle saa antaa vain sen esittelyssä mainittuja arvoja. Jokaisen määritteen esittelyssä mainitun notaation nimen on myös oltava esitelty rakennemäärittelyssä.

Esimerkki:

<?xml version="1.0" ?>
<!DOCTYPE kokoelma [
    <!NOTATION ps        SYSTEM  "/bin/ghostview" >
    <!NOTATION pdf       SYSTEM  "/bin/acrobat" >
    <!ELEMENT  kokoelma  (kirja+) >
    <!ELEMENT  kirja     (teos, sisalto) >
    <!ELEMENT  sisalto   (#PCDATA) >
    <!ATTLIST  sisalto
               formaatti NOTATION (ps | rtf) #IMPLIED
               viite     CDATA               #IMPLIED >
]>
<kokoelma>
    <kirja>
        <teos>Suuri XML-tietokirja</teos>
        <sisalto formaatti="ps" viite="ps-tiedosto.ps></sisalto>
    </kirja>
    <kirja>
        <teos>Maailmankaikkeuden keittokirja</teos>
        <sisalto formaatti="pdf" viite="pdf-tiedosto.ps"></sisalto>
    </kirja>
<kokoelma>

Esimerkissä esitellään 'formaatti'-määrite, joka voi saada arvokseen joko 'ps' tai 'rtf'. 'formaatti' rikkoo rajoitusta vastaan, sillä se on notaatiotyyppinen määrite, mutta sen toista arvoa ('rtf') ei esitellä rakennemäärittelyssä. Myös dokumentti-ilmentymä rikkoo rajoitusta vastaan, sillä 'formaatti'-määrite saa jälkimmäisessä ilmentymässään arvokseen 'pdf', joka kyllä on esitelty rakennemäärittelyssä mutta ei ole määritteen sallittu arvo.

Koskee sääntöä: NotationType (58)

Pakollisen määritteen arvo (Required Attribute)

Selitys: Mikäli määrite on esittelyssä luokiteltu pakolliseksi (#REQUIRED), on sille annettava arvo jokaisessa elementtityypin ilmentymässä, johon se liittyy.

Esimerkki:

<!ELEMENT kirja (nimi, kustantaja)>
<!ATTLIST kirja
          tunniste ID #REQUIRED>

Yllä olevassa rakennemäärittelyssä 'kirja'-elementtityyppiin liittyvä 'tunniste'-määrite on määrätty pakolliseksi. Tällöin seuraavasta dokumenttikatkelmasta ensimmäinen 'kirja'-elementti on rajoituksen mukainen mutta jälkimmäinen ei, sillä siinä 'tunniste'-määritteelle ei annata arvoa:

<kirja tunniste="23-1099">
        <nimi>Matti Mainion maineikkaan matkat</nimi>
        <kustantaja>Kustantamo Oy</kustantaja>
</kirja>
<kirja>
        <nimi>XML:n uusimmat määrittelyt</nimi>
        <kustantaja>Kustantamo Oy</kustantaja>
</kirja>

Koskee sääntöä: DefaultDecl (60)

Parametrientiteettien käyttö esittelyissä (Proper Declaration/PE Nesting)

Selitys: Mikäli merkkausesittelyn (markupdecl-sääntö) ensimmäinen ('<') tai viimeinen merkki ('>') kuuluu parametrientiteetin korvaavaan tekstiin, täytyy kyseisen korvaavan tekstin sisältää kokonainen merkkausesittely (eli lähinnä sekä aloittavan että lopettavan merkin). Tosin sanoen merkkausesittelyn on sekä alettava että loputtava joko yhdessä parametrientiteetissä tai sitten kaikkien parametrientiteettien ulkopuolella.

Esimerkkejä: Seuraavassa esimerkissä on kaksi virhettä. Ensimmäinen virhe on elementtityypin esittelyjen aloittaminen parametrientiteetillä, vaikka kumpikin esittely loppuu aloittavan entiteetin ulkopuolella. Toinen virhe on ensimmäisessä elementtityypin esittelyssä, sillä se alkaa ja päättyy eri parametrientiteeteissä.

<!ENTITY % esittelynAlku "<!ELEMENT ";>
<!ENTITY % lopetus "tekijä, kustantaja, tiivistelmä)>";>
%esittelynAlku;kirja (teos, %lopetus;
%esittelynAlku;novelli (nimi, tekijä, kustantaja)>

Toisessa esimerkissä parametrientiteettejä on käytetty oikein: ensimmäinen esittely alkaa ja päättyy samassa parametrientiteetissä ja toisen esittelyn alku ja loppu ovat kokonaan parametrientiteettien ulkopuolella. Kannattaa kuitenkin muistaa, että tälläinen käyttötapa ei ole sallittua rakennemäärittelyn sisäisessä osajoukossa.

<!ENTITY % julkaisutiedot "tekijä, kustantaja";>
<!ENTITY % kirjanTiedot "<!ELEMENT kirja (teos, %julkaisutiedot;, tiivistelmä)>";>
%kirjanTiedot;
<!ELEMENT novelli (nimi, %julkaisutiedot;)>

Koskee sääntöä: markupdecl (29)

Parametrientiteettien ryhmittely esittelyissä (Proper Group/PE Nesting)

Selitys: Jos parametrientiteetin korvaava teksti sisältää choice-, seq- tai Mixed-säännön alku- tai loppusulun, täytyy sen sisältää myös vastaava loppu- tai alkusulku.

Rajoituksen tarkoituksena on helpottaa XML-jäsentimen toimintaa.

Esimerkki: Seuraavassa rakennemäärittelyn ulkoisessa osajoukossa viitataan kolmeen parametrientiteettiin, joista vain viittaus 'nimet'-entiteettiin on rajoituksen mukaan sallittu. 'kirja'-elementin esittely sisältää seq-säännön täyttävän sisältömallin, jolloin alku- ja loppusulun on oltava samassa parametrientiteetissä. Näin ei kuitenkaan ole, sillä alkusulku on 'julkaisutiedot'-entiteetissä ja loppusulku 'kuvaus'-entiteetissä.

<!ENTITY % julkaisutiedot "(teos, kirjoittaja">
<!ENTITY % kuvaus         "tiivistelma)">
<!ENTITY % nimet          "(etunimi, sukunimi)">

<!ELEMENT kirja           %julkaisutiedot;, %kuvaus;>
<!ELEMENT kirjoittaja     %nimet;>
<!ELEMENT teos            (#PCDATA)>
<!ELEMENT tiivistelma     (#PCDATA)>
<!ELEMENT etunimi         (#PCDATA)>
<!ELEMENT sukunimi        (#PCDATA)>

Koskee sääntöjä: choice (49), seq (50), Mixed (51)

Riippumattomuusesittelyn arvo (Standalone Document Declaration)

Selitys: Riippuumattomuusesittelyn arvon täytyy olla "no", mikäli rakennemäärittelyn sisäisen osajoukon ulkopuolella on esitelty seuraavanlaista merkkausta:

Määritteitä, joille on määrätty oletusarvo. Tämä pätee vain jos dokumentti-ilmentymässä on elementtityyppien esiintymiä, joilla on tällainen määrite, eikä kyseiselle määritteelle ole annettu mitään arvoa (eli määritteellä ei ole ilmentymää).
Muita entiteettejä kuin amp, lt, gt, apos ja quot, mikäli niihin viitataan dokumentissa.
Määritteitä, joiden dokumentti-ilmentymässä annettu arvo muuttuu normalisoinnin yhteydessä.
Elementtityyppien esiintymiä, joilla on pelkästään elementtityypeistä koostuva sisältö, ja sisältöön kuuluvien elementtien välissä on erotinmerkkejä.

Esimerkki: Esimerkissä käytetään seuraavaa rakennemäärittelyn ulkoista osajoukkoa, jonka nimi on 'kirja.dtd'.

<!ENTITY  sarjanNimi      "XML" >

<!ELEMENT kirja           (teos, tekija, kustantaja)>
<!ATTLIST kirja
          toimittaja      CDATA  "Kunto Kirjakustantaja"
          sarja           CDATA  #IMPLIED >
<!ELEMENT teos            (#PCDATA)>
<!ELEMENT tekija          (#PCDATA)>
<!ELEMENT kustantaja      (#PCDATA)>
<!ENTITY  kustantajanNimi "Kustantamo Oy">

Itse dokumentti on seuraavanlainen:

<?xml version="1.0" standalone="yes" ?>
<!DOCTYPE kirja SYSTEM "kirja.dtd">
<kirja sarja="&sarjanNimi;-sarjan
atk-klassikot">
    <teos>Dokumentti ja &amp;-entiteetti</teo>
    <tekija>Äksymil Osaja</tekija>
    <kustantaja>&kustantajanNimi;</kustantaja>
</kirja>

Ulkoisessa osajoukossa 'kirja'-elementtityypille määrätään 'toimittaja'-määrite, jolla on oletusarvo. Tällöin määritteen on esiinnyttävä myös dokumentti-ilmentymässä, jos riippumattomuusesittelyn arvo on "yes" - näin ei esimerkkidokumentissa kuitenkaan tapahdu.

Toinen virhe on 'sarja'-määritteen saama arvo, joka muuttuu arvoksi "XML-sarjan atk-klassikot" kun entiteettiviittaukset ja rivinvaihto normalisoidaan. Kolmas virhe on erotinmerkkien käyttö vain elementtityyppejä sisältävässä elementtityypissä, esimerkiksi 'kirja'-elementin sisällä olevan 'teos'-elementin edellä.

Viimeisenä ongelma vastaan tulee viittaus 'kustantajanNimi'-entiteettiin, joka esitellään rakennemäärittelyn ulkoisessa osajoukossa.

Koskee sääntöä: SDDecl (32)

Sivua on edellisen kerran päivitetty: 07.02.2000.
Kommentteja voi lähettää Henri Ruinille osoitteeseen ruini@cs.helsinki.fi.