XML

Dokumentumtípus



CDATA és NMTOKEN típusok:

A dokumentumtípus definíciók az XML dokumentumok szerkezeti szabályait írják le. Ahhoz, hogy egy XML dokumentumot érvényesíthessünk, mindenek előtt szükséges, hogy az XML dokumentum egy létező (és helyes) dokumentumtípus definícióra hivatkozzék. Egy XML dokumentum érvényessége tehát mindig egy dokumentumtípushoz kötött. amely csak akkor ellenőrizhető, ha a dokumentum deklarálja, hogy milyen dokumentumtípushoz tartozik, és érvényes, ha annak meg is felel. Egy XML dokumentum érvényessége valójában azzal ekvivalens, hogy a „megfelelő szót” a „megfelelő helyen” használja. Ha egy XML dokumentum nem deklarálja, hogy mely dokumentumtípushoz tartozik, az nem jelenti azt, hogy érvénytelen, csak annyit jelent, hogy nem érvényesíthető.



elemtípus definíciók (element type declarations):

elem-típus ::= <!ELEMENT sp elemtípus-név sp tartalom [sp] >

tartalom ::= üres-tartalom | bármilyen-tartalom | vegyes-tartalom | elem-tartalom

üres-tartalom := EMPTY

bármilyen-tartalom ::= ANY

