2. ÓRA XML dokumentumok létrehozása A közönséges szövegformátum továbbra is él és virul, bár sokan jósolták már a halálát. – Bob Foster Hasonlóan a HTML-hez az XML is olyan technológia, amit leginkább úgy érthetünk meg, ha elkezdjük használni. Persze még oldalakon keresztül írhatnék a téma filozofikus vonatkozásairól, de a végén úgyis mindenki azt kérdezné: és tessék mondani, mire jó ez nekem? A munka legnagyobb részében magukkal az XML dokumentumokkal, azok szerkesztésével fogunk foglalkozni. Ez meglehetõsen hasonló lesz a weblapok szerkesztéséhez, legalábbis ami a kód strukturálását illeti. Ugyanakkor már most fontos megjegyezni, hogy az XML dokumentumok bármilyen információ tárolására alkalmasak. Miután elkészültünk egy XML dokumentummal, nyilván azonnal látni szeretnénk majd, hogyan néz ki egy webböngészõben, vagy miként használható egy alkalmazás segítségével. Mivel az XML tartalmak értelem szerinti megjelenítésének nincs általánosan bevett vagy szabványosított módszere, vagy fejlesztenünk kell egy olyan alkalmazást, amely a saját adatainkat kezeli, vagy egy olyan stíluslapot kell rendelnünk a doku-
02xml.qxd
5/16/2006
12:47 PM
Page 18
18 I. rész • Alapok
mentumunkhoz, amely lehetõvé teszi, hogy jól formázottan megjelenítsük egy webböngészõvel. Ebben az órában ezt az utóbbi megközelítést fogjuk használni. Részletesen a következõkrõl esik majd szó: • • • •
Az XML alapjai Hogyan válasszunk XML szerkesztõt Hogyan hozzunk létre egy XML dokumentumot Hogyan jelenítsük meg a tartalmát
Gyors bevezetés az XML használatába Az elõzõ órában megtanultuk, hogy az XML egy olyan jelölõnyelv, amely alapvetõen más jelölõnyelvek létrehozására szolgál. Abból a ténybõl, hogy az XML maga is jelölõnyelv, viszonylag egyenesen következik, hogy szemre számos hasonlóságot mutat a HTML-lel. Amint az elõzõ órában láttuk, az egyetlen lényeges eltérés elsõ látásra csupán annyi, hogy az XML-ben saját címkéket (tag) is használhatunk. A HTML-ben szokásos és helyett például láttunk és nevû címkéket. Összességében tehát akinek van némi gyakorlata a weblapok létrehozása terén, annak az egész dolog nagyon ismerõs, és kifejezetten egyszerû lesz. Persze azt is látni fogjuk hamarosan, hogy az XML egyáltalán nem olyan engedékeny nyelv, mint a HTML, tehát megeshet, hogy egyes eddig alkalmazott szokásainktól meg kell válnunk. Az igazat megvallva ezen a ponton talán kissé elõnyben lesznek azok, akiknek nincs a HTML-lel kapcsolatos gyakorlata, õk ugyanis észre sem fogják venni az XML merevségét.
Az XML építõkövei Akárcsak számos más jelölõnyelv, az XML is három különbözõ építõelemre támaszkodik. Tartalmaz elemeket, attribútumokat és értékeket. Az elem (element) olyan építõkocka, amely valamiféle információt ír le, vagy tartalmaz. Alapvetõen valamennyi XML dokumentum elemekbõl áll. Egy elemnek kötelezõen tartalmaznia kell legalább két címkét, egy nyitót, és egy zárót. A nyitó címkék kisebb nagyobb jelek (<>) közé zárt szavak, például , vagy . A záró címkék ehhez nagyon hasonlóak, de közvetlenül a címke neve elõtt tartalmaznak egy perjelet (/) is. Az imént említett két címkének megfelelõ zárócímke a és a . Egy elem tehát mindig a nyitó címkével indul, az esetek többségében tartalmaz valamilyen információt, majd a záró címkével végzõdik.
02xml.qxd
5/16/2006
12:47 PM
Page 19
2. óra • XML dokumentumok létrehozása 19
Ebben a példában nincs semmiféle adat a nyitó és a záró címke között annak demonstrálására, hogy a közbezárt adat megadása opcionális. Az XML nem törõdik a nyitó és záró címke közötti üres karakterekkel, vagyis teljesen megfelelõ a következõ írásmód is:
Persze fontos ehhez hozzátenni azt is, hogy az XML-ben a címkéknek alapvetõen az a rendeltetésük, hogy információdarabok elejét és végét jelezzék. Ennek megfelelõen meglehetõsen ritka az ilyen példa, amikor az elem ténylegesen üres. Az elemek általában szöveget, vagy más címkéket tartalmaznak. Lássunk erre is egy példát. A elem további elemeket tartalmazhat, például a barátok felsorolását, vagyis típusú elemeket:
Fontos megjegyezni, hogy az elem az XML-ben a tárol információ egy logikai egységét jelenti, míg a címke az XML kódban alkalmazott jelölés. Ezért van az, hogy az elemekre mindig a nevükkel hivatkozom (pet), míg a címkéket ugyanúgy írom, ahogy azok az XML kódban megjelennek. Az olvasó most biztosan csodálkozik, mert az elõzõ példában azt látta, hogy megszegtünk egy épp az imént kimondott szabályt, mely szerint egy elemnek mindig rendelkeznie kell egy nyitó és egy záró címkével. Látható, hogy a friend elemek egyetlen különleges címke formájában jelentek meg. A magyarázat egyszerû: az XML lehetõséget ad az üres elemek rövidítésére. Üres elemnek nevezzük az olyan elemet, amely semmit nem tartalmaz a nyitó és a záró címke között, vagyis sem szöveget, sem egyéb címkéket. A korábbi példákban láthattunk már ilyen elemeket, csak nem használtuk ezt a bizonyos rövidítési lehetõséget. Üres elemnél használhatunk olyan speciális címkét, amely a bezáró kisebb nagyobb jel elõtt egy perjelet (/) tartalmaz. Az üres friend elemet tehát bár közönségesen formában írnánk le, lehetõségünk van arra, hogy a jelölést használjuk. A /> elõtti szóköz opcionális, ugyanakkor használata általánosan bevett szokás az XML fejlesztõk körében. A nyitó és záró címkékkel kapcsolatos tárgyalás nem lehetne teljes egy a HTML dokumentumokban oly gyakran látott hiba említése nélkül. Igen, a bekezdések jelölésére használatos a
címkére gondolok, amelynek a fejlesztõk elõszeretettel hagyják el a záró párját. Bár a HTML-ben a p nyilván nem lehet üres elem, a HTML fejlesztõk mégis feltûnõen gyakran felejtik el a
záró címkét. Ha ugyanezt a szabados szerkesztési módszert egy XML dokumentumban próbáljuk meg használni, villámgyorsan bajba kerülünk.
2
02xml.qxd
5/16/2006
12:47 PM
Page 20
20 I. rész • Alapok
Most, hogy ilyen jól megbeszéltük az üres elemek lélektanát, talán tegyünk fel egy logikus kérdést. Mire jó nekünk egy üres elem? A magyarázat egyszerû: attól, hogy egy elemnek nincs tartalma, még tartozhatnak hozzá attribútumok, amelyek szintén hordozhatnak metainformációt. Az attribútumok olyan apró információdarabok, amelyek az elemek nyitó címkéjében bukkannak fel. Egy attribútumnak mindig van neve, és egy ehhez tartozó értéke, amelyeket egy egyenlõségjel választ el. Az érték mindig az egyenlõségjel jobb oldalán kell szerepeljen és mindig idézõjelek közé kell zárni. Íme egy példa arra, miként rendelhetünk egy friend típusú elemhez egy name nevû attribútumot:
Az attribútumok használata egy másik olyan terület, ahol a HTML dokumentumokban gyakran fedezhetünk fel furcsaságokat. A HTML attribútumokat általában idézõjelek nélkül használják, ami nyilvánvalóan ellentmond az XML szabványnak. Aki tehát szabadelvû HTML fejlesztõbõl sikeres XML fejlesztõvé szeretne válni, az sürgõsen szokjon le errõl, és tanulja meg használni az idézõjeleket. Elõzõ példánkban a name attribútumot a friend elem nevének meghatározására használtuk. Az attribútumok használata természetesen nem korlátozódik az üres elemekre, sõt egy elemhez több attribútum is tartozhat. Ha például egy állatkát részletesen akarunk leírni, több attribútumra is szükségünk lesz a pet elemen belül:
Összefoglalva tehát az attribútumok kiváló lehetõséget teremtenek arra, hogy egy elem tulajdonságait anélkül határozzuk meg, hogy a tartalmát módosítanánk.
Az elemek belülrõl Egy nem üres elem értelemszerûen olyan elem, amely a nyitó és a záró címke között valamilyen információt is tartalmaz. Amint azt korábban említettem, ez a tartalom lehet szöveg, vagy további elemek. Amikor elemen belül találhatók elemek, egymásba ágyazásról, vagy egymásba ágyazott elemekrõl beszélünk. Az egymásba ágyazott elemek mûködésének megértéséhez képzeljünk el egy társasházat. A házon belül lakások vannak, a lakásokon belül szobák. Bármelyik szobában lehetnek ezen kívül bútorok, a bútorokon pedig egyéb holmik. Az XML terminológia szerint a holmik a bútor típusú elemekbe vannak ágyazva, a bútor típusú elemek a szobákba, a szobák a lakásokba, a lakások pedig a házba. A 2.1. listában azt láthatjuk, hogyan lehet ezt a logikai struktúrát XML-ben megvalósítani.
02xml.qxd
5/16/2006
12:47 PM
Page 21
2. óra • XML dokumentumok létrehozása 21
2.1. lista
Egy társasház megvalósítása XML-ben
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
Ha figyelmesen olvassuk ezt a kódot, rájöhetünk, hogy az egymásba ágyazás a dolgok fizikai elrendezését követi. Vegyük észre továbbá, hogy a tartozékok (belonging) (5–7. sorok) elem üres, és ennek jelzésére a korábban említett rövidítést használjuk. Ezek az elemek helyenként azért maradhatnak üresen, mert a dolgok logikája nem követeli meg föltétlen, hogy tartalmuk legyen. Kicsit másként fogalmazva akár az is elképzelhetõ, hogy a tartozékok tulajdonságait kizárólag attribútumok segítségével írjuk le. A másik oldalról közelítve a dolgokhoz fontos azt is megjegyezni, hogy a nem üres elemeknek nem föltétlen kell tartalmazniuk más elemeket. A nyitó és záró címkék között lehet közönséges szöveg is, mint tartalom. Lássunk egy példát arra, hogyan adhatunk tartalmat a belonging elemnek. Kedves Michael, Örömmel értesítelek, hogy indulhatsz a nyereményjátékunkon. Egyike vagy ugyanis azoknak a szerencsés kiválasztottaknak, akik ha öt vagy annál több magazinra fizetnek elõ, akkor nyerhetnek némi pénzt. Vagy nem.
Mint látható, ebben a példában a belonging elem korai nyugdíjba vonulásom zálogát hordozza tartalom gyanánt. Az elemek néhány speciális szimbólumtól eltekintve bármilyen szöveget tartalmazhatnak. Ezekrõl a kivételekrõl egy kicsit késõbb esik majd szó, de még ebben az órában.
2
02xml.qxd
5/16/2006
12:47 PM
Page 22
22 I. rész • Alapok
Az XML öt parancsolata Most, hogy már kezdjük érezni, mire is jó az XML nyelv, ideje, hogy megtanuljuk a használatával kapcsolatos legfontosabb szabályokat. Amint azt korábban említettem, szabályait tekintve az XML sokkal merevebb nyelv, mint a HTML, ami azt jelenti, hogy bizonyos játékszabályok betartására sokkal jobban oda kell figyelnünk, amikor XMLben dolgozunk. Ami azt illeti, ez a merevség, nemhogy nem hátrány, hanem egyenesen elõny. Az XML épp a kódolási szabályok szigorúságán keresztül biztosítja azt, hogy segítségével sokkal konzisztensebb és megbízhatóbb formában tároljuk a leírni kívánt információt, mint HTML-ben. Az XML precízségének alapját öt olyan szabály adja, amelyeket jómagam az XML öt parancsolatának szoktam hívni. 1. A címkék neveiben a kis- és nagybetûk különbözõnek számítanak 2. Minden nyitó címkének meg kell legyen a záró párjai is (kivéve a rövidített formában leírt üres elemeknél) 3. Egymásba ágyazás esetén a címkék nem lapolódhatnak át. 4. Az attribútumok értékének mindig idézõjelek között kell megjelennie. 5. Minden dokumentumnak kell legyen gyökéreleme (root element). Kész vagyok elismerni, hogy az utolsó szabályban említett fogalomról eddig nem is volt szó, a többit azonban már tudjuk. Az elsõ szabály nem egyebet állít, mint hogy az XML-ben a kis- és nagybetûk különbözõnek számítanak. Ennek értelmében a , és mind különbözõ jelek. A HTML világból jövõknek ez egy igen lényeges eltérés, a weblapok esetében ugyanis nem ritka, hogy a fejlesztõ szabadon váltogatja például a és írásmódot a félkövér szöveg jelölésekor. XML esetében ez nem lehetséges, ott vagy az egyiket használjuk, vagy a másikat, de a kettõt egyszerre nem lehet. Az XML szabványokban általában azt javasolják, hogy használjunk vagy mindig kis, vagy mindig nagybetûs címkéket, bár a kevert használatnak sincs semmilyen mûszaki vagy nyelvi akadálya. Ugyanez vonatkozik az attribútumokra is. Ha valamilen speciális, XML alapú nyelvet használunk, úgy ennek a leírása egyértelmûen meghatározza, hogy kis- vagy nagybetûket kell használnunk. A második szabály csak megerõsíti azt, amit már eddig is tudtunk, nevezetesen, hogy ha mondjuk van a dokumentumunkban egy címke, akkor valahol kell lennie egy hozzá tartozó -nek is. Egy kivétel persze van ez alól a szabály alól: az üres elem, amelynél használhatjuk a már szintén említett rövidített írásmódot (). A harmadik szabály szerint ezek a nyitó és záró párok nem lapolódhatnak át, vagyis ha egy elemet egy másikba ágyazunk, akkor a befoglaló elemnek teljesen tartalmaznia kell a másikat. Ezen a ponton talán jól jöhet egy példa:
02xml.qxd
5/16/2006
12:47 PM
Page 23
2. óra • XML dokumentumok létrehozása 23
Ugye látható, mi a gond ezzel az írásmóddal? Az a baj, hogy a pet nevû elemet nem tartalmazza teljes egészében a pets nevû, holott láthatólag ez volt a programozó szándéka. A kód szerkesztésébõl, vagyis az üres helyek használatának módjából számunkra ugyan nyilvánvaló a programozó elgondolása, de ez azon a tényen nem változtat, hogy a kód maga helytelen. Ráadásul elõfordulhat az is, hogy még a szerkesztési forma sem teszi nyilvánvalóvá a hibát. Nézzük például a fenti kód egy másik változatát:
Mivel az üres helyek nem befolyásolják az XML kódok jelentését, ez a kód funkcionálisan ekvivalens a fentivel. Az egyetlen eltérés csak az, hogy a hibát – nevezetesen a pet elem „túllógását” – így sokkal nehezebb felfedezni. A túllógási effektussal egyébként az a gond, hogy a szerkezet többféleképpen is értelmezhetõ, az XML-nek pedig éppen az a célja, hogy az ilyen eseteket teljesen kizárja. A szerkezeti zavar feloldásához vagy a záró címkét kell elmozdítanunk, vagy a kérdéses pet elemet teljesen a pets elemen kívülre helyeznünk. Visszatérve az XML parancsolataihoz a negyedik egy az elõzõhöz nagyon hasonló egyszerû szabály az attribútumokkal kapcsolatban: minden attribútum értékének idézõjelek között kell megjelennie. A következõ kód tehát helytelen, hiszen a Maximilian nevét tároló attribútumnál lefelejtettük az idézõjeleket:
Amint azt korábban is említettem azoknak, akik dolgoztak már HTML-ben különösen fontos, hogy észben tartsák ezt a szabályt, mivel a HTML ezen a téren is sokkal liberálisabb. Ami azt illeti a weblapok fejlesztõi nem alakítottak ki ezzel kapcsolatban semmiféle szokásjogot, bár az általános tendencia az, hogy nem szeretik használni az idézõjeleket. Az XML-nél ez a dolog nem ízlés kérdése, az idézõjelek használata kötelezõ és pont. Az utolsó parancsolat egy olyasféle kikötést tartalmaz, amire még nem vagyunk felkészülve, mert ezidáig nem esett szó a gyökérelem (root element) fogalmáról. A gyökérelem az XML dokumentumnak az az egyetlen eleme, amely minden más elemet magában foglal. Minden dokumentumnak kell legyen gyökéreleme, és ebbõl az elembõl a szabvány szerint csak egy lehet. A kisállatokat leíró példáinkban ebben és az elõzõ óra anyagában a gyökérelem mindig a pets nevû elem volt. Ez volt az, ami mindig ma-
2
02xml.qxd
5/16/2006
12:47 PM
Page 24
24 I. rész • Alapok
gában foglalta az összes pet és friend típusú elemet. Ha visszagondolunk a HTML nyelvre, ott is mindig van gyökérelem, mégpedig a html nevû. E tekintetben tehát a HTML eleve megfelel az XML szabványainak. Ugyanakkor a HTML szintaxisa lehetõvé teszi egynél több gyökérelem alkalmazását, míg az XML-ben erre soha nincs lehetõség. Mivel a gyökérelemnek tartalmaznia kell minden más elemet, nyilván triviális, hogy ez soha nem lehet üres elem. Ez egyben azt is jelenti, hogy a gyökérelemnek mindig meg kell legyen a nyitó és a záró címkéje is. Az üres elemekkel kapcsolatban korábban többször említett rövidítés itt garantáltan nem használható.
Az XML speciális szimbólumai Van néhány olyan speciális jel, amelyeket különleges módon kell megadnunk, ha azok a szöveges tartalom részeként bukkannak fel valahol. Ennek egyszerûen az az oka, hogy ezek a jelek az XML szintaxis részét képezik, vagyis arra használjuk õket, hogy segítségükkel a címkéket vagy az attribútumokat leírjuk. Speciálisnak számít tehát a kisebb (<) és a nagyobb (>) jel, az idézõjel ("), az aposztróf ('), valamint az & (ampersand). Az XML nyelven belül ezeknek a karaktereknek speciális jelentésük van, így jeleznünk kell, ha nem ebben az értelemben kívánjuk õket használni. Ennek megfelelõen a következõ példa helytelen, hiszen a nevet tartalmazó attribútum értéke maga is tartalmazza az aposztróf jelet, mégpedig annak literális (betû szerinti) értelmében. <movie name="All the King’s Men" />
Persze a speciális jeleket is használhatjuk a tartalom részeként, de speciális módon, úgynevezett egyedként (entity) kell õket megadnunk. Az egyed olyan szimbólum, amely valamilyen erõforrást, például egy karaktert vagy akár egy fájlt azonosít. Az XML-ben az egyedek neve mindig egy & jellel kezdõdik, és egy pontosvesszõvel (;) végzõdik. Az egyed neve e kettõ között szerepel. A következõkben felsoroljuk a speciális karaktereknek megfelelõ elõre definiált egyedeket: • • • • •
Kisebb jel (<) – < Nagyobb jel (>) – > Idézõjel (") – " Aposztróf (') – ' És jel (& , ampersand) – &
Ennek megfelelõen az elõzõ helytelen példa javított változata a következõképpen fest: <movie name="All the King's Men" />
Íme egy másik példa, csak hogy tisztázzuk, miként használható a többi egyed: <movie name="Pride & Prejudice" />
02xml.qxd
5/16/2006
12:47 PM
Page 25
2. óra • XML dokumentumok létrehozása 25
Ebben a példában az & egyedet (entity) kellett használnunk, ha helyesen akartuk leírni a film címét („Pride & Prejudice”). Készséggel elismerem, hogy a speciális karaktereknek ez az írásmódja nem teszi éppen könnyûvé a szöveg olvasását, ugyanakkor nagy elõnye a módszernek, hogy hasonlóan az XML minden más eleméhez ez is teljesen egyértelmûvé teszi a fejlesztõ szándékát. Szerencsére mindössze öt olyan speciális karakter van, amire emlékeznünk kell, így ez az egész talán nem is akkora probléma.
Az XML deklaráció Az utolsó lényeges dolog, amit tisztáznunk kell az XML deklaráció, amit ugyan nem kötelezõ megadni a dokumentumok elején, de kifejezetten hasznos lehet. Az XML deklaráció egyetlen sornyi kód a dokumentum elején, amely azt határozza meg, hogy a kérdéses dokumentum az XML mely szabványa alapján készült. Az XML-nek pillanatnyilag két szabványa létezik, az XML 1.0 és az 1.1. Ezek elsõsorban abban térnek el egymástól, hogy miként támogatják a különleges karaktereket az elemek és attribútumok nevében. Az XML 1.1, amely e tekintetben viszonylag tágabb teret ad a programozónak elsõsorban a nagygépes felhasználóknak és fejlesztõknek készült. Talán éppen ezzel magyarázható, hogy támogatottsága egyelõre nem különösebben széleskörû. Ami azt illeti, az elõre látható jövõben a legtöbbünknek elegendõ lesz az 1.0-ás szabvánnyal törõdni. Az XML közösség berkein belül egyesek sugdosnak valamit egy XML 2.0 szabványról is, de ezt hivatalos forrásból még soha senki nem erõsítette meg.
Visszatérve az XML deklarációhoz ez a bizonyos kezdõ sor azt mondja meg az XML alkalmazásnak vagy webböngészõnek, hogy a kérdéses dokumentum az XML melyik szabvány alapján készült. XML 1.0 esetén a deklaráció a következõképpen fest.
Elsõ látásra ez a kódrészlet meglehetõsen hasonlít egy elem megadására, ám jobban megnézve nem errõl van szó, hiszen itt nem egy címkével nyílik a leírás. Amit látunk az egy úgynevezett feldolgozási utasítás (processing instruction) amely nevének megfelelõen az XML dokumentumot használó alkalmazás számára közvetít feldolgozási utasításokat. Ebben a konkrét esetben azt közöljük az alkalmazással, hogy dokumentumunk az XML 1.0 szabvány elõírásainak megfelelõen készült, tehát ekként kell azt értelmezni. A feldolgozási utasításokat minden esetben a jelek határolják. Az XML 1.1 szabvány szerint minden XML dokumentumnak tartalmaznia kell az XML deklarációt.
2
02xml.qxd
5/16/2006
12:47 PM
Page 26
26 I. rész • Alapok
A megfelelõ XML szerkesztõ kiválasztása Az XML dokumentumok létrehozásához és szerkesztéséhez szükségünk van valamilen szerkesztõprogramra. Mivel ezek a dokumentumok alapvetõen közönséges szövegfájlok, természetesen akár egy egyszerû szövegszerkesztõ is megteszi. Aki például Windows operációs rendszer alatt dolgozik, nyugodtan használhatja a Notepad vagy a Wordpad nevû alkalmazásokat. Macintosh gépen ugyanezt a célt szolgálhatja a TextEdit alkalmazás. Ugyanakkor ha olyan az XML-re specifikus szolgáltatásokat is szeretnénk használni, mint az elemek vagy attribútumok szintaktika szerinti színezése, akkor egy igazi XML szerkesztõre lesz szükségünk. Mielõtt azonban bemutatnék néhány népszerû alkalmazást, egy kicsit még visszatérek magához az XML nyelvhez, hogy bemutathassam, milyen elveket használnak illetve valósítanak meg ezeknek az alkalmazásoknak a fejlesztõi. Az XML szerkesztõknek alapvetõen három típusa létezik. Vannak WYSIWYG, WYSIWYM és közönséges szövegszerkesztõk. Akinek van némi tapasztalata webfejlesztéssel vagy nyomdai elõkészítéssel kapcsolatban, annak a WYSIWYG (What You See Is What You Get) kifejezés ismerõsen cseng. Az ilyen elven mûködõ alkalmazások alapelve egyszerû: a dokumentumot pontosan olyan formában szerkeszthetjük, amilyen formában az meg fog jelenni a felhasználó képernyõjén, vagy a papíron. Jó példa erre a megközelítésre a Microsoft Word vagy a Macromedia Dreamweaver. Az egyikkel nyomtatni kívánt dokumentumokat, a másikkal weblapokat szerkeszthetünk „élethû” formában. A WYSIWYG XML szerkesztõk ugyanezt a megközelítést követik, vagyis nem annyira az adattartalomra, hanem annak végsõ megjelenésére koncentrálnak. Ez nyilván nem igazán igazodik az XML szellemiségéhez, így akadhatnak olyanok, akiket a logikai struktúra jobban érdekel fejlesztés közben. Nekik készülnek a WYSIWYM (What you See Is What You Mean) szerkesztõk, amelyek a dokumentum jelentését tartják szem elõtt, a megjelenítést pedig a dokumentumot használó alkalmazásra bízzák. Az ilyen szerkesztõprogramok gyakran eleve ismernek többféle XML alapú jelölõnyelvet, ami azért hasznos, mert így képesek helyfüggõ segítséget nyújtani szerkesztés közben. Ezek a programok a megfelelõ ponton csak az adott nyelv által megengedett címkéket vagy attribútumokat ajánlják fel. Magát a kész kódot a legtöbb WYSIWYM szerkesztõ olyan faszerkezetként jeleníti meg, mint a webböngészõk (lásd az elõzõ fejezet 1.1. és 1.2. ábráját). A WYSIYM XML szerkesztõket gyakran hívják szemantikai szerkesztõknek is, mivel az XML kód szemantikájára (jelentésére) koncentrálnak, nem annak megjelenésére.
Az XML szerkesztõk harmadik típusába az olyan közönséges szövegszerkesztõk tartoznak, amelyek azért nyújtanak némi XML-re specifikus támogatást is. Az ezek által alkalmazott megközelítés tehát se nem WYSIWYG, se nem WYSIWYM, mivel itt munka közben sem a dokumentum megjelenése, sem annak jelentésen nem derül ki. Itt a fej-
02xml.qxd
5/16/2006
12:47 PM
Page 27
2. óra • XML dokumentumok létrehozása 27
lesztõ teljesen magára van utalva, ami nem föltétlen rossz dolog, hiszen a spártai egyszerûség különösen egy kezdõt arra késztethet, hogy az XML-nek minden apró részletére odafigyeljen. A piacon természetesen számos szoftver van jelen mindhárom kategóriából, és ezek ára is teljesen változó. Bár egy ilyen speciális alkalmazás beszerzése egy ponton mindenképpen célszerû lesz azok számára, akik komolyan foglalkoznak az XML-lel, én mégis azt javaslom, hogy egyszerû pedagógiai megfontolásból töltsünk el némi idõt egy közönséges szövegszerkesztõ társaságában. Ez lehetõséget teremt arra, hogy azon a szinten dolgozzunk, hibázzunk és tanuljunk, ahol maga az XML létezik és mûködik. Ebbõl lehet a legtöbbet tanulni. A 2.1. ábrán azt láthatjuk, miként fest a korábban emlegetett „talltales” dokumentumunk, ha az XML-rõl mit sem sejtõ Windows Notepad segítségével nyitjuk meg.
2.1. ábra XML dokumentumokat az olyan közönséges szövegszerkesztõkkel is lehet készíteni, mint amilyen a Windows Notepad
Ha a Windows Wordpad-et, vagy bármilyen egyéb szövegszerkesztõt használunk, amely többféle formátumban is képes menteni a dokumentumokat, az XML dokumentumok mentéséhez akkor is a „közönséges szöveg” (plain text) formátumot használjuk. Ez azt jelenti, hogy a munka befejeztével a Mentés másként menüpontot kell használnunk, és ott fájltípusként a „Text Only (.txt)” formátumot választanunk. Ami a WYSIWYG szerkesztõket illeti, a legjobb, amit valaha láttam a Vex, ami ráadásul szabad szoftver, és a vex.sourceforge.net címrõl tölthetjük le. A Vex egy a Microsoft Wordhöz hasonló grafikus felhasználói felületet jelenít meg. Ami azonban még ennél is
2
02xml.qxd
5/16/2006
12:47 PM
Page 28
28 I. rész • Alapok
fontosabb, ez a program elrejti az XML címkéket, vagyis valóban a WYSIWYG elvnek megfelelõen mûködik. Így a fejlesztõ kizárólag a kód megjelenésére koncentrálhat. A Vex CSS-t használ az XML tartalom megjelenítéséhez. Hogy miként lehet stíluslapokat XML dokumentumokra alkalmazni, arról a 10. órában lesz részletesen szó. Sajnos a Vex segítségével meglehetõsen nehézkes a nagyobb projektek kezelése, így azt javaslom, hogy ilyen esetben használjunk inkább egy WYSIWYM vagy egy közönséges szövegszerkesztõt, amíg kellõ gyakorlatot nem szerzünk. Ne felejtsük el azt sem, hogy egy közönséges szövegszerkesztõvel létrehozott XML dokumentum megjelenítéséhez bármikor használhatunk egy webböngészõt, vagyis a WYSIWYG szolgáltatás nem is olyan igazán fontos. A legtöbb XML dokumentumban a lényeg ráadásul nem is a megjelenés, hanem a logikai felépítés. Ilyen esetekben sokkal hasznosabb lehet egy WYSIWYM szerkesztõ. Ebbõl a típusból a kedvencem a Butterfly XML, ami szintén szabadon használható, és a http://www.butterflyxml.org címrõl tölthetjük el. A Vex-szel ellentétben a Butterfly XML a dokumentumok logikai szerkezetére és nem azok megjelenésére koncentrál. Ennek megfelelõen a dokumentumot hierarchikus faszerkezetként és közönséges szövegként egyaránt képes megjeleníteni. Másként fogalmazva ezzel a szerkesztõvel dolgozva egyszerre láthatjuk a dokumentum logikai vázát, és azt, hogy a váz egyes pontjaihoz milyen tartalom tartozik. Ugyanakkor a program megkímél bennünket attól, hogy közönséges szövegként kelljen ezt a szerkezetet létrehoznunk. A szöveg beviteléhez számos segédeszközt kapunk. A Butterfly például helyi menük formájában képes megjeleníteni azoknak a címkéknek a listáját, amelyek az adott ponton szóba jöhetnek. Nekünk csak választanunk kell. A 2.2. ábrán láthatjuk, miként segít bennünket a Butterfly XML abban, hogy a dokumentumot annak jelentése és logikai szerkezete alapján szerkesszük.
2.2 ábra A Butterfly XML egy WYSIWYM XML szerkesztõ, vagyis lehetõvé teszi, hogy fejlesztés közben a dokumentum jelentésére és logikai szerkezetére koncentráljunk.
02xml.qxd
5/16/2006
12:47 PM
Page 29
2. óra • XML dokumentumok létrehozása 29
Nos ami azt illeti, itt egy kicsit elõreszaladtam, hiszen a képen az a talltales.xml dokumentum látszik, amit csak késõbb fogunk létrehozni. Ez lesz életünk elsõ XML dokumentuma, és ígérem, nem kell már sokat várni rá. Még ebben az órában sorra kerül. Nehogy valaki úgy gondolja, hogy én amolyan spórolós pasas vagyok, mert kizárólag ingyenes alkalmazásokat mutatok be, elárulom, hogy rengeteg kereskedelmi XML szerkesztõ is létezik. Ha tehát valaki ezt az utat szeretné választani, nos ennek semmi akadálya. A legtöbb kereskedelmi alkalmazás általában a WYSIWYG és WYSIWYM megközelítést is támogatja, ami természetesen nagy elõny, hiszen a sokoldalúság egyben flexibilitást is jelent. Ezek közül az alkalmazások közül az egyik legjobb, amivel valaha találkoztam az XML Editor, mely Windows, Macintosh és Linux operációs rendszerek alatt egyaránt futtatható, sõt létezik Eclipse modulként is. Az ugyan pénzbe kerül, de aki komolyan foglalkozik XML-lel, annak pillanatok alatt behozza az árát. Aki többet akar tudni errõl a programról, látogasson el a http://www.oxygenxml.com címre. Egy másik kifejezetten ígéretes alkalmazás az XML Spy, amely viszont csak Windows alatt futtatható. Ez tulajdonképpen egy viszonylag régóta létezõ szerkesztõ, és ennek megfelelõen számos XML technológiát támogat. Mindazonáltal nekünk kezdõknek most a leglényegesebb tulajdonsága talán az lehet, hogy létezik egy ingyenesen használható Home kiadása is. Van persze Enterprise Edition és Professional Edition is belõle, amelyek pénzbe kerülnek, ugyanakkor a beléjük fektetett összeg szintén hamar megtérül azoknak, akik komoly munkához használnak XML-t. Az XML Spy Home Edition a http://www.altova.com/download_spy_home.html címrõl tölthetõ le.
Elsõ XML dokumentum unk Immár birtokában vagyunk annak az alapvetõ tudásnak, amelyre építve létrehozhatjuk elsõ XML dokumentumunkat. A legtöbb olvasónak ezen a ponton valószínûleg már számos önálló ötlete is van arra, hogyan használhatná a megszerzett ismereteket saját adatainak megformázására. Ami azt illeti, csak bátorítani tudok mindenkit az efféle önállóságra. Ugyanakkor itt és most maradjunk az én adataimnál, és használjuk ezeket az elsõ példa létrehozása során. Amikor épp nem írok könyvet, egy Stalefish Labs-nek nevezett, hagyományos táblás játékokat készítõ cégnek dolgozom. Néhány éve Talltales néven elkészítettük egy papír alapú kérdezz–felelek játékot (http://www.talltalesgame.com) és jelenleg a szoftveres változaton dolgozunk. A kérdéseket és a helyes válaszokat tartalmazó adatbázist – mi sem természetesebb – XML-ben valósítjuk meg. Az elképzelés szerint ezt a játékot közönséges webböngészõvel, sõt mobil eszközökkel is lehet majd játszani. Az XML-ben történõ megvalósítás legfõbb haszna a mi szempontunkból az, hogy az adatbázis egyrészt garantáltan konzisztens marad, másrészt egészen egyszerû lesz a frissítések kibocsátása.
2
02xml.qxd
5/16/2006
12:47 PM
Page 30
30 I. rész • Alapok
Számunkra most ebbõl az egészbõl csak annyi a lényeg, hogy a kérdések és feleletek tárolása kiváló példa lesz XML tanulmányaink folytatásához. A Tall Tales játék többféle kérdéstípust tartalmaz. Közülük az egyik olyan, hogy a kérdéshez három lehetséges válasz tartozik, és ezek közül kell a játékosnak megjelölnie a szerinte helyeset. Természetesen az adatszerkezetnek csak úgy lesz értelme, ha tartalmazza valahol a helyes válasz kódját is. Eddigi tudásuk alapján a legcélszerûbbnek az mutatkozik, ha ezt a kérdést és a válaszokat tartalmazó fõelem egyik attribútumaként tároljuk. Ne felejtsük el azt sem, hogy – amint azt nem is olyan régen megtanultuk – valamennyi XML dokumentumnak kell legyen egy és csakis egy gyökéreleme. Esetünkben ez a talltales nevû elem lesz, már csak a játék neve miatt is. A talltales elem tehát számos kérdést fog tartalmazni, amelyek mindegyikéhez három lehetséges válasz tartozik majd. A kérdéseket tartalmazó elemet question-nek fogjuk nevezni, a válaszok pedig rendre az a, b, és c nevet kapják. Természetese fontos, hogy a válaszok a megfelelõ kérdéssel legyenek „összecsomagolva”, vagyis valamennyien egy tárolási egységbe tartozzanak. Ezt a befoglaló elemet tt-nek fogjuk nevezni, megint csak a talltale szó után. Már csak a helyes válasz tárolásáról kell gondoskodnunk, ami a tt elem egyik attribútuma lesz. Legyen ennek az attribútumnak a neve answer. Azoknak, akiknek ez a leírás kicsit gyors volt és tömör, összefoglalom a használni tervezett elemeket, és azok rendeltetését: • • • • • •
talltales – A dokumentum gyökéreleme tt – Egy konkrét kérdés, és a hozzá tartozó három válasz question – Egy kérdés a – Az elsõ lehetséges válasz b – A második lehetséges válasz c – A harmadik lehetséges válasz
Ezen kívül a tt nevû elemnek lesz egy answer nevû attribútuma, amelyben a helyes válasz betûjelét (a, b vagy c) fogjuk tárolni. Azt se felejtsük el, hogy a dokumentumnak egy megfelelõ XML deklarációval kell kezdõdnie. Mindezeket szem elõtt tartva egy teljes tt elem a következõképpen fog kinézni: 1994-ben az Ohio államban található Akronban egy bûnözõt különös baleset ért, miközben egy pizzériát akart kirabolni. Mi történt vele? Elcsúszott egy a padlón levõ zsírfolton, és az ütéstõl elájult.Kifelé menet beletolatott egy rendõrautóba.Majdnem megfulladt egy kenyérdarabtól, amit menekülés közben félrenyelt.
02xml.qxd
5/16/2006
12:47 PM
Page 31
2. óra • XML dokumentumok létrehozása 31
A fenti kódból világosan látszik, miként képeztünk egyetlen logikai csoportot a kérdésbõl és a hozzá tartozó három lehetséges válaszból. Az answer nevû attribútum tartalmából az is látszik, hogy a helyes válasz jelen esetben az (a). Példánkban nem fordul elõ üres elem, hiszen minden egység vagy szöveget tartalmaz, vagy más elemeket. Figyeljük meg azt is, miként vannak egymásba ágyazva az egyes elemek. Most, hogy láttuk a teljes adatbázis egyetlen elemét, vessünk egy pillantást a 2.2. listára, amely egy három kérdésbõl álló teljes adatbázist tartalmaz.
2.2. lista
Egy a Tall Tales játékhoz tartozó XML dokumentum
1: 2: 3: 4: 5: 6: 1994-ben az Ohio államban található Akronban egy bûnözõt különös baleset ért, miközben egy pizzériát akart kirabolni. 7: Mi történt vele? 8: 9: Elcsúszott egy a padlón levõ zsírfolton, és az ütéstõl elájult. 10: Kifelé menet beletolatott egy rendõrautóba. 11: Majdnem megfulladt egy kenyérdarabtól, amit menekülés közben félrenyelt. 12: 13: 14: 15: 16: 1993-ban az Indiana államban található Martinswille-ben egy embert letartóztattak betörés vádjával, miután a lakók 17: felfedezték, és feljelentették a rendõrségen. 18: Hogyan jöttek rá a lakók a betörésre? 19: 20: Mielõtt bement volna valahova, illedelmesen becsöngetett. 21: Emberünk üvegekkel és edényekkel csörömpölve nekiállt a konyhában, hogy egy kenyeret kenjen magának. 22: Az illetõ az egyik házban leült a zongorához, és játszani kezdett. 23: 24: 25: 26: 27: 1994-ben az angliai Yorkban található Nestle UK élelmiszeripari céget az egyik 36 éves dolgozója beperelte, 28: mert üzemi balesetet szenvedett. 29: Mi történt az illetõvel? 30: 31: Beleesett az egyik nagy méretû keverõbe, és vagy egy percig kavargott a masszában.
2
02xml.qxd
5/16/2006
12:47 PM
Page 32
32 I. rész • Alapok 32:
Gyomorfekélye keletkezett a sok nyalókától, ugyanis hivatásos kóstolóként dolgozott a cégnek. 33: Fejbevágta egy nagy méretû csokoládé, ami valahonnan elrepült. 34: 35:
Bár elsõ ránézésre ez egy meglehetõsen hosszú kódnak tûnik, a jelentõs részét valójában a kérdések és a válaszok teszik ki. Az elõzõ magyarázat alapján a címkék jelentése és használatának módja már nyilván világos. Ezzel tehát el is készültünk elsõ XML dokumentumunkkal. Mielõtt továbblépnénk, vessünk egy pillantást a 2.2. ábrára, amelyen az látszik, miként fest dokumentumunk a WYSIWYM tulajdonságokkal rendelkezõ Butterfly XML szerkesztõben.
XML dokumentumok megjelenítése Ha nekiálltunk egy projekt megvalósításának, és látni szeretnénk, hogyan fest az az XML dokumentum, amin eddig dolgoztunk, annak legjobb módja, ha egy megfelelõen kialakított stíluslapot rendelünk hozzá. A stíluslapok olyan formázási leírások, amelyek azt határozzák meg, hogy az XML dokumentum egyes elemei hogyan jelenjenek meg egy webböngészõben. A módszer természetesen nem új, hiszen a stíluslapokat eredetileg HTML oldalak formázására találták ki. Ugyanakkor a módszer egy az egyben átvihetõ XML dokumentumokra is. Ez utóbbi esetben a formázás explicit megadása különösen fontos, hiszen a böngészõprogramoknak fogalmuk sincs, mit kellene kezdeniük az általunk bevezetett egyedi címkékkel. A stíluslapokról és az XML dokumentumok formázásáról a könyv harmadik részében részletesen esik majd szó. Ugyanakkor itt és most mégis szeretnék bemutatni egy olyan stíluslapot, amivel az imént létrehozott Tall Tales dokumentumot lehet szépen formázva megjeleníteni egy böngészõben. Ne felejtsük el, hogy a stíluslapok célja alapvetõen az adatok megjelenésének a szabályozása, azok jelentésére azonban nincs hatásuk. Segítségükkel megadhatjuk a betûtípusokat, a színeket, a szövegrészek, bekezdések és képek elhelyezkedését. A stíluselemeket mindig az egyes elemtípusokra lehet alkalmazni, vagyis esetünkben minden egyes elemhez (tt, question, a, b, c) meg kell adnunk a megjelenítés módját. A 16. órában azt is be fogom mutatni, hogy szkriptek segítségével miként rendelhetünk interaktivitást a Tall Tales játék tartalmi elemeihez, most azonban csak a szép megjelenés a cél. Az alapelképzelés az, hogy a lehetséges válaszoknak a kérdés után, valamivel kisebb betûkkel és más színnel kell megjelenniük. A formázáshoz használt talltales.css stíluslap tartalma a 2.3. listában olvasható.
Ha ez így elsõre túlságosan bonyolultnak tûnik, semmi gond. Egyelõre csak azt figyeljük meg, hogy a stíluslap kódjában minden egyes XML elem neve feltûnik. Még ha valaki nem is látott soha életében CSS stíluslapot, a paraméterek tanulmányozásával akkor is számos dolgot megérthet a fenti kódból, hiszen a nevek meglehetõsen beszédesek. A 12. sorban például a color: black kitétel nyilvánvalóan azt jelenti, hogy a question nevû elem tartalmának feketével kell megjelennie. Ha egy közönséges szövegszerkesztõvel létrehozzuk ezt a stíluslapot, és hozzácsatoljuk a talltales.xml dokumentumhoz, akkor azt a Mozilla Firefox böngészõ a már nem 2.3. hanem a 2.4. ábrán látható módon fogja megjeleníteni. Amíg a stíluslapot nem csatoljuk a megfelelõ XML dokumentumhoz, addig a böngészõ mit sem tud arról, hogy az egyes elemeket hogyan kellene formáznia (2.3. ábra). A tartalom közönséges XML kódként jelenik meg, a megadott formázásoknak pedig nyoma sincs sehol. A stíluslap és a dokumentum összerendeléséhez az XML deklarációt ki kell egészítenünk a következõ módon:
2
02xml.qxd
5/16/2006
12:47 PM
Page 34
34 I. rész • Alapok
2.3. ábra A talltales.xml fájl tartalma egyelõre közönséges XML kódként jelenik meg, mivel a stíluslapot még nem csatoltuk hozzá.
A talltales.xml dokumentum eleje tehát immár így fog festeni: ...
A figyelmes szemlélõ felfedezheti, hogy a dokumentumban egy a feldolgozónak szóló új utasítássor jelent meg, melynek tartalma a már ismert jelek közé van zárva. Ez a sor utasítja az XML alkalmazást, esetünkben a webböngészõt arra, hogy a megjelenítés során a talltales.css fájlban található információkra támaszkodjon. Ennek a kiegészítõ információnak a megadása után dokumentumunk már a 2.4. ábrán látható módon fest, ha megnyitjuk a Mozilla Firefox böngészõ segítségével.
02xml.qxd
5/16/2006
12:47 PM
Page 35
2. óra • XML dokumentumok létrehozása 35
2
2.4. ábra Egy egyszerû stíluslap hozzárendelésével XML dokumentumunk tartalma sokkal áttekinthetõbben jelenik meg egy webböngészõben.
Nos, ez már sokkal jobban fest. Amint látható, már egy egyszerû stíluslap is csodát tesz XML dokumentumunk megjelenésével. Elégedetten hátradõlhetünk: létrehoztuk elsõ XML dokumentumunkat, a hozzá tartozó stíluslappal egyetemben. Ha az olvasó netán úgy érzi, hogy a stíluslapok létrehozásának kérdését enyhén szólva elnagyoltam ebben a fejezetben, akkor készségesen egyetértek. Azért tettem így, mert itt és most arra törekedtem, hogy gyors áttekintést adjak az XML dokumentumokkal kapcsolatos munkáról. Ami pedig a stíluslapok használatát illeti, arról bõven lesz szó a könyv harmadik részében, tehát nincs veszve semmi.
Összefoglalás Amint az a második óra anyagából kiderült, az XML alapvetõ szabályai nem különösebben bonyolultak. Bár az XML sokkal merevebb, mint a HTML, ha elsajátítottuk a nyelv alapvetõ szerkesztési szabályait, villámgyorsan létrehozhatjuk elsõ dokumentumunkat. Ami azt illeti, az XML erejét éppen a konzisztenciája adja. Ez teszi képessé arra, hogy segítségével gyakorlatilag bármilyen adatokat kezeljünk. Mivel maga az XML sem bonyolult, a használatához szükséges eszközök is egészen egyszerûek lehetnek. Elsõ közelítésben semmi egyébre nincs szükségünk, csak egy olyan közönséges szö-
02xml.qxd
5/16/2006
12:47 PM
Page 36
36 I. rész • Alapok
vegszerkesztõre mint például a Windows Notepad nevû alkalmazása. Természetesen léteznek specializált alkalmazások is, amelyeknek elsõsorban azok vehetik hasznát, akik komolyabb, nagyobb méretû feladatokba vágnak bele az XML segítségével. Az óra elején megtanultuk az XML alapelveit, majd megnéztük, hogyan hozhatunk létre mi magunk ilyen dokumentumokat, illetve milyen segédeszközöket használhatunk ehhez. A bevezetõ után létrehoztunk egy nem túl bonyolult de a maga módján teljes XML dokumentumot, majd azt is megnéztük, hogyan csatolhatunk ehhez egy megfelelõen kialakított stíluslapot, amely a tartalom webböngészõben való megjelenítését teszi kissé barátságosabbá.
Kérdések és válaszok Kérdés: Honnan tudhatom meg, mi az XML legfrissebb változata? Válasz: Az XML jelenleg legfrissebb változata az 1.1-es, bár ezt egyelõre meglehetõsen kevés alkalmazás támogatja. A legfrissebb ajánlásokat amúgy a World Wode Web Consortion (W3C) hivatalos webhelyén, a http://www.w3c.org/ címen találhatjuk meg. Ugyanakkor fontos megjegyezni, hogy az XML pillanatnyilag meglehetõsen stabil technológiának számít, így vele kapcsolatban nem várhatóak olyan gyors és drasztikus változások, mint más technológiák, például a Java vagy a HTML esetében. Gyakorlati szempontból az XML aktuális változatának továbbra is tekinthetjük az 1.0-ás szabványt. Kérdés: Mi történik, ha egy XML dokumentumban megsértjük a nyelvvel kapcsolatos ajánlások valamelyikét? Válasz: Nos, a számítógépünk azonnal le fog fagyni, majd közvetlenül ez után az egész egy tûzgolyóvá változik és fölrobban. Viccet félretéve egészen addig az égvilágon semmi nem fog történni, amíg meg nem próbáljuk a kérdéses dokumentumot földolgozni valamilyen XML alkalmazással. Ekkor sem lesz azonban semmiféle katasztrofális következménye a tévedésnek, egyszerûen csak kapunk egy hibaüzenetet. Az XML alapú alkalmazások általában megvizsgálják, hogy a feldolgozni kívánt dokumentum megfelel-e bizonyos alapvetõ kódolási szabályoknak, és ha nem, akkor ezt egy megfelelõ hibaüzenetben közlik a felhasználóval. Szerencsére a webböngészõk többsége is egész ügyesen kiszûri az XML dokumentumok hibáit, ami már csak azért is érdekes, mert a HTML dokumentumokat köztudottan mindegyik kicsit máshogy kezeli. Kérdés: Van a bemutatotton kívül más módja is annak, hogy egy XML dokumentum tartalmát megformázzuk? Válasz: Igen. Ebben az órában a Tall Tales példa kapcsán a CSS (Cascading Style Sheets) technológiát használtuk, amit elsõsorban HTML és XML dokumentumok formázására fejlesztettek ki. Létezik ugyanakkor egy XSL (eXtensible Style Language) nevû
02xml.qxd
5/16/2006
12:47 PM
Page 37
2. óra • XML dokumentumok létrehozása 37
technológia is, amellyel szûrhetjük, átalakíthatjuk és kezelhetjük az XML dokumentumok tartalmát. A stíluslapokról és errõl a technológiáról is a könyv harmadik részében lesz szó részletesen.
Feladatok A feladatokat úgy alkottuk meg, hogy segítsenek a felmerülõ kérdések megválaszolásában, a tanultak áttekintésében, és azok gyakorlatba való átültetésében.
Kvíz 1. Mit nevezünk üres elemnek? 2. Mi a jelentõsége a gyökérelemnek? 3. Mit nevezünk XML deklarációnak, és a dokumentum mely részén kell ennek szerepelnie? 4. Hogyan valósítana meg egy olyan movie nevû üres elemet, amelynek van egy format nevû attribútuma, és ennek dvd azt értéke?
Válaszok 1. Az üres elem olyan elem, amely semmit sem tartalmaz a nyitó és a záró címke között. Az üres elemeket megadhatjuk címkepárokkal (), de használhatjuk az erre rendszeresített rövidített formát is (). 2. A gyökérelem az az elem, amely a dokumentum összes más elemét tartalmazza. Minden dokumentumnak pontosan egy gyökérelemmel kell rendelkeznie. 3. Az XML deklaráció egy olyan kódsor a dokumentum elején, amely azt adja meg, hogy az adott anyag melyik XML szabvány alapján készült. 4. <movie format="dvd" />
Gyakorlatok 1. Hozzunk létre még egy kérdés elemet a talltales.xml dokumentumban. Adjuk meg a három lehetséges választ, valamint a helyes kódját is. Ezután nézzük meg egy webböngészõ segítségével, hogyan fest az új dokumentum a talltales.css stíluslappal formázva. 2. Módosítsuk úgy a talltales.css stíluslapot, hogy a kérdések és válaszok eltérõ színnel jelenjenek meg. A stíluslapok ugyanolyan szöveges dokumentumok, mint az XML fájlok, így ezeket is szerkeszthetjük egy egyszerû szövegszerkesztõvel.
2
02xml.qxd
5/16/2006
12:47 PM
Page 38
03xml.qxd
5/16/2006
12:48 PM
Page 39
II. RÉSZ Az XML adatok meghatározása 3. óra 4. óra 5. óra 6. óra 7. óra 8. óra
Az adatok meghatározása DTD séma segítségével Ássunk az XML dokumentumok mélyére! Névterek használata Átméretezhetõ vektorgrafika készítése SVG-vel Az XML Schema használata XML dokumentumok érvényességének ellenõrzése
03xml.qxd
5/16/2006
12:48 PM
Page 40
03xml.qxd
5/16/2006
12:48 PM
Page 41
3. ÓRA Az adatok meghatározása DTD séma segítségével A számítógépek nem intelligensek, csak azt gondolják magukról. – Ismeretlen Az XML nyelv megalkotásának egyik oka az emberi hibák lehetõségének kiküszöbölése volt. Mivel az XML szerkezete meglehetõsen merev, az XML fejlesztõknek nem sok lehetõségük van arra, hogy hibázzanak. Akivel megtörtént már, hogy bankszámláján tévesen számoltak el egy terhelést (vagyis a bank a saját javára tévedett) az a saját bõrén (zsebén) érezte, mekkora jelentõsége van a hibák kizárásának egy kritikus küldetést betöltõ számítógépes rendszerben. Az XML használata ennek megfelelõen gyorsan terjed az efféle rendszereket üzemeltetõ vállalatokon belül, de különösen a gazdasági életben és a bankszektorban. Az XML merev szabályrendszere nyilván nagyobb stabilitást kölcsönöz majd ezen szervezetek informatikai rendszereinek. Az XML dokumentumokban esetleg megbújó hibák felfedezésének alapja az úgynevezett séma. Ez egy olyan logikai felépítmény, vagy szerkezeti leírás, amely segítségével az XML fejlesztõk elõre meghatározhatják, miféle adatok, milyen formátumban és milyen struktúrával szerepelhetnek az adott dokumentumban.
03xml.qxd
5/16/2006
12:48 PM
Page 42
42 II. rész • Az XML adatok meghatározása
Ebben az órában tehát a sémákról lesz szó. A könyvben természetesen érinteni fogjuk mindkét ma használatos sémanyelvet, de ebben az órában csak a DTD-rõl lesz szó részletesebben. A másik módszerrõl majd egy késõbbi órában ejtünk szót. Ebben az órában tehát a DTD-k belsõ mûködését fogjuk boncolgatni, és megtanuljuk, hogyan hozhatunk létre mi magunk is egy DTD sémát saját igényeinknek megfelelõen. Ebben az órában a következõket fogjuk megtanulni: • • • • • •
Miként teszi lehetõvé az XML speciális nyelvek meghatározását A sémák szerepe az XML segítségével történõ adatmodellezésben Az XML sémák közti különbségek Mitõl lesz egy dokumentum érvényes, illetve jól formázott (well-formed) Hogyan határozhatunk meg elemeket és attribútumokat egy DTD-ben Hogyan hozhatunk létre és használhatunk egy DTD-t, ha saját jelölõnyelvet akarunk definiálni
Saját jelölõnyelv létrehozása Mielõtt belevágnánk az óra tényleges anyagába, hadd tegyek egy kis kitérõt. Amikor létrehozunk egy XML dokumentumot, annak kódolásához valójában nem magát az XML nyelvet használjuk, hanem azt a saját jelölõnyelvet, amit az XML segítségével definiáltunk. Másként fogalmazva az XML-t ténylegesen olyan jelölõnyelvek létrehozására használjuk, amelyek segítségével aztán XML dokumentumokat alkothatunk. Igazából az „XML dokumentum” kifejezés félrevezetõ, hiszen ezeket a dokumentumokat nem XML nyelven, hanem egy az XML-lel létrehozott nyelven fogalmazzuk meg. Ha mondjuk létrehoznék magamnak egy különbejáratú jelölõnyelvet, teszem azt MML (Michael's Markup Language) néven, akkor az e nyelv segítségével megalkotott dokumentumokat sokkal helyesebb volna MML dokumentumoknak hívni, tekintve hogy a kódolásukhoz az én saját jelölõnyelvemet használtuk. Ugyanakkor kicsit nagyobb ívû általánosítást alkalmazva azt is állíthatjuk, hogy ezek azért mégis csak XML dokumentumok, hiszen egy XML alapú jelölõnyelv segítségével jöttek létre. A fentiek miatt azonban az „MML dokumentum” kifejezés sem tekinthetõ helytelennek. Nomármost ennek a szép eszmefuttatásnak nem az XML terminológiával kapcsolatos szõrszálhasogatás volt a célja, sokkal inkább az, hogy rávilágítsak az XML tényleges céljára. Ez a nyelv arra ad lehetõséget, hogy segítségével saját jelölõnyelveket alkossunk. Az az olvasó, aki a HTML világából érkezett egészen eddig nyilván meg volt róla gyõzõdve, hogy jelölõnyelv csak egy van, éspedig a HTML. Nos az XML világában jelölõnyelvek ezrei léteznek, és mindegyik más és más adattípusra alkalmazható. Egy XML fejlesztõnek alapvetõen két választása van: használhat egy kész jelölõnyelvet, amit valaki más már létrehozott az adott adattípus kezeléséhez, vagy definiálhat magának egy
03xml.qxd
5/16/2006
12:48 PM
Page 43
3. óra • Az adatok meghatározása DTD séma segítségével 43
saját nyelvet. Egy ilyen XML alapú jelölõnyelv lehet teljesen hivatalos. Ilyen például az XHTML, a HTML XML-alapú kiterjesztése. Lehet ugyanakkor teljesen egyedi is, mint a korábban említett Tall Tales játék saját jelölõnyelve. Amikor létrehozunk egy saját jelölõnyelvet, gyakorlatilag azt határozzuk meg, hogy az adott problémával és adattípussal kapcsolatban milyen címkéket és attribútumokat lehet használni. Persze nyelvrõl lévén szó nem csak az elemeket és attribútumokat kell pontosan leírnunk, hanem azok egymáshoz való viszonyát is. Ha például létre akarunk hozni egy olyan XML-alapú nyelvet, amellyel a helyi softball liga eredményeit kívánjuk nyilvántartani, feltehetõleg olyan egyedi címkéket fogunk használni, mint <schedule> (játékterv), (mérkõzés), (csapat), (játékos) és így tovább. Ami pedig az attribútumokat illeti, a player elemhez például a következõket rendelhetjük: name (név), hits (gólok száma), rbis, és így tovább. Ha a példán felbuzdulva valaki azon töri a fejét, hogy valóban létrehoz egy efféle „sportleíró nyelvet”, annak azt hiszem megspórolok némi idõt ha elárulom, hogy a dolog SportsML (Sprts Markup Language) néven már létezik. Ebben a nyelvben az imént említetthez hasonló címkék már léteznek, sõt a lehetõségek tárháza sokkal nagyobb, hiszen a SportsML számos különbözõ sportág leírására ad lehetõséget. Aki többet szeretne megtudni errõl a speciális jelölõnyelvrõl, látogasson el a SportsML hivatalos webhelyére (http://www.sportsml.org). Most nyilván sokakban merült fel a kérdés, miszerint hogyan is hozhatunk létre egy saját jelölõnyelvet? Hogyan határozhatjuk meg a használható elemek és attribútumok körét, illetve hogy ezek miféle viszonyban állhatnak egymással? Bár használhatnánk saját címkéket és attribútumneveket is, abból a ténybõl, hogy ez a nyelv már létezik egyenesen következik, hogy lennie kell valahol egy formális leírásnak is, ami megadja a dokumentumok felépítését és formátumát. Nos, ez a szabályhalmaz valóban létezik, és ezt nevezzük röviden egy jelölõnyelv sémájának. A séma egyrészt megadja, hogy az adott nyelvben milyen címkék és attribútumok léteznek, másrészt meghatározza, hogy ezek miféle viszonyban állnak egymással. A séma tehát olyasmi, mint egy szerzõdés a nyelv megalkotója, és majdani használója között. Bár az imént azt mondtam, hogy a séma olyan, mint egy szerzõdés, a dolognak a joghoz természetesen semmi köze. Az összehasonlítás alapját csak az a tény képezi, hogy a séma – akárcsak egy igazi jogi szerzõdés – mindent nagyon pontosan leír, és semmiféle kétséget nem hagy azzal kapcsolatban, hogy az adott nyelvet miként kell használni.
3
03xml.qxd
5/16/2006
12:48 PM
Page 44
44 II. rész • Az XML adatok meghatározása
Sémák és adatmodellezés XML-lel Azt a folyamatot, amely során létrehozunk egy sémát egy XML dokumentumtípushoz adatmodellezésnek nevezzük. A név onnan ered, hogy a séma létrehozásához fel kell mérnünk, milyen osztályokba sorolhatók az adatok, ezeknek milyen elemek fognak megfelelni, az elemekhez pedig milyen attribútumok tartozhatnak. Ha elkészültünk egy a kérdéses adattípushoz tartozó adatmodellel (sémával), elkezdhetünk létrehozni olyan XML dokumentumokat, amelyek ehhez a struktúrához igazodnak. A sémák igazi jelentõsége abban áll, hogy lehetõvé teszik az XML dokumentumok szerkezeti és logikai ellenõrzését. Ez a gyakorlatban azt jelenti, hogy a séma alapján maga a fejlesztõ, vagy akár egy XML alapú alkalmazás ellenõrizheti, hogy a neki átadott vagy általa fejlesztett dokumentum szerkezetileg valóban megfelel-e a sémában megadott szabályoknak. Ha valahol eltérés van, mind a fejlesztõ, mind az alkalmazás biztos lehet benne, hogy a kérdéses dokumentum valahol hibás. Az XML dokumentum érvényessége, vagyis a sémának való megfeleltethetõsége olyan, mint egy hivatalos pecsét, ami igazolja, hogy a kérdéses adatok szerkezetileg megfelelnek mindazon kritériumoknak, amelyek lehetõvé teszik, hogy az adott alkalmazással kezelhetõek legyenek. Az XML dokumentumok érvényességének ellenõrzésérõl részletesen majd csak a 8. órában esik szó. Hogy megvilágítsuk, milyen jelentõs szerepet töltenek be a sémák az XML világában, nézzünk egy a való életbõl vett analógiát. Tegyük fel, hogy találkoztunk valakivel, akit már évek óta nem láttunk, és az illetõ megadta nekünk az e-mail címét, hogy könnyebben elérhessük. Csakhogy az általa leírt cím a következõképpen fest: lucy*stalefishlabs.com. Mi persze tudjuk, hogy az összes e-mail cím egy felhasználónévvel kezdõdik, amit egy „at szimbólum” (@) követ, majd pedig egy tartománynévnek kell következnie. Mindez azt jelenti, hogy ebben a címben valami biztosan nem stimmel. A név@tartománynév formátum tulajdonképpen nem más, mint egy egyszerû séma. Amikor megvizsgáltuk a barátunktól kapott e-mail címet, valójában ezt a sémát használtuk arra, hogy eldöntsük, érvényes címrõl van-e szó, és arra jutottunk, hogy az bizony hibás. A hiba jelen esetben amúgy egészen nyilvánvaló: a * karaktert @-ra cserélve már érvényes címet kapunk. Nos, ez a példa talán rávilágított, hogyan használhatók a sémák az XML dokumentumok érvényességének ellenõrzésére, az azonban talán még nem teljesen világos, hogy egyáltalán miért kell az érvényességet ellenõrizni. Azt, hogy az XML világában sémákat használunk az magyarázza, hogy a fejlesztõk lehetõvé akarták tenni a dokumentumok belsõ szerkezetének számítógéppel történõ ellenõrzését. Visszatérve az iménti példához mi emberek egész könnyen rá tudtunk jönni arra, hogy hol a hiba azzal a bizonyos elrontott e-mail címmel. Mit tehet azonban ilyen esetben egy levelezõprogram? Itt nyilván a fejlesztõnek kell gondoskodnia a lehetséges hibák ellenõrzésérõl, vagyis írnia kell egy olyan kódrészletet, ami megvizsgálja, hogy a felhasználó által begépelt cím megfelel-e a megadott szabályoknak. Nos, az XML dokumentumok esetében ugyanezt a szerepet
03xml.qxd
5/16/2006
12:48 PM
Page 45
3. óra • Az adatok meghatározása DTD séma segítségével 45
tölti be a séma, hiszen ez alapján döntheti el az alkalmazás, hogy a neki átadott adatok szerkezetileg megfelelnek-e azoknak az elõírásoknak, amelyeket a fejlesztõ feltételezett. Röviden tehát a sémák a dokumentumok szerkezeti ellenõrzésének segédeszközei. Ha létre kell hoznunk egy sémát, alapvetõen a következõ két technológia közül választhatunk: • DTD (Document Type Definition), • XSD (XML Schema) E két eltérõ technológia tulajdonképpen ugyanazt a célt szolgálja, nevezetesen XML alapú jelölõnyelvek adatmodelljét készíthetjük el a segítségükkel. A következõ két szakaszban kicsit részletesebben is bemutatom a két megközelítés közti különbségeket.
A DTD technológia (Document Type Definition) Figyelem, egy új rövidítést készülök bevezetni. A DTD a Document Type Definition (Dokumentumtípus Meghatározás) az XML dokumentumok logikai felépítésének leírására eredetileg alkalmazott megközelítés. Az „eredetileg” kifejezést itt azért használtam, mert a DTD-k használata valójában nem az XML-lel együtt született meg, hanem még az XML elõdjét jelentõ SGML (Standard General Markup Language) fejlesztõi dolgozták ki. A DTD technológia tulajdonképpen úgy került be az XML világába, hogy annak születésekor már számos olyan eszköz létezett, ami képes volt DTD-ket kezelni. Persze azóta sok minden változott, és ma már egy sokkal hatékonyabb módszer is létezik ugyanerre a célra. Mindazonáltal a DTD-ket a mai napig elõszeretettel használják a fejlesztõk, így nem tehetjük meg, hogy nem foglalkozunk ezzel a technológiával. Errõl a fejlettebb, XML Schema nevû technológiáról a következõ szakaszban lesz szó.
A DTD-vel a legnagyobb gond az, hogy egy kicsit misztikus szerkezetû nyelven alapul. Mármost jogosan kérdezheti valaki, hogy ha az XML olyan kiváló módszert ad a dokumentumok belsõ szerkezetének leírására, akkor ugyan minek kell egy másik nyelvet megtanulnunk az XML sémákhoz? Erre a kérdésre sajnos nem tudok semmiféle frappáns választ adni, eltekintve persze attól, hogy történeti okok miatt a DTD technológia túlélte az XML megjelenését, és a mai napig elterjedt a használata. Egyszerûen nincs más választásunk, mint hogy mi is megtanuljuk használni. Azért van jó hír is: a legtöbb XML alapú jelölõnyelv DTD-vel való leírása meglehetõsen egyszerû. Ez alapvetõen annak köszönhetõ, hogy a DTD nyelve nagyon tömör – és persze pont ezért olyan rejtélyes. Ahelyett, hogy folytatnám a DTD-rõl való elmélkedést, azt hiszem jobb lesz, ha mutatok egy konkrét példát (3.1. lista).
A talltales.xml dokumentumnak megfelelõ séma DTD-vel megfogalmazva
Nos, én mondtam elõre, hogy olyan lesz, mint a titkosírás. Ha azonban fölocsúdva az elsõ meglepetésbõl kicsit közelebbrõl kezdjük vizsgálni ezt a kódot, egy idõ után egészen értelmesnek tûnik. Felfedezhetjük például, hogy a leírás az elõzõ órában bemutatott Tall Tales dokumentum szerkezetérõl szól. Látható az is, hogy a DTD-ben felbukkan az ott alkalmazott összes elemtípus, és mindegyik elõtt az ELEMENT kulcsszó szerepel. A tt elem attribútumainak felsorolása szintén felfedezhetõ. Ezeket az ATTLIST kulcsszó (4. sor) elõzi meg. Esetünkben tulajdonképpen csak egy attribútum, az answer nevû szerepel a leírásban, de természetesen lehetne több is. Figyeljük meg azt is, hogy a kérdéses attribútum mellett fel van sorolva a három lehetséges válasz (a, b és c) is (5. sor). Bár ezeken az értelmezhetõ részeken kívül még jócskán akadnak egyelõre érthetetlen részek – például a minden sor elején felbukkanó
Az XML Schema (XSD) technológia Az XML Schema a DTD-ket hivatott leváltani. Bár ugyanazt a célt szolgálja, vagyis sémákat hozhatunk létre segítségével az XML alapú nyelvekhez, ez a technológia sokkal inkább intuitív szintaktikával rendelkezik. Az XML Schema segítségével létrehozott sémák XSD (XML Schema Definition) nyelven készülnek, ezért „XSD-k” összefoglaló néven is szokás õket említeni. Az XML Schema technológiát és az XSD nyelvet, amelyek együtt egy sokkal hatékonyabb és hajlékonyabb módját adják a sémák létrehozásának mint a DTD a W3C (World Wide Web Consortium) dolgozta ki. Az XML Schema alapöt-
03xml.qxd
5/16/2006
12:48 PM
Page 47
3. óra • Az adatok meghatározása DTD séma segítségével 47
lete az, hogy az XML sémák létrehozásához maga az XML nyelv is használható. Ahelyett tehát, hogy meg kellene tanulnunk egy új nyelvet, mint a DTD estén, most a már ismert XML szintaktikát, vagyis azokat az elemeket és attribútumokat használhatjuk, amelyeket az XSD nyelv definiál. Funkcióját tekintve egy XSD rendkívül hasonló egy DTD-hez, hiszen ezzel is az XML dokumentumok egy osztályának a sémáját írhatjuk le. A DTD-khez hasonlóan az XSD-k is az elemeket, és azok tartalmi modelljeit írják le, hogy az XML dokumentumok logikai szerkezete ez alapján ellenõrizhetõ legyen. Ugyanakkor az XSD-k bizonyos pontokon túl is lépnek a DTD technológia képességein. Az XSD-ben például azt is megadhatjuk, hogy egy elem milyen típusú adatokat tartalmazhat, míg a DTD esetében az elemek tartalma csak szöveg lehet. Az XSD segítségével az elemek típusát bizonyos tartalomtípusokra korlátozhatjuk. Megadhatjuk például, hogy egy elem csak egész szám, vagy csak dátum lehet. Az XSD-k legvonzóbb tulajdonsága persze az, hogy az XML szókincsen (vocabulary) alapulnak, hiszen az XSD maga is XML alapú nyelv. Egy XSD séma tehát ugyanúgy XML dokumentum, mint azok, amelyeknek a szerkezetét leírja. Egy XSD létrehozásához semmiféle új megközelítést nem kell alkalmaznunk, semmi mással nem kell tisztában lennünk, csak a már ismert elemek és attribútumok fogalmával. Az XSD nyelv speciális elemeinek és attribútumainak nevét persze meg kell tanulnunk, de ez egyrészt nem túlságosan nehéz, másrészt koncepcionálisan nem új. A már ismert Tall Tales példánál maradva a 3.2. listában azt láthatjuk, miként írató le ennek a dokumentumosztálynak a sémája XSD segítségével.
3.2. lista
A Tall Tales dokumentumosztály sémája XSD nyelven megfogalmazva
48 II. rész • Az XML adatok meghatározása 18: <xsd:enumeration value="a" /> 19: <xsd:enumeration value="b" /> 20: <xsd:enumeration value="c" /> 21: 22: 23: 24: 25: 26: 27: 28:
Amint látható, az XSD-k nem olyan kompaktak, mint a DTD-k, és elsõre talán átlátni is nehezebb õket. Ennek azonban csupán az az oka, hogy ez a technológia hajlékonyabb, többet nyújt, és a szolgáltatások számának növekedésével az összetettség is szükségszerûen nagyobb. Az XSD-k létrehozásáról mindent meg fogunk tanulni a 7. órában. A fenti kód tartalma akkorra teljesen világossá válik. Itt és most elegendõ az XML Schema alapkoncepcióját megértenünk, vagyis azt, hogy ez a technológia lehetõvé teszi magának az XML-nek a használatát az XML sémák létrehozása közben, illetve hogy az XSD-k hatékonyabb, részletesebb leírást tesznek lehetõvé, mint a DTD. Az XSD például lehetõvé teszi annak meghatározását, hogy egy adott elem hányszor fordulhat elõ egy másik elemen belül. Valójában létezik egy harmadik sématechnológia is, amely az XSD-kkel együtt járó összetettséget csökkenti. Ez a RELAX NG, amit sokan még hatékonyabbnak, és ugyanakkor összefogottabbnak, illetve könnyebben használhatónak tartanak, mint az XML Schemát. Ugyanakkor ennek a technológiának a támogatottsága egyelõre egyáltalán nem olyan általános, mint a DTD-é vagy az XSD-é. Persze ez a helyzet idõvel majd változhat. A RELAX NG-rõl, illetve annak az XSD-hez való viszonyáról a 7. órában lesz szó.
A sématechnológiák összehasonlítása Bár egyelõre tulajdonképpen semmiféle gyakorlati ismeretünk nincs sem a DTD-rõl sem az XSD-rõl, azt már értjük, hogy ezek a sémák létrehozásának két alapvetõen különbözõ megközelítését jelentik. Amint arra korábban utaltam, a DTD ugyan nem olyan hatékony technológia, mint az XSD, de azért megvannak a maga elõnyei. Történeti okokból kifolyólag viszonylag széles támogatottságnak örvend, és sokak számára a használata is egyszerûbb. Ugyanakkor az XSD technológiai szempontból mindenképpen magasabb színvonalat képvisel, hiszen jóval nagyobb szabadságot, több lehetõséget ad a fejlesztõnek az XML adatmodell egyes részleteinek meghatározásával kapcsolatban. Ezen a ponton talán hasznos, ha tételesen is összefoglaljuk, milyen eltérések vannak a DTD és XSD technológia között, hiszen ez alapján könnyebb lesz eldönteni, melyikre van inkább szükségünk egy-egy adott probléma kapcsán.
03xml.qxd
5/16/2006
12:48 PM
Page 49
3. óra • Az adatok meghatározása DTD séma segítségével 49
Lássuk tehát a különbségek listáját: • A DTD-ket egy speciális nyelven kell megfogalmazni, míg az XSD-knél tulajdonképpen magát az XML-t használjuk. • Az XSD-ket ugyanúgy kezelhetjük, mint bármely más XML dokumentumot. • Az XSD nyelv számos adattípus használatát teszi lehetõvé (egészek, lebegõpontos számok, logikai értékek (Boolean típusok), dátumok és így tovább), míg a DTD-ben minden vagy karakterlánc, vagy karakterláncok listája. • Az XSD egy nyílt végû adatmodellt szolgáltat, amely lehetõvé teszi egyedi jelölõnyelvek kidolgozását, illetve az elemek közti összetett kapcsolattípusok kiépítését anélkül, hogy ezzel a dokumentumok érvényüket vesztenék. A DTD-k ezzel szemben zárt adatmodellt alkalmaznak, így a kiegészítésre nem sok esélyt nyújtanak. Az eltéréseknek e listája alapján az ember azonnal az XSD javára döntene. Ugyanakkor természetesen nem arról van szó, hogy én, a szerzõ egyszerûen beleszerettem az XML Schemába. Ne felejtsük el, hogy ez a technológia jóval a DTD után jött létre, így a fejlesztõi tanulhattak az elõdök hibáiból. És bár felsorolásunk alapján sokan úgy gondolhatják, hogy az XSD helyett a DTD-t választani egyszerûen esztelenség, azért a DTD technológia még egyáltalán nem tekinthetõ kihaltnak. Ennek pedig elsõsorban az az oka, hogy a DTD régóta létezõ, illetve széles körben elterjedt és támogatott technológia. Ha valaki esetleg úgy gondolná, hogy egy elavul technológia nem lehet képes túlélni önmagát pusztán a széles körû elfogadottságának köszönhetõen, nos annak csak azt tudom javasolni, hogy gondolkodjon el a közelmúlt technikai fejlesztésein. Nem kell messzebbre tekintenünk, csak a videólejátszónkig. Annak idején mindenki pontosan tudta, hogy a Betamax technológiailag jobb, mint a VHS szabvány, mégis valahogy az utóbbi kerekedett felül. Persze nem kell, hogy a történelem ismételje önmagát, így egészen valószínû, hogy az XML Schema és a RELAX NG idõvel kiszorítja a DTD-t. A DTD mellet szóló legfõbb érv az, hogy számos XML alapú jelölõnyelv leírása egyelõre csak DTD formájában létezik. Ha tehát valaki azt tervezi, hogy munkájához ezek valamelyikét használja, az kénytelen lesz tisztába jönni a DTD technológiával is. A másik lényeges szempont, hogy az XML jelenlegi alkalmazási területein a DTD tulajdonképpen egész jól megállja a helyét, így az a tény, hogy az XSD technológiai szempontból jobb, egyelõre nem kellõen erõs érv a DTD leváltására.
3
03xml.qxd
5/16/2006
12:48 PM
Page 50
50 II. rész • Az XML adatok meghatározása
Miért fontos ellenõrizni a dokumentumok érvényességét? Mielõtt belemerülnénk a DTD technológia részleteibe, azt hiszem tisztáznom kell egy kérdést, amit ugyan érintettünk már, de nem tárgyaltuk meg részletesen. Ez pedig a dokumentumok ellenõrzésének (validálásának) jelentõsége. Amint azt korábban említettem a sémák alkalmazásának legfõbb oka az XML dokumentumok ellenõrizhetõvé tétele. Amit azonban eddig nem mondtam, az az, hogy egy XML dokumentumnak nem kell feltétlenül helyesnek lennie ahhoz, hogy használni tudjuk. Szóval a dokumentumok ellenõrzésével kapcsolatos történetnek még nincs egészen vége, fejezzük tehát be. A dokumentum érvényessége (validity) mellet az XML megalkotói bevezettek egy új fogalmat is, mégpedig a jól formázottságot (well-formedness). Egy dokumentum jól formázott akkor, ha szerkezetileg megfelel az XML szabvány minden egyes elõírásának. A jól formázott dokumentumok tehát biztosan megfelelnek az elõzõ órában említett öt feltételnek, viszont nem föltétlenül minõsülnek érvényesnek valamilyen szabályrendszer szempontjából. Ez utóbbi úgy lehetséges, hogy a jól formázott dokumentumhoz nem föltétlenül tartozik séma. Ha tehát ezen új szempontok alapján szemléljük az XML dokumentumokat, akkor gyorsan rájöhetünk, hogy a „helyességnek” az XML-ben két foka van. Az elsõ lépcsõfok a jól formázottság, ami mindössze annyit jelent, hogy dokumentumunk szerkezete megfelel az XML valamennyi, meglehetõsen merev szabályának. A második lépcsõ a dokumentum érvényes volta (validity), ami azt jelenti, hogy annak szerkezete nem csak az XML szabályrendszeréhez igazodik, hanem egy DTD vagy XSD formájában létezõ sémában megadott, ennél még szigorúbb logikához is. A fentiekbõl következõleg valamennyi érvényes (valid) dokumentum egyben jól formázott is (well-formed), viszont ennek a fordítottja nem föltétlen igaz.
Az érvényesség és a jól formázottság fogalma rendkívül fontos az XML terminológiájában, így mi is gyakran fogunk velük találkozni a könyv hátralevõ részében. Azt, hogy egy XML dokumentum az adott környezetben érvényes-e vagy sem, az alkalmazás módja, vagyis az anyagot kezelõ XML alkalmazás igényei döntik el. Ugyanakkor minden használható dokumentumnak jól formázottnak kell lennie, ellenkezõ esetben garantáltan hibaüzenetet kapunk a feldolgozása során. Összefoglalva tehát a jól formázottság eléréséhez magának az XML nyelvnek a formai szabályait kell betartanunk, míg az érvényesség egy sémában rögzített szabályrendszer alapján dõl el. Hogy az XML dokumentumok miként validálhatók egy DTD vagy XSD séma alapján, arról a 8. órában lesz részletesen szó.
03xml.qxd
5/16/2006
12:48 PM
Page 51
3. óra • Az adatok meghatározása DTD séma segítségével 51
A DTD alapjai Amint azt már tudjuk a DTD technológia jelenti az „eredeti” sématechnológiát, illetve arról is volt már szó, hogy a DTD logikailag szorosan összeépül azokkal az XML fájlokkal, amelyek leírására szolgál. Ahhoz tehát, hogy megérthessünk, hogyan épülnek fel a DTD sémák, elõbb az XML dokumentumokkal való viszonyukkal kell tisztában lennünk. Ahhoz, hogy egy XML dokumentum és egy DTD séma között kapcsolatot teremtsünk, a dokumentumban valahogyan hivatkoznunk kell a sémára. Az összerendelést a dokumentumtípus deklarációján (document type declaration) keresztül valósíthatjuk meg, amely a dokumentum elején, közvetlenül az XML deklaráció után szerepel:
Az ebben a példában látható második sor nem más, mint a már korábban látott Tall Tales dokumentumtípus deklarációja. Számunkra pillanatnyilag a legfontosabb annak megfigyelése, miként határozhatjuk meg a sémát tartalmazó DTD-t. Ami azt illeti, a DTD-k és a dokumentumtípus deklarációja körüli terminológia kissé félrevezetõ, tehát nem árt, ha rögtön az elején tisztázzuk, hogy melyik mit is jelent pontosan. A DTD A Document Type Definition rövidítése. Egy DTD fájl nem egyéb, mint egy XML alapú jelölõnyelv formális leírása, definíciója. A dokumentumtípus deklarációja (document type declaration) ezzel szemben egyetlen sornyi kód, amiben megadjuk, hogy az adott dokumentumban melyik DTD-ben leírt jelölõnyelvet fogjuk használni. Összefoglalva tehát a definíció magát a nyelvet írja le, míg a deklarációban csak azt közöljük, hogy melyik nyelvet fogjuk használni. Ugye érthetõ? No, akkor haladjunk tovább! A DTD a dokumentumok logikai szerkezetének alapvetõ részleteit írja le, vagyis az adott jelölõnyelvben használható elemeket, attribútumokat, valamint azok egymáshoz való viszonyát. Egy DTD-n belül a következõ dolgokat adhatjuk meg: • • • •
Az adott dokumentumtípusban megengedett elemek körét Az egyes elemekhez rendelhetõ attribútumokat A dokumentumban szerepeltethetõ egyedeket (entity) A külsõ egyedekkel kapcsolatban használható jelöléseket
Az elemeket és az attribútumokat már ismerjük, viszont a két utolsó dolog egyelõre teljesen új területet képvisel. Semmi gond, az egyedekrõl és a jelölésekrõl a következõ órában bõven lesz majd szó. Egyelõre maradjunk annyiban, hogy a DTD legfontosabb feladata annak biztosítása, hogy az XML dokumentumok helyessége ellenõrizhetõ legyen.
3
03xml.qxd
5/16/2006
12:48 PM
Page 52
52 II. rész • Az XML adatok meghatározása
Amikor összerendelünk egy DTD-t és egy dokumentumot, a dokumentumtípus deklarációjában alapvetõen kétféle eljárást követhetünk: • Maga a deklaráció tartalmazhat bizonyos leírásokat. Ilyenkor belsõ DTD-rõl (internal DTD) beszélünk. • A deklaráció hivatkozhat egy külsõ fájlra, ami a DTD-t tartalmazza. Az a külsõ DTD (external DTD). Ebbõl a különbségtételbõl egyelõre annyi nyilvánvaló tehát, hogy a DTD-nek alapvetõen két része van, vagy legalábbis lehet: egy külsõ és egy belsõ. Amikor egyszerûen egy dokumentum DTD-jérõl beszélünk, akkor hallgatólagosan a külsõ és a belsõ rész egyesítésére gondolunk. Az, hogy a DTD az említett módon két részre tagolódik, alapvetõen a hajlékonyságot szolgálja. A külsõ DTD rendszerint az adott dokumentumtípus átfogó, soha nem változó szerkezetét írja le, míg a belsõ DTD-ben olyan elõírások szerepelnek, amelyek az adott dokumentumra specifikusak. Az XML szabvány a belsõ DTD elõírásait magasabb prioritásúnak tekinti, vagyis a belsõ DTD a külsõben megadott általános szabályok felülbírálatára is használható. Akinek van némi tapasztalata a CSS (Cascading Style Sheets) technológiával kapcsolatban, az valószínûleg felfedezte, hogy a külsõ/belsõ viszony tekintetében a DTD-k ugyanazt a logikát követik, mint a stíluslapok, vagyis a dokumentumhoz „közelebbi” belsõ leírás felülbírálja a külsõt.
A DTD részei Egy dokumentumtípus-deklaráció általános formája a következõ:
Sokan úgy gondolhatják, hogy az XML használatához tulajdonképpen fölösleges ismerni a DTD technológia mûködését, és be kell valljam, ezeknek a kételkedõknek van is valami igazuk. Valójában az XML-lel úgy is lehet érdekes dolgokat megvalósítani, ha semmit sem tudunk a sémákról. Ugyanakkor magát az XML technológiát lehetetlen anélkül megérteni, hogy átlátnánk, hogyan és mibõl épül fel egy XML alapú jelölõnyelv. És mivel ezeket a nyelveket DTD-vel és más technológiákkal készült sémák írják le, ezek ismerete végsõ soron nem spórolható meg. A külsõ DTD-re az ExternalDTDRef részben hivatkozunk, ami nem más, mint a külsõ DTD-t tartalmazó fájl URI-ja (Unified Resource Identifier). A belsõ DTD leírásait szimbolizálja az InternalDTDDecl, ami szögletes zárójelek között ([]) szerepel. A belsõ és külsõ DTD mellett van még egy rendkívül fontos információ, amit szerepeltetni kell a dokumentumtípus-deklarációban, ez pedig az adott dokumentumtípusra jellemzõ
03xml.qxd
5/16/2006
12:48 PM
Page 53
3. óra • Az adatok meghatározása DTD séma segítségével 53
gyökérelem (RootElem). A SYSTEM kulcsszó azt jelzi, hogy a DTD-t egy külsõ fájl tartalmazza. A következõ példában azt mutatom be, miként lehet egy dokumentumban egyszerre belsõ és külsõ DTD-t használni: [ ]>
Az URI (Uniform Resource Identifier) a sokak által ismert URL (Uniform Resource Locator) olyan általánosított változata, amellyel fájloktól különbözõ hálózati erõforrásokat is azonosíthatunk. Az URL-eket – mint közismert – a leggyakrabban weblapok címeként használjuk. Ez a kódrészlet azt mutatja, miként hozhatunk létre egy megfelelõ dokumentumtípusdeklarációt a korábban említett Tall Tales játék alapját képezõ XML dokumentumokban. Látható, hogy a dokumentum gyökéreleme a talltales lesz, ami azt jelenti, hogy minden ilyen típusú dokumentumnak tartalmaznia kell egy és csakis egy ilyen elemet, és ennek a dokumentum teljes tartalmát magában kell foglalnia. A deklaráció említ egy külsõ DTD-t, amit a TallTales.dtd nevû fájl tartalmaz. Az ebben található formai és logikai leírások mellett maga a deklaráció is leír egy question nevû elemet a belsõ DTD részeként. Emlékezzünk rá, hogy a belsõ DTD elemei minden esetben felülbírálják a külsõ DTD azonos nevû elemeinek deklarációját. Ugyanakkor természetesen nem kötelezõ minden esetben belsõ DTD-t használni. Ami azt illeti, az esetek többségében a külsõ DTD tökéletesen elegendõ a formai követelmények leírására. A dokumentumtípus-deklarációnak az XML deklaráció után, de még az elsõ elem (címke) elõtt kell szerepelnie a dokumentumban.
Az elõzõ órában tanultunk az XML deklarációról, amelynek mindig a dokumentum elsõ sorában kell szerepelnie, és feladata a használt XML szabvány megadása. Az XML deklaráció azonban maga is tartalmazhat a DTD-re vonatkozó információkat. Itt a dokumentum önálló státuszára (standalone) és az alkalmazott karakterkódolási szabványra gondolok. Az önálló státusz (standalone status) azt jelzi, hogy a kérdéses dokumentum támaszkodik-e valamilyen külsõ információforrásra, például egy DTD-re. Ha van ilyen külsõ forrás, és ezt kifejezetten jelezni szeretnénk a dokumentum deklarációjában, azt a következõképpen tehetjük meg:
3
03xml.qxd
5/16/2006
12:48 PM
Page 54
54 II. rész • Az XML adatok meghatározása
A dokumentumokban alkalmazható karakterkódolásokról a következõ órában fogunk tanulni.
Ha a fenti deklarációban a standalone kulcsszó után yes áll, az azt jelzi, hogy a dokumentum semmiféle külsõ információforrásra nem támaszkodik. A no érték ezzel szemben azt jelenti, hogy dokumentumunk nem önálló, vagyis feldolgozása során szükség lehet külsõ forrásokra is. Az olyan dokumentum, amely külsõ DTD-re támaszkodik, nyilvánvalóan nem lehet önálló, így ezekben az esetekben a standalone után csak no állhat.
Elem vagy attribútum? Egy DTD két legfontosabb összetevõje az elem és az attribútum. Ezek az összetevõk attól olyan fontosak, hogy õk képezik egy XML dokumentum logikai szerkezetét. Az elem nem más, mint a tárolt információ egy logikai egysége, az attribútum pedig ennek az egységnek valamilyen kiegészítõ jellemzõjét hordozza. Ez egy lényeges különbségtétel, ugyanis XML adatszerkezetek tervezése közben gyakran találjuk majd szembe magunkat azzal a dilemmával, hogy egy adott információtípust elemként vagy attribútumként érdemes-e tárolni. Az ilyen esetekben a leghasználhatóbb megközelítés az, ha elgondolkodunk azon, miféle információról van szó pontosan, illetve milyen módon fogjuk azt használni. Ha attribútumot használunk, azzal szûkebb keretek közé szorítjuk vagy szoríthatjuk magunkat, ami néha hasznos lehet. Kicsit konkrétabban attribútumok esetén megadhatjuk a lehetséges értékek listáját, illetve megadhatunk alapértelmezett értéket is. Az elemek tartalma ezzel szemben sokkal kevésbé kötött, és leginkább hosszú karakterláncok, vagy gyermekelemek tárolására alkalmas. A következõ listában összefoglaltam, milyen elõnyökkel járhat, ha elem helyett attribútumot használunk: • Az attribútumokhoz meghatározhatjuk a lehetséges értékek körét egy felsorolás formájában. • Az attribútumoknak lehet alapértelmezett értékük. • Az attribútumoknak van adattípusa, bár kétségtelen, hogy viszonylag szûk listából válogathatunk. • Az attribútumok segítségével igen tömör formában tárolhatunk információt. Ugyanakkor kétségtelen, hogy az attribútumok sem jelentenek megoldást minden problémára. Íme tehát egy lista azokról a hátrányokról, amelyekkel az attribútumok használata esetén számolnunk kell: • Az attribútumok nem alkalmasak hosszú karakterláncok tárolására. • Attribútumon belül nincs lehetõségünk az információk egymásba ágyazására. • Az attribútumok értékében számítanak a szóközök és egyéb üres karakterek is.
03xml.qxd
5/16/2006
12:48 PM
Page 55
3. óra • Az adatok meghatározása DTD séma segítségével 55
Tekintve hogy az attribútumok tömörebb és egyszerûbb formában tárolják az információt, mint a gyermekelemek, célszerû rájuk mindannyiszor támaszkodni, ahányszor ezt a kérdéses adatszerkezet és felhasználási mód lehetõvé teszi. Szerencsére az említett korlátozások meglehetõsen egyértelmûvé teszik, mikor kell gyermekelemet és mikor attribútumot használnunk. Ha egy információ csak hosszú karakterláncként adható meg, logikai szerkezete egymásba ágyazást igényel, vagy jelentéssel nem bíró, de változó számú üres karaktert tartalmaz, amelyeket a rendszernek majd figyelmen kívül kell hagynia, nyilvánvalóan gyermekelemet kell használnunk a tárolására. Minden egyéb esetben tökéletesen megfelel egy attribútum is, sõt valószínûleg ez lesz a jobb választás. Mindazonáltal akármennyire jól illeszkedik is a kezelni kívánt adatszerkezet az attribútumok kedvezõ tulajdonságaihoz, egy elemnek, nevezetesen egy gyökérelemnek mindenképpen lennie kell a dokumentumban.
Ássunk az elemek mélyére! Ahhoz, hogy egy DTD-ben megadjuk egy elem leírását, a következõ formátumú elemdeklarációt (element declaration) kell használnunk:
Az elem neve értelemszerûen annak a címkének a nevét határozza meg, amit az XML dokumentumban az adott elemtípus azonosítására fogunk használni. Az is magától értetõdõ, hogy ennek a névnek az adott DTD-n belül egyedinek kell lennie. Az elem típusát a Type mezõben határozhatjuk meg. Az XML összesen négy elemtípust különböztet meg, amelyeket az adott elemben tárolt tartalom határoz meg: • Empty – Üres elem, amelynek nincs semmiféle tartalma. (Ugyanakkor attribútumai lehetnek). • Element-only – Olyan elem, amely csak gyermekelemeket tartalmaz. • Mixed – Kevert tartalmú elem, vagyis gyermekelemeket és szöveget egyaránt tartalmaz. • Any – Tetszõleges típus. Az ilyen elem bármit tartalmazhat, amit az adott DTD megenged. Az elemek neve nem tartalmazhat & (ampersand) jelet, illetve nem kezdõdhet az X, M és L betûk ebben a sorrendben vett semmilyen kis- és nagybetûkbõl álló kombinációjával (XML, xml, XmL és így tovább).
A következõ szakaszokban az egyes elemtípusokat vizsgáljuk meg részletesebben.
3
03xml.qxd
5/16/2006
12:48 PM
Page 56
56 II. rész • Az XML adatok meghatározása
Üres elemek Az üres elemek értelemszerûen nem tartalmaznak sem szöveget, sem gyermekelemeket, viszont információtárolás szempontjából mégsem teljesen haszontalanok, hiszen lehetnek attribútumaik. Egy üres elemet a következõ deklarációval adhatunk meg a DTD-ben:
Íme egy ezzel a szintaxissal megadott elem:
Miután a DTD-ben megadtunk egy üres elemet, kétféleképpen használhatjuk azt egy dokumentumon belül: • Használhatunk nyitó és záró címkét • Használhatjuk az üres elemek leírására rendszeresített rövidítést Elõzõ példánkkal kapcsolatban az elsõ esetnek a
írásmód felel meg. Figyeljük meg, hogy a két címke között semmiféle tartalom nem szerepel, még egy szóköz sem. Ellenkezõ esetben a dokumentum érvénytelen lenne. Az üres elemek megadásának jóval tömörebb formája a már ismert rövidített alak használata. Esetünkben ez a következõképpen fest:
Amint már említettük, ez az írásmód a nyitó és a záró címke egyfajta kombinációja, amely amellett, hogy tömörebb, formájával egyrészt világossá teszi az adott elem üres voltát, másrészt meg is akadályozza a tévedéseket. Amint már többször hangsúlyoztam, az üres elemekhez is tartozhatnak attribútumok. A példánkban szereplõ, ruhák leírására szolgáló üres elem például a következõ tulajdonságokat hordozhatja:
03xml.qxd
5/16/2006
12:48 PM
Page 57
3. óra • Az adatok meghatározása DTD séma segítségével 57
Gyermekelemek egy csak elemeket tartalmazó (element-only) elemben Egy csak elemeket tartalmazó (element-only) elem elnevezésének megfelelõen kizárólag más elemeket tartalmazhat. Másként fogalmazva egy ilyen elemben nem bukkanhat fel önálló szöveges tartalom, csak más elemekbe ágyazottan. A DTD-ben úgy hozhatunk létre egy ilyen tárolóelemet, hogy a deklarációjában felsoroljuk, milyen nevû elemeket tartalmazhat. Ezt nevezzük a kérdéses elem tartalmi modelljének (content model). Az ilyen deklarációk általános formája a következõ:
A tartalmi modell speciális elemdeklarációs szimbólumokból, és elemnevekbõl áll össze. A szimbólumok az elemek egymás közti, valamint a szülõvel kapcsolatos logikai viszonyát írják le. A gyermekelemekbõl kerek zárójelekkel sorozatokat (sequence) vagy úgynevezett választási csoportokat (choice group) hozhatunk létre. A sorozat csupán a gyermekelemek sorrendjét írja elõ, míg a választási csoportok az elemek használatának alternatív módozatait írják le. A sorozatban a gyermekelemek neveit, vesszõ (,), míg a csoportban szûrõkarakter (|) választja el egymástól. Lássuk az alkalmazható szimbólumok rövid összefoglalását: • Kerek zárójelek (()) – Gyermekelemek sorozatát (sequence) vagy egy választási csoportot (choice group) zárnak közre. • Vesszõ (,) – Egy sorozat elemeit választja el egymástól. A sorozat az elemek kötelezõ sorrendjét írja elõ. • Szûrõkarakter (|) – Az alternatívákat választja el egy választási csoportban. • Nincs szimbólum – Azt jelzi, hogy egy gyermekelem pontosan egyszer fordulhat elõ. • Kérdõjel (?) – Azt jelzi, hogy a kérdéses gyermekelem pontosan egyszer fordulhat elõ, vagy egyszer sem. • Pluszjel (+) – Azt jelzi, hogy a gyermekelemnek legalább egyszer elõ kell fordulnia. • Csillag (*) – Az adott gyermekelem tetszõlegesen sokszor fordulhat elõ. Bár ezeknek a jeleknek a pontos használatáról most oldalakat írhatnék, azt gondolom egy viszonylag összetett példa elemzése sokkal sokkal hasznosabb lesz. Lássuk tehát egy resume (önéletrajz) nevû elem deklarációját:
Ez a példa attól olyan kiváló, hogy az összes imént említett szimbólum elõfordul benne. A resume csak elemeket tartalmazó (element-only) elem, vagyis kizárólag gyermekelemek lehetnek benne. Az elsõ ilyen az intro, amely pontosan egyszer fordulhat
3
03xml.qxd
5/16/2006
12:48 PM
Page 58
58 II. rész • Az XML adatok meghatározása
elõ, hiszen semmiféle speciális szimbólum nem csatlakozik hozzá. Az education és az experience elemeket magában foglaló zárójelen kívül látható pluszjel azt jelzi, hogy ennek a csoportnak legalább egyszer szerepelnie kell. A zárójelen belül az education után nincs semmiféle minõsítés, tehát ennek pontosan egyszer szabad elõfordulnia. Az experience ezzel szemben legalább egyszer kell szerepeljen, de több elõfordulása is megengedett. Nyilván megeshet, hogy valaki több helyen is dolgozott, és többféle munkakörrel kapcsolatban szerzett tapasztalatot. A hobby elemnek legfeljebb egyszer szabad szerepelnie, vagy egyszer sem, ami azt jelenti, hogy ha adunk meg magunkról ilyen információt, akkor ezt egyetlen elem formájában kell leírnunk. Végezetül a references elem akárhányszor szerepelhet az önéletrajzban. Hogy legyen valami fogalmunk arról, miféle gyakorlati felhasználása lehet a csak elemeket tartalmazó elemeknek, vessünk egy pillantást a következõ, az RSS nyelv DTDjébõl származó sorra:
Az RSS egy olyan XML alapú jelölõnyelv, amely lehetõvé teszi, hogy a webes portálokon megjelenõ friss hírekrõl és egyéb tartalmakról a különbözõ alkalmazások rövid összefoglalót töltsenek le. A Sports Illustrated webhely (http://sortsillustrated.cnn.com) például valamennyi jelentõsebb sportág híreivel kapcsolatban szolgáltat RSS tartalmat. A többi sporthírekkel kapcsolatos webhely ez alapján frissítheti a saját hivatkozásait, illetve használhatunk valamilyen speciális RSS aggregátort is. Ilyen például a http://www.feeddemon.com címen elérhetõ FeedDemon. Az aggregátorok segítségével az RSS tartalmakat körülbelül úgy jeleníthetjük meg, mint a leveleket egy levélolvasó alkalmazással. Visszatérve az iménti DTD-bõl származó sorhoz látható, hogy az item elem a title, link és description elemek tetszõleges kombinációját tartalmazhatja, de egyikbõl sem lehet egynél több. Lássuk, hogyan valósul meg mindez magában az XML kódban. A következõ kódrészlet a Sports Illustrated NFL híranyagából származik: Titans’ trio of young WRs showing promise http://sportsillustrated.cnn.com/rssclick/2005/football/nfl/06/22/ bc.fbn.titans.receivers.ap/index.html?section=si_nfl <description>Read full story for latest details.
Ha látni szeretnénk a Sports Illustrated valamelyik híréhez tartozó XML kódot, menjünk a webhely nyitólapjára, majd kattintsunk az oldal alján látható XML logóra. Megjelenik a hírtartalmak listája, amelyben bármelyik sorra kattintva elõbukkan a kérdéses RSS tartalom XML kódja.
03xml.qxd
5/16/2006
12:48 PM
Page 59
3. óra • Az adatok meghatározása DTD séma segítségével 59
Amint látható, az item elem valóban pontosan egy példányt tartalmaz mind a title, mind a link, mind pedig a description gyermekelembõl. Aki látni szeretné, hogyan mûködik mindez a gyakorlatban, látogasson el az én weblapomra, és nézze meg az ott ezzel a módszerrel gyûjtött NFL híreket (3.1. ábra).
3
NFL hírek
3.1. ábra Az NFL hírek megjelenése saját weblapomon.
A fenti ábra azt mutatja, miként jelenik meg az én weblapomon az iménti RSS kódban bemutatott, és a Tennessee Titansról szóló híranyag A következõ szakaszban azt fogom bemutatni, miként határozza meg az RSS DTD-je az elõbb említett gyermekelemeket. A hírek átvételérõl, illetve az ezzel kapcsolatos technológiák saját céljainkra való felhasználásáról egyébként a 24. órában részletesen is lesz szó.
A szöveges tartalom és a gyermekelemek kombinálása kevert elemekben A kevert elemek (mixed elements) szöveget és gyermekelemeket egyaránt tartalmazhatnak. A legegyszerûbb kevert tartalmú elem tulajdonképpen a csak szöveget tartalmazó elemtípus. Az ilyen elemeket a következõképpen deklarálhatjuk a DTD-ben:
03xml.qxd
5/16/2006
12:48 PM
Page 60
60 II. rész • Az XML adatok meghatározása
A tisztán szöveges elem tartalmi modellje kizárólag a kerek zárójelek között szerepeltetett #PCDATA szimbólumból áll, amely azt jelzi, hogy ez az elem kizárólag értelmezett (parsed) szöveget tartalmaz (PCDATA = Parsed Character DATA). Íme egy ilyen tisztán szöveges elem deklarációja:
A PCDATA, vagyis Parsed Character DATA kifejezésben a parsed (értelmezett) szó arra utal, hogy a dokumentumnak azt a részét az XML alkalmazás a feldolgozás során értelmezni fogja. Az XML dokumentumok szöveges tartalmának jelentõs része ilyen értelmezett tartalom, beleértve a karakteregyedeket is. Az értelmezési folyamat során az alkalmazás elõször eldobja az összes fölösleges üres karaktert (szóköz, tabulátor), majd a karakteregyedeket azok megfelelõjével helyettesíti. A PCDATA ellentéte a CDATA (Character DATA), ami az XML alkalmazás által fel nem dolgozandó szöveget jelöl. Késõbb megtanuljuk, pontosan mire is jó ez az utóbbi adattípus. Ez az elem nevének megfelelõen a hobbik felsorolását tartalmazhatja egy XML dokumentumon belül. Íme egy példa ennek a lehetõségnek a használatára: juggling, unicycling, tight-rope walking
Ha már a példáknál tartunk, a következõ három sor a már említett RSS jelölõnyelv sémájából a title, a link és a description elemek DTD deklarációját tartalmazza:
Amint látható, mindhárom tisztán szöveges elem, amin tulajdonképpen nincs is mit csodálkozni, ismerve a felhasználási módjukat. A tisztán szöveges elemek valójában olyan kevert elemek, amelyek nem tartalmaznak gyermekelemeket. Az olyan elemeket, amelyeken belül a szöveg mellett további elemek is elõfordulhatnak, egészen hasonlóan kell megadni. Mindössze néhány apró eltérés van. Kicsit konkrétabban egy kevert tartalmú elem tartalmi modelljében lennie kell egy a következõ általános formának megfelelõ ismétlõdõ választási listának:
Ha elsõre meglehetõsen zavarosnak tûnik a dolog, semmi gond. Nézzük részekre bontva. A lista elején szereplõ #PCDATA szimbólum azt jelzi, hogy elemünk maga is tartalmazhat szöveget. A lista további tagjait az elemek felsorolása képezi, a felépítés
03xml.qxd
5/16/2006
12:48 PM
Page 61
3. óra • Az adatok meghatározása DTD séma segítségével 61
pedig erõsen hasonlít a csak elemeket tartalmazó elemek tartalmi modelljére. Itt helyenként újabb #PCDATA szimbólumok is felbukkanhatnak, jelezvén, hogy a gyermekelemek is hordozhatnak szöveges tartalmat. A tartalmi modellt egy csillag (*) kell zárja, amely azt jelzi, hogy a teljes választási csoport opcionális. Ez utóbbi alapkövetelmény a kevert tartalmú elemek esetében. Szintén lényeges kiemelni, hogy bár a kevert tartalmú elem deklarációja korlátozza a gyermekelemek típusát, azt nem adja meg, hogy ezek milyen sorrendben, illetve hányszor szerepelhetnek. A kevert tartalmú elemek tartalmi modelljében a karakteres adatokat azonosító (#PCDATA) szimbólumnak mindig a lista elején, a választási csoport elsõ tagjaként kell szerepelnie. Magát a csoportot egy utána írt csillaggal minden esetben opcionálissá kell tenni. Bár a kevert tartalmú elemek számottevõ mértékben növelik az adatszerkezet hajlékonyságát, nem rendelkeznek azzal a kötött struktúrával, mint a csak gyermekelemeket tartalmazóak. Ennek megfelelõen – eltekintve a tisztán szöveges elemektõl – célszerû kerülni a kevert tartalmú elemek használatát, amennyire az lehetséges. Számos esetben egyébként az elkerülõ megoldást az jelenti, ha a kiegészítõ információkat egy tisztán szöveges elem attribútumaiként adjuk meg.
Tetszõleges tartalmú (ANY) elemek A tetszõleges tartalmú (any) elemek jelentik a leginkább flexibilis szerkezeti egységet, hiszen gyakorlatilag semmiféle belsõ szerkezettel nem rendelkeznek. Ezt az elemtípust az ANY kulcsszóval deklarálhatjuk, és nevének megfelelõen bármit tartalmazhat, amit az adott DTD lehetõvé tesz: szöveget, gyermekelemeket, vagy ezek tetszõleges kombinációját. Az ANY elemet olyan kevert tartalmú elemnek képzelhetjük, amelynél a tartalommal kapcsolatos megkötéseket kiiktattuk. Deklarációjának általános alakja a következõ:
Gondolom nem okozok nagy meglepetést, amikor azt mondom, hogy az ANY az az elemtípus, amit bármi áron el kell kerülnünk egy DTD-ben. Mivel nincs belsõ szerkezete, ez az elemfajta tulajdonképpen ellentétes az XML alaptörekvésével. Az is igaz ugyanakkor, hogy az iménti kitétel csak a végleges DTD-kre alkalmazható szigorúan. A tesztelési fázisban az ANY elemek használata néha kifejezetten jól jöhet.
3
03xml.qxd
5/16/2006
12:48 PM
Page 62
62 II. rész • Az XML adatok meghatározása
Használjunk attribútumokat Az attribútumok – amelyek az esetek többségében kéz a kézben járnak az elemekkel – használata igen fontos része a DTD-k létrehozásának. Egy attribútumot általában arra használunk, hogy egy elemmel kapcsolatban valamilyen kiegészítõ információt adjuk meg. Kicsit konkrétabban az attribútum tulajdonképpen egy név/érték páros, amely az elem valamilyen tulajdonságát írja le. Egy DTD-ben az attribútumokat attribútumlista formájában adhatjuk meg, amelynek általános alakja a következõ:
Látható, hogy egy attribútumnak minden esetben van neve (AttrName), típusa (AttrType), valamint lehet alapértelmezett értéke (Default). Az alapértelmezett érték lehet egy számérték vagy egy szimbólum, amely az attribútum használatára utal. Az alapértelmezett értékeknek négy típusa létezik, vagyis a Default helyén a következõ négy kulcsszó szerepelhet: • • • •
#REQUIRED – Az attribútum megadása kötelezõ #IMPLIED – Az attribútum megadása opcionális #FIXED – Az attribútum kötött értékkel rendelkezik default – Az attribútum alapértelmezett értéke
A #REQUIRED kulcsszó kötelezõen használandó attribútumot jelöl, vagyis amikor egy ilyen elemet használunk, annak mindenképpen be kell állítanunk ezt a tulajdonságát. Az #IMPLIED ezzel szemnem opcionális attribútumot takar, amit tetszés szerint vagy megadunk, vagy nem. A #FIXED attribútumnak kötött értéke van, ami gyakorlatilag azt jelenti, hogy az így megadott tulajdonság valamiféle konstans. Az értéket a #FIXED kulcsszó után, magában a deklarációban kell megadnunk. A negyedik lehetõség nem más, mint az alapértelmezett érték listájában történõ megadása. Ez az érték akkor jut érvényre, ha a felhasználó nem ad meg explicit módon semmit az elem létrehozásakor. Nézzünk egy példát a dolog gyakorlati megvalósítására. Legyen distance egy olyan elem, amely valamilyen távolságot hordoz. A távolságnak nyilván kell legyen mértékegysége is, mégpedig a következõk szerint:
Látható, hogy a distance-nak példánkban mindössze egyetlen attribútuma van, mégpedig units. Ez utóbbi összesen háromféle értéket vehet fel: miles, kilometers, laps. Az alapértelmezett értéke miles, vagyis ha a felhasználó nem ad meg mértékegységet, akkor mérföldet kell érteni.
03xml.qxd
5/16/2006
12:48 PM
Page 63
3. óra • Az adatok meghatározása DTD séma segítségével 63
Bár az attribútumlisták megadásának helye a DTD-n belül nem kötött, a fejlesztõk körében általánosan elfogadott, hogy azt annak az elemnek a deklarációja után szerepeltetik, amelyhez tartozik. Az alapértelmezett érték mellett az attribútumlista deklarációjának tartalmaznia kell az attribútumok típusát is. Összesen 10 különféle típust használhatunk: • • • • • • • • •
CDATA – Nem értelmezett (unparsed) szöveges adat Enumerated – Karakterláncok sorozata NOTATION – Egy a DTD más pontján megadott jelölés ENTITY – Külsõ bináris egyed ENTITIES – Több különféle külsõ bináris egyes üres karakterekkel elválasztva ID – Egyedi azonosító IDREF – Egy a DTD más pontján deklarált ID-ra mutató hivatkozás IDREFS – Több különbözõ, máshol deklarált ID-ra mutató hivatkozás NMTOKEN – XML tokenekbõl (számok, betûk, pontok, kötõjelek, kettõspontok és
aláhúzásjelek) felépített név • NMTOKENS – Több XML tokenekbõl felépített név Ahhoz, hogy megérthessük az attribútumtípusok közötti különbségeket, célszerû azokat három csoportra osztani. Vannak karakterláncok, felsorolt típusok és tokenizált típusok. A karakterláncok jelentik az attribútumok legközönségesebb és leggyakrabban használt típusát. Ide tartozik a CDATA típus, amely egy karakterláncból álló attribútumot takar. A következõ példa azt mutatja, hogyan deklarálhatunk egy a korábban említett education elemhez tartozó CDATA típusú attribútumot:
Ebben a példában annak az iskolának a nevét, amelyben az illetõ a tanulmányait végezte az education elem egy kötelezõen megadandó attribútuma (school) hordozza. Ha az attribútum megadását opcionálissá akarjuk tenni, az #IMPLIED szimbólumot kell használnunk:
A felsorolt típushoz tartozó attribútumok értéke csak bizonyos elõre meghatározott halmazelemek közül kerülhet ki. A felsorolt típusok amúgy hasonlítanak a CDATA típushoz, a különbség csak annyi, hogy a deklaráció részeként lehetséges értékeket is meg kell adnunk egy felsorolás formájában. Korábbi példánknál maradva nézzük, miként adhatunk meg egy az illetõ végzettségének típusát tároló attribútumot (degree):
3
03xml.qxd
5/16/2006
12:48 PM
Page 64
64 II. rész • Az XML adatok meghatározása
Amikor egy dokumentumban a degree attribútumot használjuk, annak értékét a fent látható felsorolásból kell választanunk. Ha nem adunk meg semmit, még az attribútum nevét sem, akkor annak alapértelmezett értéke bachelors lesz. A tokenizált attribútumokat az XML alkalmazások – nevüknek megfelelõen – tokenekként kezeik, vagyis eltávolítják elõlük és mögülük az összes üres karaktert, a bennük elõforduló több összefüggõ üres karakterbõl álló részeket pedig egyetlen szóközre cserélik. Az üres részek eltávolításán túl az alkalmazás validálja is a tokenizált attribútumot annak deklarált típusa alapján. Ez utóbbi lehet ENTITY, ENTITIES, ID, IDREF, IDREFS, NMTOKEN, vagy NMTOKENS. A token az információnak az a legkisebb egysége, amit egy XML alkalmazás képes feldolgozni. A tokenizált attribútum ennek megfelelõen olyan attribútum, amelynek értékét az alkalmazás ilyen tokenekre bontja. Az üres karakterek említett eltávolítása ennek a felbontásnak a mellékhatása. (Üresnek számít a szóköz, a tabulátor és az új sor.) A közönséges karakterláncok ezzel szemben feldolgozatlanul jutnak át a folyamaton, így az összes üres karakter is megmarad bennük. Az ENTITY és ENTITIES típusok egyedekre hivatkoznak. Az egyedekrõl a következõ óra anyagában lesz szó részletesen. Itt és most csak egy példát említek meg. A képek tipikusan bináris egyedekként jelennek meg az XML dokumentumokban. Ilyen esetben az ENTITY kulcsszót használjuk a kép és az elem összerendelésre:
Az ENTITIES típus hasonló az ENTITY-hez, de lehetõvé teszi több egyed felsorolását. Az ID, IDREF és IDREFS attribútumtípusok egyedi azonosítókat jelölnek. Az ID olyan egyedi azonosító, amely segítségével egyedileg hivatkozhatunk a dokumentum valamely elemére:
Egy adott elemtípushoz csak egyetlen ID típus tartozhat. Az NMTOKEN és NMTOKENS típusok olyan attribútumokkal kapcsolatban használatosak, amelyek név jellegû tokenértékeket hordoznak. A név jellegû tokenérték egyetlen nevet tartalmaz, vagyis nem lehet benne szóköz vagy bármely más üres karakter. Kicsit konkrétabban egy ilyen érték betûket, számokat és a következõ karaktereket tartalmazhatja: . , - , _ és : .
Több attribútum egyidejû használata Egészen eddig csak olyan példákat mutattam, ahol egy elemhez legfeljebb egy attribútum tartozott. Ugyanakkor a való életben nyilván gyakran fordulnak majd elõ olyan esetek is, amikor több ilyen kiegészítõ tulajdonságot is kell valamilyen információhoz
03xml.qxd
5/16/2006
12:48 PM
Page 65
3. óra • Az adatok meghatározása DTD séma segítségével 65
rendelnünk. Ilyenkor is használhatunk egyetlen attribútumlistát a deklarációban, amelyben az egyes tulajdonságokat egymás után felsoroljuk. Íme egy példa erre a módszerre:
Látható, hogy bár a photo nevû elemhez két attribútum (image és photo) tartozik, mindkettõt egyetlen attribútumlista részeként adhattuk meg.
Példa egy teljes DTD-re Készséggel elismerem, hogy ebben az órában meglehetõsen sok volt az új, és erõsen technikai jellegû információ. Bolond beszéd, de van benne rendszer! Ideje, hogy ezt a gyakorlatban is kamatoztassuk. Alkossuk meg tehát egy sporttal kapcsolatos jelölõnyelv teljes sémáját DTD-ben. Ez kiváló alkalmat teremt arra, hogy lássuk, hogyan mûködnek a gyakorlatban az elemek és attribútumok deklarálására bemutatott módszerek. Saját jelölnyelvünk, amit ETML-nek (Endurance Training Markup Language) fogunk hívni azoknak jöhet jól, akik maratonra vagy triatlonra készülnek, és szeretnék edzési tervüket számítógép segítségével kialakítani, illetve nyomon követni. A nyelv az olyan sportágakkal kapcsolatos adatokat modellezi mint az úszás, futás és kerékpározás. Elõször is foglaljuk össze, hogy egy edzési fázisban miféle adatok nyilvántartására lehet szükségünk: • • • • • • •
Dátum – Az edzés ideje Edzéstípus – Milyen edzésrõl van szó (úszás, futás vagy kerékpározás) Pulzusszám – Mekkora lesz az átlagos pulzusszám az edzés során Idõtartam – Az adott edzési szakasz idõtartama Távolság – A megtenni kívánt távolság (kilométerben vagy mérföldben) Hely – Az edzés helye Megjegyzések – Mindennemû egyéb információ vagy megjegyzés
Tudván, hogy mindennek egyetlen, az adott edzéshez tartozó elemben kell elférnie, próbáljuk meghatározni, hogy melyik információt érdemes gyermekelemben, és melyiket attribútumban tárolni. Ennek a feladatnak persze nincs egyetlen, általánosan elfogadott helyes megoldása, viszont bizonyos logikai szempontok alapján végül is nem túl nehéz a döntés. Én magam a következõképpen rendezném el a dolgokat: • Attribútumok – dátum, típus, pulzusszám • Gyermekelemek – idõtartam, távolság, hely, megjegyzések
3
03xml.qxd
5/16/2006
12:48 PM
Page 66
66 II. rész • Az XML adatok meghatározása
A dátum, a típus, és a pulzusszám egyszerû, röviden kifejezhetõ értékek, így optimálisak az attribútumban történõ tárolásra. A típus esetében ráadásul még a választható értékek köre is kötött (futás, kerékpározás és így tovább). Az, hogy az edzés hossza és a megtett távolság gyermekelemben vagy attribútumban kerül rögzítésre ízlés dolga. Ugyanakkor ha elemként modellezzük õket, akkor meghagyjuk magunknak azt a lehetõséget, hogy késõbb attribútumokat fûzhessünk hozzájuk. Ilyen formában adhatjuk meg például egy mennyiség használható mértékegységeit. A hely és a megjegyzések valószínûleg szöveget fognak tartalmazni, tehát ezeket mindenképpen elemként célszerû megvalósítani. Az XML egyik aranyszabálya szerint minél több korlátozást alkalmazunk egy dokumentum tartalmával kapcsolatban, annál jobb lesz a szerkezete. Másként fogalmazva ez azt jelenti, hogy egy séma kialakítása akkor jó, ha a lehetõ legkevesebb kétséget hagyja az elemek és attribútumok használatával kapcsolatban. Ezzel el is készültünk az ETML nyelv koncepciótervével Készen állunk tehát arra, hogy megírjuk a konkrét DTD-t. A kész séma kódját a 3.3. listában láthatjuk. 3.3. lista 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22:
Az ETML nyelvû dokumentumok validálására használható DTD (etml.dtd)
Az eddig tanultak alapján ennek a kódnak minden részletét értenünk kell, ami pedig a koncepciót illeti, a fenti séma mindenben megfelelõ a korábban leírt koncepciótervnek. Az ETML dokumentumok gyökéreleme a trainlog lesz (1. sor). Az egyes edzések adatait session nevû elemek tárolják, amelyeknek duration, distance, location és comments nevû gyermekelemeik lesznek (3. sor). A session elem ezen
03xml.qxd
5/16/2006
12:48 PM
Page 67
3. óra • Az adatok meghatározása DTD séma segítségével 67
kívül három, date, type és heartrate nevû attribútummal rendelkezik (4–7. sorok). Figyeljük meg, hogy a session elem type (6. sor), és a duration illetve distance elemek units (12. és 17. sor) nevû attribútumai csak egy lista szerint vehetnek fel értékeket. Természetesen egyetlen DTD bemutatása sem lehet teljes anélkül, hogy kipróbálnánk a gyakorlatban, vagyis létrehoznánk egy neki megfelelõ XML dokumentumot. A 3.4. lista egy ETML nyelven készült edzésnaplót mutat be. 3.4. lista 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25:
Egy ETML nyelven készült edzésnapló
<session date="11/19/05" type="running" heartrate="158"> 505.5Warner ParkReggeli futás, végig kicsit fullasztó volt. <session date="11/21/05" type="cycling" heartrate="153"> 1.526.4Natchez Trace ParkwayHegymenet, állati húzós volt. <session date="11/24/05" type="running" heartrate="156"> 2.516.8Warner ParkDélutáni futás, elég kemény volt.
Látható, hogy ez a dokumentum mindenben szigorúan ragaszkodik az ETML DTDjéhez, akár a megadható elemeket, akár azok egymásba ágyazását tekintjük. A DTD-t a dokumentumtípus-deklarációban találjuk a fájl elején (2. sor). Egy másik lényeges dolog, amire érdemes odafigyelni a type és units attribútumok használata (5., 12., és 19. sorok). Itt is csak olyan értékek szerepelnek, amelyek benne voltak a DTD-ben megadott listában is. Érdemes megjegyezni, hogy bár ebben a példában csak három edzés adatai szerepelnek, a dokumentumnak akárhány ilyen eleme lehet. Aki tehát duzzad az energiától, és elég erõsnek érzi magát egy maratoni távhoz, nyugodtan kezdje el használni ezt az újonnan megalkotott jelölõnyelvet saját edzéseinek nyilvántartására. Hogy miként lehet egy XML dokumentumot egy DTD alapján validálni, arról a 8. órában lesz szó.
3
03xml.qxd
5/16/2006
12:48 PM
Page 68
68 II. rész • Az XML adatok meghatározása
Összefoglalás Az XML olyan jelölõnyelv, amely más jelölõnyelvek létrehozására használható. Azt a folyamatot, amikor megalkotjuk egy ilyen XML alapú jelölõnyelv logikai struktúráját összefoglaló néven adatmodellezésnek (data modeling) nevezzük. Az adatmodell definíciója, formális leírása a séma. Az XML alapú nyelvek sémáinak leírására két alapvetõen eltérõ technológia létezik, a DTD és az XSD. Mindkettõnek megvannak a maga elõnyei és hátrányai, de funkcionálisan mindkettõ tökéletesen megfelel az XML sémák létrehozására. Ebben az órában megtanultuk, mit jelent a dokumentumok érvényességének ellenõrzése (validálása), illetve hogy mit takar a jól formázottság (well-formedness). Megismerkedtünk ezen kívül a DTD technológia alapjaival, és megvizsgáltuk, hogyan hozhatjuk létre ezzel a technológiával az XML dokumentumok egy osztályának formális leírását. Láttuk, hogyan adhatjuk meg egy teljesen új jelölõnyelv sémáját az egyedi címkékkel kapcsolatos leírásokon keresztül. Amellett, hogy meghatározzák egy adott jelölõnyelv formális szabályait, a DTD-knek óriási jelentõsége van az XML dokumentumok validálásával kapcsolatban is. A sémák legfõbb jelentõsége éppen abban áll, hogy segítségükkel a dokumentumok helyessége gépileg is ellenõrizhetõvé válik. Az óra végén létrehoztuk egy ETML (Endurance Training Markup Language) nevû nyelv sémáját, és ki is próbáltuk azt a gyakorlatban, egy ezen a nyelven megalkotott XML dokumentumon keresztül.
Kérdések és válaszok Kérdés: Egyáltalán nem tervezem, hogy valaha is saját jelölõnyelvet hozzak létre. Kell-e ennek ellenére ismernem a DTD és XSD technológia részleteit? Válasz: Igen. A jelölõnyelvek dokumentációja sajnos számos esetben nem valami részletes. Ilyenkor az egyetlen információforrás az adott nyelv DTD-je vagy XSD-je. Csak ezekbõl leszünk képesek kitalálni, hogy mit hogyan kell használni. Kérdés: Elõfordulhat-e olyan helyzet, amikor DTD-t és XSD-t is létre kell hoznom egy jelölõnyelvhez? Válasz: Nem nagyon. Az egyetlen elképzelhetõ szituáció az, ha kezdetben pusztán kényelmi szempontok alapján DTD-ben dolgozunk, és csak a kész sémát alakítjuk át XSD-vé. Megeshet persze az is, hogy a kezdetben figyelembe vett alkalmazások még támogatják a DTD-t, a késõbbi alkalmazási területek azonban már megkövetelik az XSD séma használatát.
03xml.qxd
5/16/2006
12:48 PM
Page 69
3. óra • Az adatok meghatározása DTD séma segítségével 69
Kérdés: Egyáltalán miért használ valaki belsõ DTD-t? Válasz: A belsõ DTD-t maga az XML dokumentum tartalmazza, nem pedig egy külsõ fájl. Az ebben leírtak ennek megfelelõen csak erre az egy dokumentumra érvényesek. Belsõ DTD-t tehát akkor érdemes használni, ha egy konkrét dokumentummal kapcsolatban akarunk valamit szabályozni. Minden más sémaelemet egy külsõ DTD-ben célszerû rögzíteni, hogy azokat bármely más dokumentum is használhassa. Kérdés: Miért használunk néha attribútumokat elemek helyett, amikor egy DTD-t tervezünk? Válasz: Az attribútumokkal kapcsolatban viszonylag szigorúbb korlátozások alkalmazhatók, mint az elemeknél. Attribútum esetében megadhatjuk a felvehetõ értékek listáját, illetve meghatározhatunk alapértelmezett értéket is. Az elemek tartalmára ezzel szemben sokkal kevesebb korlátozás érvényes. Ezek leginkább hosszú karakterláncok, illetve egyéb elemek (gyermekelemek) tárolására alkalmasak. Az XML egyik alapszabálya szerint minél több korlátozást vezetünk be egy dokumentumtípus logikai szerkezetével kapcsolatban, annál jobban strukturált lesz a tartalom. Ennek megfelelõen minden olyan esetben célszerû attribútumot használni elem helyett, amikor erre lehetõség nyílik.
Feladatok A feladatokat úgy alkottuk meg, hogy segítsenek a felmerülõ kérdések megválaszolásában, a tanultak áttekintésében, és azok gyakorlatba való átültetésében.
Kvíz 1. Mi a rendeltetése egy sémának? 2. Milyen sématechnológiát kell használnunk olyan séma létrehozásához, amelyben meg akarjuk határozni az adattípusokat, vagyis egészeket, dátumokat és egyéb hasonló típusokat akarunk elõírni bizonyos helyeken? 3. Mi a különbség egy érvényes (valid) és egy jól formázott (well-formed) dokumentum között?
Válaszok 1. A séma az adott jelölõnyelvben használható elemeket és attribútumokat adja meg. Leírja ezen kívül, hogy mely attribútumok mely elemekhez tartoznak, illetve hogy ezek milyen logikai viszonyban állnak egymással. 2. Ha speciális típusokat, például egészeket vagy dátum típusokat szeretnénk használni a sémában, akkor az XML Schema technológiát kell használnunk.
3
03xml.qxd
5/16/2006
12:48 PM
Page 70
70 II. rész • Az XML adatok meghatározása
3. A jól formázott (well-formed) dokumentumok megfelelnek az XML minden formai követelményének, míg az érvényes dokumentumok ezen felül egy séma logikai szabályrendszerének is eleget tesznek.
Gyakorlatok 1. Módosítsuk az óra anyagában bemutatott ETML nyelv DTD-jét úgy, hogy a session elemhez egy újabb, rating nevû attribútum is tartozzon. Ennek az attribútumnak az adott edzéssel kapcsolatos megelégedettségünket kell tartalmaznia 1-tõl 10-ig. Egy megfelelõ lista segítségével eleve úgy alakítsuk ki az ezzel kapcsolatos sémabejegyzést, hogy rating csak ilyen értékeket vehessen fel. 2. Módosítsuk a trainlog.xml dokumentumot úgy, hogy az a most bevezetett rating attribútumot is használja.