vegyes-tartalom ::= (#PCDATA) | (pcdata-elemtípus-felsorolás)*

pcdata-elemtípus-felsorolás ::= #PCDATA | elem-tartalom

elem-tartalom ::= elemtípus-név | szabványos-kifejezés(elem-tartalom) 

Az elemek (elements) az XML szerkezet-leírás alapkövei. Minden elem egy érvényes XML dokumentumban megfelel a vonatkozó DTD egy elemtípusának. Egy elemtípus definíció tartalmazza az elemtípus nevét, és a tartalmára vonatkozó szerkezeti (típus) leírást.

Az elemtípus-név egy szabályos név, egy elemtípus neve. Az elemtípus neveknek egyedieknek kell lenniük. A #PCDATA (Parsed Character DATA) karakter tartalmat jelöl, de ez tartalmazhat szerkezetleírót (entitás-referencia). A #PCDATA elemtípust akkor is vegyes tartalomnak tekintjük, ha az ilyen típusú elemek beágyazott elemeket nem tartalmaznak. A pcdata-elemtípus-felsorolás  definíciójában a | karakter félkövér betűtípussal szerepel (tehát nem a szabályok leírásakor használt metajel). A szabványos-kifejezések a tartalmi elemek előfordulását, azok számát és relatív sorrendjét definiálja az alábbi indikátor-operátorokkal : 

indikátor név                             operator                                          jelentés

üres operator                             hatástalan

egymáshoz fűzés                           az elemek relatív sorrendjét írja le

felsorolás                                választás több megengedett elem közül

opcionális tartalom                       legfeljebb egyszer megjelenő tartalom

kötelező tartalom                         legalább egyszer megjelenő tartalom

opcionális többszörös tartalom            a tartalom opcionális

 Egy példa:

<!ELEMENT poem (verse | verse*)>

<!ELEMENT verse (sor+)>

<!ELEMENT sor (#PCDATA)>

 

attributumok (Attributes):

attribútum-lista-definíció ::= <!ATTLIST sp elemtípus-név attribútum-definíció… [sp]>

attribútum-definíció ::= sp attribútum-név sp  attribútum-típus sp alapértelmezés

attribútum-típus ::= CDATA | (felsorolás) | NOTATION sp (felsorolás) | ID | IDREF |   IDREFS | ENTITY | ENTITIES | NMTOKEN | NMTOKENS

felsorolás ::= névszó [| névszó]…

alapértelmezés ::= #REQUIRED | #IMPLIED | #FIXED sp literál | literál

Az attribútumok lehetőséget nyújtanak az XML dokumentumok szerzőinek ahhoz, hogy további információkat (tulajdonságokat) határozzanak meg egy elemtípus leírásakor. Az elemtípus definíciók globális szerkezeti felépítés leírását engedik meg, de ezek a definíciók nem teszik lehetővé, pl., azt a tényt, hogy a dokumentum érdemi szövege angolul íródott, vagy azt, hogy egy elemtípus egy adott előfordulása egy másik elemtípus egy előfordulására hivatkozzék. Az attribútumok segítségével leírható extra-információk természetesen (bár néha csak körülményesen) megadhatók kizárólag elemtípus definíciókkal. Az attribútumok használata egy egyszerű alternatíva. Két alapvető különbség van az elemek és attribútumaik között:

·        Az attribútumoknak nincsenek „elemeik” (nincsenek egymásba ágyazott attribútumok

·        Az attribútumok neveinek csak egy elemen belül kell egyedieknek lenniük.

Az elemtípus-név annak az elemtípusnak a neve, amelyhez az attribútumot definiáljuk. Az attribútum-név a definiálandó attribútum neve. Egy attribútum név egy adott elemtípusnál legfeljebb egyszer definiálható. Az attribútumok definiálási sorrendje nem határozza meg a vonatkozó XML dokumentumban az elemtípushoz tartozó elem kezdő-tagjában az attribútumok megadási sorrendjét. Az alapértelmezésben szereplő literál az & jelet entitáshivatkozásnak tekinti, ezért annak ettől eltérő használata csak a &amp; alakban lehetséges.

CDATA és NMTOKEN típusok

A legegyszerűbb attribútum típus. A CDATA (Character DATA) típusú attribútumok érétke tetszőleges literál. Az NMTOKEN típus ezt korlátozza: olyan karakterek előfordulását engedi meg, amelyek a névszót alkotnak. Az üres karakterlánc pl. egy érvényes CDATA érték, de érvénytelen névszó.

Felsorolás és NOTATION típusok:

A felsorolás típus egy olyan értékhalmazt definiál, amelynek elemei névszók. Az ilyen típusú attribútumok csak a felsorolás típus által definiált halmazbeli értékek valamelyikét veheti föl. Ehhez kapcsolódó típus a NOTATION típus. Az utóbbi szerepe az ún. NOTATION deklarációkhoz is kapcsolódik annyiban, hogy a felsorolással definiált értékhalmaz csak a NOTATION deklarációban deklarált névszókat tartalmazhat.

ID és IDREF típusok:

Már a bevezetőben említettük, hogy a valós világ dokumentumai nem mindig tesznek eleget faszerkezettel reprezentálható objektum modellnek. Az XML az ID típusú attribútummal lehetőséget biztosít arra, hogy bármely meghatározott elemet egy egyedi névvel lássunk el. Vegyük észre, hogy ez az azonosítás nem ugyanaz, amelyet (az ugyancsak egyedi) elemtípus név biztosít, hiszen ez minden ilyen típusú elemnek az (egyedi) neve, és természetesen nem alkalmas arra, hogy egy bizonyos az adott elemtípushoz tartozó előfordulást azonosítson. Az így azonosított meghatározott elemekre azután más elemek egy IDREF típusú attribútummal tudnak hivatkozni.

ENTITY típus:

Az ilyen típusú attribútumok entitások neveit kaphatják értékül. Ahogy a NOTATION típus kapcsolatban van a NOTATION deklarációval, ugyanúgy az ENTITY típus kapcsolatban van az ENTITY deklarációval.

A fentiekből kiderül, hogy két olyan típus van, amely felsorolás típusú (az ezekben előforduló lehetséges értékek csak névszók lehetnek). A maradék típusokra, a CDATA típust leszámítva, ez a megszorítás szintén érvényes. Az NMTOKEN, IDREF és ENTITY típusok esetében léteznek a „többes számú” típusok (NMTOKENS, IDREFS és ENTITIES), amelyekhez tartozó attribútumok nem egy ilyen típusú értéket, hanem ilyen típusú értékek listáját hordozzák. Az értéklista elemeit szóköz karakterek választják el egymástól.

Alapértelmezés:

Az attribútumokra adható alapértelmezések a következők:

·        #REQUIRED: az attribútum érték megadása kötelező az XML dokumentumban.

·        #IMPLIED: az attribútum megadása opcionális az XML dokumentumban.

·        #FIXED sp literál: az attribútum megadása opcionális, de megadásakor az XML dokumentumban ugyanazt az értéket kell megadnunk, amely egybeesik a megadott rögzített értékkel literál az attribútum alapértéke.

NOTATION deklaráció:

A deklaráció Az XML dokumentumok legkülönbözőbb részeiben előforduló tartalmi jelentésekhez, kategóriákhoz rendel belső nevet. Az így deklarált nevek lehetnek értékei a NOTATION típusú attribútumoknak. A NOTATION deklaráció egyik legtipikusabb alkalmazása az ún. nem-elemzendő (unparsed) entitások deklarálása. Ebben az esetben a NOTATION deklaráció egy nem XML adathoz (annak külső azonosítójához) rendel egy nevet. Ezeket az adatobjektumokat szokás nem elemzendő entitásnak is nevezni. Ahhoz, hogy ilyen entitásokat létrehozhassunk a vonatkozó adatobjektumot névvel kell ellátnunk. Az ilyen NOTATION név azután egy nem elemzendő entitás deklarációjában jelenik meg. A NOTATION nevek más felhasználási területei lehetnek a NOTATION típusú attribútumok értéke vagy feldolgozás-utasítás szerkezetleírók cél-utasítása, vagy annak része.

 Példa:

<!NOTATION isodate SYSTEM ’http://www.iso.ch/date_specification’>

<!NOTATION eudate SYSTEM  ’http://www.eu.eu/date_specification’>

<!ELEMENT today (#PCDATA)>

<!ATTLIST today date-format NOTATATION (isodate|eudate) #REQUIRED>

 

Entitás deklaráció:

entitás-deklaráció ::= általánosentitás-deklaráció | paraméterentitás-deklaráció

általánosentitás-deklaráció ::=  <!ENTITY sp entitás-név sp általánosentitás-definíció [sp]>

paraméterentitás-deklaráció ::= <!ENTITY sp % sp entitás-név sp paraméterentitás-definíció [sp]>

általánosentitás-definíció ::= entitás-érték | (külső-azonosító [ sp NDATA sp notation-név])

paraméterentitás-definíció ::= entitás-érték | külső-azonosító

paraméterentitás-hivatkozás ::= %entitás-név;

entitás-érték ::= literál

entitás-név ::= név

notation-név ::= név

Az entitásokkal bővebben a fizikai szerkezetről szóló rész foglalkozik.

feldolgozás-utasítás ::= <? Pinév sp utasítás ?>

Pinév ::= név

utasítás ::= Unicode

Az ún. feldolgozás utasítások (a továbbiakban PI) arra szolgálnak, hogy „üzenetet” küldjünk egy feldolgozó programnak úgy, hogy annak tudomásulvétele ne igényelje sem a DTD feldolgozását (elemzés), és ne befolyásolja a többi (más) feldolgozó programok dokumentumkezelő tevékenységét. Sokan úgy vélekednek, hogy ennek a szerkezetnek az alkalmazási lehetősége annyira ritka, hogy kár ezt a szerkezetet az XML-be átvenni. Az SGML alkotóinak egyike viszont az SGML kézikönyvben a következőket mondja a szerkezet ottani szükségességéről: „egy tökéletes világban, elismerem, nem lenne rá szükség, de ahogy azt valamennyien tudjuk, a világ nem tökéletes.” A PI-k használatánál mindig figyelembe kell vennünk, hogy ezek olyan „egyedi” utasítások kellenek, hogy legyenek, amelyek nincsenek kapcsolatban a dokumentum strukturális felépítésével, sokkal inkább a dokumentumok feldolgozásával (vagy egy speciális feldolgozással kapcsolatos) kívánalmakat fogalmaznak meg. Ha egy XML dokumentum sok PI-t tartalmaz, el kell gondolkodnunk azon, hogy dokumentumunk helyesen épült-e föl (pl.: megjelenítési formázást leíró XSL dokumentum túl sok PI esetén valószínűleg strukturálisan nem épül föl helyesen). Speciális feldolgozási környezetben, ne engedjünk  a kísértésnek, és a dokumentum szerkezeti leírását ne kódoljuk bele a feldolgozó programokba, hogy azután egy vagy néhány PI-vel ezeket aktiváljuk.

A Pinév annak a számítógépes programnak a neve, amelyiknek a PI szól. Az utasítás tetszőleges karaktersorozat, amely nem tartalmazhatja a PI-ket lezáró szerkezetleíró ?> jelkombinációt.   

A „standalone” dokumentumokról:

Ha visszaidézzük az xml deklarációt, az maga egy speciális PI. Speciális, mert speciálisan az XML processzornak szóló utasítás, amely az XML dokumentum processzálásával (esetleg érvényesítésével) kapcsolatos instrukciókat közöl. Már korábban megemlítettük, hogy az xml deklarációban a standalone értékét általában no-ként kell megadnunk (abból baj nem lehet). Azt is tisztáztuk, hogy a yes értékű standalone pontosan azt jelenti, hogy a dokumentum érvényesítéséhez nincs szükség a DTD külső részére. Az alábbiakban felsoroljuk azokat a DTD külső részére vonatkozó ismérveket, amelyek megléte esetén nem beszélhetünk „egyedül álló” (standalone) XML dokumentumokról.

Ha a DTD külső szegmense tartalmaz:

·        attribútum deklarációt, amelyeket az XML dokumentumban nem definiálunk az elem használatakor

·        olyan entitásokat (az előre definiált entitásoktól eltekintve), amelyekre az XML dokumentum hivatkozik

·        olyan az attribútum értékek normalizálását befolyásoló attribútum deklarációt, amelynek az értékét az XML dokumentumban adjuk meg, és a megadott érték megváltoztatja az attribútum értékek normalizálását (xml:space)

·        olyan tartalommal megadott elemtípusokat, amelyekhez tartozó bármely előfordulás nem látható karaktert közvetlenül tartalmaz.


Példa:

<say>

    <poem>

        <verse>

            <line> Fuzzy Wazyt was a bear. </line>

            <line> Fuzzy Wazyt had no hair. </line>

            <line> Fuzzy Wazyt was not fuzzy, was it? </line>

        </verse>

    </poem>

</say>

Dokumentumtípus és megadásuk

A valós világ dokumentumai, levelek, folyóiratok, telefonkönyv, regény, műszaki dokumentáció, mind, mind eltérő szerkezettel rendelkeznek, és az ember általában azonnal képes eldönteni egy papírlapról, hogy az feltehetően éppen egy folyóiratból, vagy esetleg egy telefonkönyvből származik. A dokumentum-típust a dokumentum elemei (a benne felhasználható elemtípusok) határozzák meg. Ha két dokumentum alapvetően különböző elemeket (különböző elemtípusokhoz tartozó előfordulásokat) tartalmaz, vagy ugyanolyan típusnévvel illetett elemeket alapvetően különböző sorrendben vagy hierarchiában használja, akkor az a két dokumentum nagy valószínűséggel különböző dokumentumtípushoz tartozik.

Az XML-ben a dokumentumtípusok jól formalizálhatók. Egy dokumentumtípus definíciója (DTD) azt írja le, hogy a dokumentumot alkotó elemek, attribútumok, entitások és jelölések hol és hogyan használhatók föl az XML dokumentumok készítésekor. Egy XML dokumentum specifikálhatja, hogy milyen dokumentumtípushoz tartozik. Ez a dokumentumtípus deklarálása. Példaképpen megadunk egy olyan DTD-t, amelynek megfelel a bevezetőben példaként bemutatott XML dokumentum.

 <!ELEMENT say (poem) >

<!ELEMENT poem (verse+) >

<!ELEMENT verse (line+) >

<!ELEMENT line (#PCDATA)>

A fenti DTD azt mondja, hogy egy mondóka (say) az egyetlen költemény (poem). A költemény (poem) legalább egy versszakból (verse) áll, amelyek mindegyike legalább egy sort (line) tartalmaz, továbbá, hogy minden sor (line) közönséges szövegből áll. A #PCDATA egy típus, amely a Parsed Character DATA kifejezésből származik, és ennek a típusnak az értékkészletébe beletartozik az egyszerű (XML szerkezetleírót nem tartalmazó) szöveg is, de ennél bővebb. A fenti angol kifejezés jelentése félrevezető, mert azt sugallja, hogy az ilyen típusú adat előfordulást már nem kell elemezni. Bár a PCDATA szó valóban a fenti kifejezésből ered, a fenti kifejezés egy leegyszerűsített és ily módon nagyon pongyola XML zsargon, amely a Character DATA to be Parsed fogalmat helyettesíti. Ahhoz, hogy a bevezetőben leírt dokumentumban deklaráljuk, hogy az a fenti dokumentumtípushoz tartozik, több lehetőségünk van. Az egyik legegyszerűbbet mutatja a következő példa.