Szövegfeldolgozás XML alapokon Bíró, Szabolcs

Átírás

1 Szövegfeldolgozás XML alapokon Bíró, Szabolcs

2 Szövegfeldolgozás XML alapokon Bíró, Szabolcs A könyv az Oktatási Minisztérium támogatásával, az NKTH által lebonyolított Felsőoktatási Tankönyv- és Szakkönyv-támogatási Pályázat keretében jelent meg. Az elektronikus kiadás DocBook XML formátumát Bíró Szabolcs készítette. Szerzői jog 2005 Neumann Kht. Szerzői jog 2005 Bíró Szabolcs Minden jog fenntartva. Jelen könyvet, illetve annak részeit tilos reprodukálni, adatrögzítő rendszerben tárolni, bármilyen formában vagy eszközzel elektronikus úton vagy más módon közölni a szerző és a kiadó engedélye nélkül.

3 Ajánlás Köszönettel tartozom a Neumann János Digitális Könyvtár és Multimédia Központ Kht. minden jelenlegi és volt munkatársának, hogy iránymutatásukkal, tanácsaikkal nagymértékben hozzájárultak jelen munkám, illetve a kötet alapjául szolgáló Kulcs az SGML-hez című akkreditált tanfolyami jegyzet elkészítéséhez. Köztük kell megemlítenem KORA Andrást, aki a Berzsenyi Dániel Főiskola Könyvtár- és Információtudományi Tanszékének oktatójaként, majd később a Neumann-ház Könyvtár-Informatikai Osztályának vezetőjeként bevezetett az SGML/XML alapú kódolás rejtelmeibe és felkeltette érdeklődésemet a szövegfeldolgozás mint szakterület iránt. Ugyancsak köszönettel tartozom SZALAI Attila szoftverfejlesztőnek, akitől közös projektfeladataink révén szintén rengeteget tanultam különösen a TEI XML alapú szövegkódolás, illetve az XML-re épülő webfejlesztések terén. E könyv nem készülhetett volna el a Berzsenyi Dániel Főiskola Könyvtár- és Információtudományi Tanszékén, illetve a Szegedi Tudományegyetem Könyvtártudományi Tanszékén elsajátított ismereteim, így volt oktatóim és jelenlegi kollégáim tanórai és azon kívüli szakmai és emberi segítsége nélkül. Köszönet illeti MARKÓJA Szilárdot, a Kempelen Farkas Hallgatói Információs Központ könyvtárvezetőjét és BARTAL Tamás szoftverfejlesztőt, akik a kötethez rendelkezésemre bocsátották a HIK Felsőoktatási Digitális Tankönyvtárában alkalmazott DocBook XML formátum magyar nyelvű leírását. Ugyancsak köszönettel tartozom egykori tanáromnak, Dr. SÜTHEŐ Péternek, akinek megjegyzései és javaslatai a könyvet messze használhatóbbá tették, mint amilyen nélkülük valaha is lehetett volna. Köszönet HÁMORY Zsófiának a korrektúráért és nyelvi csiszolatlanságom javításáért, illetve BACSA Andrásnak, a Digitize-IT ügyvezetőjének, volt kollégámnak a tördelésért és a nyomdai előkészítésért. Végezetül hálás vagyok e munka elkészítése alatt tanúsított mérhetetlen megértésért és türelemért családomnak, minden barátomnak, kollégámnak és ismerősömnek. Itt az idő, hogy végre nekik is több időt szenteljek! Örömmel fogadok minden visszajelzést, megjegyzést és javaslatot a könyv esetleges jövőbeni kiadásához a birszab@gmail.com címen. Frissítésekkel, bővítésekkel és javításokkal kapcsolatban ugyanitt lehet érdeklődni. Budapest, februárja Bíró Szabolcs Neumann-ház i

4 Tartalom Előszó... vi 1. Bevezetés A témaválasztás indoklása A kötet célja, feladatai Az anyaggyűjtés forrásai Szakkönyvek Nyomtatott és elektronikus szakfolyóiratok, online források Konferenciák, fórumok, szakmai tapasztalat Jelölésmutató, a szerkesztés elvei Az XML-hez vezető út áttekintés Hardver és szoftverkörnyezet, felhasználók, formátumok Kísérletek a tartalom és forma szétválasztására SGML az XML bátyja Az SGML létrejöttének körülményei Az SGML lehetséges használati területei Az SGML előnyei és hátrányai HTML az SGML gyermeke XML az SGML öccse Az SGML/XML jelölésrendszer kódolás Leíró kontra műveleti jelölés Leíró jelölés Műveleti jelölés Szintaktika SGML/XML Elemek Jelölőkódok Elemnevek Elemek egymásba ágyazása Üres elemek Minimalizálási lehetőségek Attribútumok Attribútumok felépítése Attribútumnevek Attribútumértékek Entitások Az entitásokról általában Entitáshivatkozások Karakterentitás-hivatkozások Beépített entitáshivatkozások foglalt karakterek Megjegyzések Nem elemzett karakteres adatok XML-deklaráció Dokumentumtípus-deklaráció (DTD) A DTD-k szerkezeti felépítése A DTD-kről általában Elem-típus deklarációk Minimalizálási szabályok Tartalmi modell Előfordulási gyakoriság jelzése Sorrendiség, csatolójelek Attribútum-lista deklarációk Attribútum-minimalizálás Attribútum-öröklődés Entitás deklarációk Általános entitások Paraméter-entitások NOTATION deklarációk ii

5 Szövegfeldolgozás XML alapokon 5. Szövegjelölés TEI DTD alapján TEI A TEI alapelvei és előnyei Alapelvek Előnyök A TEI felépítése TEI P5 fejléc metainformációk TEI P5 szövegstruktúra A TEI jövője Szövegjelölés DocBook DTD alapján DocBook A DocBook előnyei A DocBook felépítése DocBook fejléc metainformációk DocBook szövegstruktúra A DocBook jövője A megjelenítésről általában Röviden a megjelenítésről Stílusorientált szolgáltatási formátumok (X)HTML PDF RTF Stíluslapnyelvek DSSSL CSS XSL CSS vagy XSL Stíluslap-kombinációk különböző kimenetekhez Az XHTML Mi is valójában az XHTML Az XHTML létrejöttének okai Az XHTML haszna XHTML típusdefiníciók XHTML dokumentum-sablon Dublin Core kódolás XHTML-be XHTML szabályok Különbségek a HTML 4.01-től Elemhasználati tilalmak Karakterkódolási szabályok Vegyes DTD-k használata XHTML-ben MathML DTD és névtér MathML és SVG DTD, illetve névtér Validitás-vizsgálat XHTML ellenőrzők W3C HTML Validator W3C Link Checker HTML Tidy WAI tippek akadálymentesítés Lépcsős stíluslapok CSS A CSS rövid története CSS szintaktika CSS utasítások felépítése Csoportképzés CLASS szelektor osztályképzés ID szelektor Összekapcsolt szelektorok Pszeudo-osztályok Megjegyzések CSS-ben Betűstílus tulajdonságok Betűcsaládok és általános családok iii

6 Szövegfeldolgozás XML alapokon 3.2. Betűtípus-vastagság Betűstílus Betűváltozatok Betűméret Összetett betűtulajdonságok Szövegstílus-tulajdonságok Betűközök Szóközök Szövegdekoráció Kis- és nagybetűk Szövegigazítás Szövegbehúzás Szöveg előformázása Szövegsorok közti távolság Függőleges szövegelrendezés Egyéb, megjelenést szabályozó tulajdonságok Színek Margók Keretek Kitöltés CSS és XHTML CSS és XML A CSS érvényesség-vizsgálata A CSS jövője XSLT és XPath XSLT XSLT-állományok szerkezeti váza XPath Elérési utak Relatív elérési utak Abszolút elérési utak XML és XSLT Az XSLT jövője A szövegfeldolgozás formátumainak jövője Tárolási, archiválási formátumok SGML XML Megjelenítési, szolgáltatási formátumok HTML vs. XHTML Egyéb, megjelenítésre szánt formátumok Összegzés A. Utószó Irodalomjegyzék iv

7 A táblázatok listája 4.1. Kulcsszavak SGML/XML-ben Bonyolult táblázat v

8 Előszó Az egész a két- és hárombetűs rövidítésekkel kezdődött A Föld nevű bolygón ahol mindez megtörtént, több ezer időegységgel ezelőtt különös létforma ütötte fel fejét. Ezek a szénalapú, majomszerű teremtmények embereknek nevezték magukat, és úgy gondolták, hogy a kommunikáció valami nagyon jó dolog. Időszámításuk szerint követve az eseményeket napjainkra ez odáig fajult, hogy az emberek megpróbáltak minden kezükbe akadó eszközzel kommunikálni. Leginkább két cselekvést végeztek naphosszat: beszéltek és írtak. A beszédhez nem volt szükségük különösebb eszközre, de hamar rájöttek: maradandó nyomot hagyni igazából csak írással lehet. Gépeket alkottak tehát, amelyek adatokat tároltak és közvetítettek a többi ember felé. A kommunikációra különböző nyelveket használtak, az íráshoz jelrendszereket fejlesztettek ki. Szerettek írni. Valaki néhány időegységgel ezelőtt úgy gondolta, milyen jó is lenne, ha az emberek a gyakran használt kifejezéseiket írásban a szavak nagy kezdőbetűivel rövidítenék. Sokan egyetértettek ezzel, és úgy gondolták, ez remek ötlet. Elkezdték hát gyártani a rövidítéseket. Gondosan ügyeltek arra, hogy minden lehetséges kifejezésnek legyen egy rövidített alakja. Sikerrel jártak Később civilizációjuk fejlődéstani szempontból újabb korszakba lépett. Az emberiség egyre lustább lett. Ennek nyomait felfedezhetjük ránk maradt írásaikban. Beszélni szerettek, de amint írásra került a sor, ahol lehetett, rövidítettek. Tőlünk egy egérkattintásnyival nyugatabbra az emberek tehát boldogok voltak. Vidáman, minden probléma nélkül használták a rövidítéseket. Egyedül csak a nyelvészek szomorkodtak. Szerintük ez a folyamat kifejezetten káros volt. Visszaemlékezéseikben halványan feldereng még, hogy a kétbetűsökkel kezdődött minden IC, AI, IO, KB, DB, PS, DC, HF, HQ, IP, IT, és még sorolhatnánk. A nyelvészek a zárójelekhez ragaszkodtak. Minden esetben a kifejezés teljes feloldását zárójelek között, a rövidítések után kell írni, hirdették. IC (Integrated Circuit), IO (Input/Output), IP (Internet Protocol), IT (Information Technology), Ez nem nyerte el egyöntetűen mindenki tetszését, sőt sokan kifejezetten rosszallóan gondoltak az így leírt kifejezésekre. Szegény zárójelek igazán nem értették, hogy miért is kerültek ilyen kellemetlen helyzetbe. A nagybetűk viszont rendkívül hálásak voltak. Csillaguk szépen ívelt felfelé. Büszkén álltak a mondatok közepén, olykor egy-egy mondaton belül többen össze is csoportosultak. Az emberek úgy tartották, hogy ez így szép. Szemük és agyuk is hozzászokott már. Egy szakkönyvben vagy a szaksajtó olvasásakor szemük a csupa nagybetűvel szedett rövidítések között cikázott. A többit át is ugrották, mondván: nem fontos. Később megjelentek a hárombetűs rövidítések, és az emberek ettől kezdve egyre lelkesebbek lettek. BBS, ASP, BPS, BTW, PDA, DAT, DLL, DOS, FAQ, IRC, FTP, FYI, LAN, WAN, ISP, JDK, NAT, NIC, OCR, POP, PPP, RFC, SMS, MMX, SSL, TCP, UDP, UPS, URL, VPN, és így tovább a végtelenségig. Mindez a beszédükben is érzékeltette hatását: Láttad a legújabb CSS ajánlásokat a W3C-től? vi

9 Előszó Hogy állsz a WAP-oldalakkal? WML-ben lehet DSO-t kezelni? Fejlesztettél már XML-ben? Neked melegedik a CPU-d? Láttad volna a PHP oldalamat! Jobb a CGI-s megoldásoknál! PDF-ben dokumentálom. Szerinted is jó, ha CF kártyával bővítem a PDA-m? Átírtam az XSL lapot. Így most szebb lett a HTML kimenet. A SAX-ot használom az eseményvezérelt feldolgozáshoz. Ekkor valaki felkiáltott: No more TLA please! (TLA = Three Letter Abbreviations) Magyarul: Elég a HBR-ekből! (HBR = Három Betűs Rövidítés) Hirtelen súlyos csönd lett, majd kis idő elteltével bekövetkezett a Föld nevű bolygón az igazi katasztrófa: megjelentek a négybetűs rövidítések SGML, HTML, JPEG, XSLT, MARC, HTTP, IMAP, LDAP, IRDA, BIOS, DHCP, FDDI, ICMP, ADSL, MIME, MPEG, NNTP, SMDS, DBMS stb. álltak rendezett sorokban. A nagybetűk örömujjongásban törtek ki, és már a nyelvészek sem szomorkodtak. Beletörődtek a megmásíthatatlanba. Tudták, hogy a folyamat megállíthatatlan és nem ér véget négy betűnél. Igazuk lett. Ez a könyv is ilyen nagy- és sokbetűs rövidítésekről szól London, februárja KORA András Walt Disney Internet Group vii

10

11 1. fejezet - Bevezetés 1. A témaválasztás indoklása A mottóul választott Nemere Istvántól származó idézet és az előszó gondolatmenetén továbbhaladva nyilvánvalóvá válik, hogy a mindennapjainkat behálózó online kommunikáció és az egyre fontosabbá váló digitalizáció világában minden kétséget kizáróan lényeges szempont az adatok, információk hordozhatósága. A különböző operációs rendszereket és böngésző programokat alkalmazó és futtató asztali, illetve hordozható számítógépek, okos telefonok és PDA-k 1, nem utolsó sorban pedig azok felhasználói, egyre jobban megkövetelik, hogy digitalizált dokumentumaink többféle formátumban elérhetővé váljanak számukra. Ennek hatékony, gyors és korszerű megvalósítása azonban több okból sem egyszerű feladat, hiszen sok digitalizálással, szövegfeldolgozással foglalkozni akaró szakember még az adattárolási, illetve megjelenítési formátumok közti különbségekkel sincs tisztában. 2 Mindez persze számos veszélyt rejt magában, így gyakran felvetődnek a gondolatok: Vajon hogyan, milyen kezelhető, értelmezhető, időtálló formában leszünk képesek átadni a jövő nemzedékei számára azt a hatalmas mennyiségű információt, melyet nap mint nap gyártunk s tárolunk? Mi(k) az univerzális csodaformátum(ok)? Kiemelkedően hangsúlyos kérdések ezek, melyekkel a szakma képviselőinek a mindennapok során is foglalkozniuk kell. Éppen ezért tartottuk fontosnak, hogy ebben a kötetben egyrészt a digitalizálás típusdefinícióiból kiindulva kiragadjuk annak egyik legfontosabb részterületét, a szövegdigitalizálást, másrészt az abban alkalmazott legkorszerűbb szövegtárolási formátumokat SGML/XML egyszerű példákon végigvezetve érthetően ismertessük. Ez a könyv egyfajta útikalauz, mely bevezeti olvasóit az XML világába ám mindvégig kitér az SGML-től való lényeges eltérésekre. Ugyanakkor nem csupán azt mondja el, hogy mi fán teremnek és hogyan hozhatók létre ilyen dokumentumok, hanem áttekintést ad jó néhány, környező és a hasznosításhoz nélkülözhetetlen technológiáról is, melyek nélkül korszerű szövegfeldolgozásról manapság már aligha beszélhetünk. A kötet világos, precíz magyarázatai, jól áttekinthető szerkezete mindenkinek segít eligazodni az XML világában. Ennek ellenére leginkább informatikusok, informatikus-könyvtárosok, képző intézmények (egyetemek, főiskolák) oktatói és hallgatói, illetve a szövegfeldolgozás időtálló formátumai iránt érdeklődő szakemberek forgathatják nagy haszonnal. 2. A kötet célja, feladatai Mint azt tudjuk, a nemzeti kulturális örökség digitalizálása alapvető fontosságú társadalmi érdek és megkerülhetetlen állami feladat, mert az információs társadalom mennyiségileg és minőségileg több és gyorsabban megszerezhető információt igényel. Ennek kiszolgálása a kulturális és tudományos stratégiai megfontolásokat állandóan szem előtt tartva elsőrendű feladat, nem beszélve arról, hogy az információhoz való hozzáférés biztosításának egyik legjobb módja a digitalizálás és a digitalizált tartalom szolgáltatása 3 fogalmazták meg téziseikben 2004-ben az országos közgyűjtemények vezetői. Valóban, az elmúlt években Magyarországon is egyre nagyobb számban indultak digitalizálási projektek. Sok szép eredmény mellett állandó hiányként merül fel, hogy rendkívül kevés a digitalizálással értem ezalatt annak összes részterületét foglalkozó magyar nyelvű szakirodalom. A helyzeten némiképp javított, hogy a MINERVA Plus projekt keretében az OSZK MEK Osztálya magyarra fordíttatta a Minerva Good Practice Handbook című kiadványt. A dokumentum minden kétséget kizáróan hiánypótló szerepet tölt be és nagy segítséget nyújt a közgyűjteményeknek, ugyanakkor általános útmutatóként mélységében nem foglalkozik a digitalizálás egyes területeivel így az XML alapú szövegfeldolgozással sem. Összességében tehát kijelenthető, 1 PDA Personal Digital Assistant (személyes digitális asszisztens), gyakorlatilag korlátozott funkcionalitású hordozható tenyérszámítógép. 2 BÍRÓ Szabolcs: Dokumentum digitalizálási módszerek. In: NetworkShop 2005 konferencia anyag. Tutoriálok. Bp.: NIIF, p A közgyűjtemények a nemzeti kulturális örökség digitalizálásában. In: Könyv, könyvtár, könyvtáros, sz. p Sikeres digitalizálás lépésről lépésre 1.2: gyakorlati útmutató (ford.: MEZŐ Zoltán). Bp.: OSZK MEK, [Elektronikus dokumentum.] URL: (A letöltés időpontja: ) 1

12 Bevezetés hogy a jelenleg magyar nyelven hozzáférhető segédletek nem nyújtanak elegendő segítséget a közgyűjteményeknek a sikeres és hatékony gyakorlati munka megvalósításához. Ebből a megállapításból kiindulva ragadtuk ki a szövegfeldolgozást mint szakterületet és közelítettük meg az XML oldaláról. Elsődleges feladatként tűztük ki, hogy az XML alapú szövegfeldolgozás egyes vonatkozásait feltárjuk, ezáltal elősegítendő a területtel kapcsolatban úgy a hallgatók, mint a könyvtáros, informatikuskönyvtáros kollégák körében joggal meglévő kérdések, kételyek és bizonyos fokú homály eloszlatását. Ennek eredményeként az alábbi témakörök elemzésére helyeztük a hangsúlyt: az XML-hez vezető út áttekintés; az SGML/XML jelölésrendszer kódolás; a DTD-k szerkezeti felépítése; szövegjelölés TEI DTD alapján; szövegjelölés DocBook DTD alapján; a megjelenítésről általában; az XHTML; lépcsős stíluslapok CSS; XSLT és XPath; a szövegfeldolgozás formátumainak jövője; A felsorolt területek releváns forrásainak elemzése, majd szintetizálása eredményeképpen a szóban forgó fejezetek reményeink szerint egyfajta taneszközként is használhatóak lesznek az egyes képzési formák megfelelő évfolyamain. A kötet másik nagy feladata, hogy a tárgyalt témakörök érzékeltessék és rávilágítsanak az egyes technológiák sokrétűségére, rugalmasságára, használhatóságára és időtállóságára, illetve előrevetítve egy lehetséges jövőt, következtetéseket vonjanak le azokkal kapcsolat-ban. 3. Az anyaggyűjtés forrásai Mivel emberi léptékkel mérve új technológiákról beszélünk, melyeknek említésre méltó hazai irodalma alig 7 évre nyúlik vissza és az is meglehetősen szegényes, erre nem támaszkodhattunk a kutatás és a könyv írása során. Alapvetően két fő megközelítést tartottunk szem előtt: igyekeztünk az elméleti alapokat feltárni, ugyanakkor különösen nagy hangsúlyt fektettünk a gyakorlati tapasztalatok vizsgálatára is. E kettősség a források felhasználásában egyértelműen nyomon követhető Szakkönyvek Mivel magával a digitalizálással foglalkozó hazai szakirodalom is meglehetősen szegényes, így az sem meglepő, hogy az SGML/XML alapú szövegfeldolgozás területét szintén mostohagyermekként kezelte a szakma. Gyakorlatilag kijelenthetjük: kizárólag SGML/XML alapú szövegfeldolgozással foglalkozó magyar nyelvű szakkönyv nem létezik. Kissé sarkalatosan fogalmazva, a helyzet az, hogy noha néhány helyen hazánkban már 6-7 éve használják az említett technológiákat (Neumann János Digitális Könyvtár és Multimédia Központ Kht. továbbiakban Neumann-ház, Digitális Irodalmi Akadémia továbbiakban DIA), mégsem írtak róla kellő mértékben és igazán használható formában mostanáig. Az első komolyabb előrelépésnek tulajdonképpen ez a Neumann Kht. kiadásában megjelent kötet tekinthető. Alapjául egy 120 órás akkreditált tanfolyam hallgatói tankönyve szolgált, amely a Kulcs az SGML-hez 5 nevet viseli. A könyv elsősorban ezen és Neil BRADLEY XML kézikönyvén 6 alapul bővebben az Irodalomjeyzékből lehet tájékozódni. 5 BÍRÓ Szabolcs KORA András: Kulcs az SGML-hez. Bp.: Neumann Kht., p. [akkreditált oktatási tananyag] 6 BRADLEY, Neil: Az XML-kézikönyv. Bp.: Szak Kiadó, p. 2

13 Bevezetés 3.2. Nyomtatott és elektronikus szakfolyóiratok, online források A nyomtatott szakfolyóiratokban különös tekintettel a Tudományos és Műszaki Tájékoztatásra (TMT) találhatók vonatkozó, szintetizáló jellegű írások, ám ezek többségében néhány, a szakmában tevékenykedő, vagy azt oktató személy tollából születtek. A további objektív vizsgálódáshoz tehát elsősorban angol nyelvű forrásokra kellett hagyatkozni, ami voltaképpen az egyes szakmai közösségek, fejlesztésekért felelős konzorciumok, illetve egyéb témába illő online források tanulmányozását jelentette a legaktuálisabb információk részben mindig így szerezhetők meg Konferenciák, fórumok, szakmai tapasztalat Értelemszerűen információkhoz nemcsak nyomtatott és elektronikus formában juthatunk. Új, friss ismeretek megszerzéséhez kiváló lehetőséget nyújt a szakmai fórumokon, konferenciákon való részvétel, illetve az ilyen irányú személyes kapcsolatok építése. Hazánkban erre leginkább az évente megrendezésre kerülő Networkshop konferencia ad lehetőséget, hiszen figyelemmel kísérhetők az éppen aktuális fejlesztések, illetve jelen vannak a könyvtári és informatikai szakma jeles képviselői. Kiemelnénk még az olyan nemzetközi konferenciák és szakmai közösségek jelentőségét, melyek szintén éves vagy gyakoribb rendszerességgel lehetőséget adnak szakmai tapasztalatcserére. Hogy csak néhányat említsünk ezek közül: European Conference on Digital Libraries, Internet Librarian International, MINERVA és MINERVA Plus rendezvények stb. Végezetül pedig nem hanyagolható el az a gyakorlati tapasztalat sem, amit e kötet szerzője munkája során az SGML/XML alapú szövegfeldolgozás, annak kapcsolódó technológiái, az e-könyvek és ezek oktatása terén szerezett. 4. Jelölésmutató, a szerkesztés elvei Az XML-ben, illetve az ahhoz kapcsolódó technológiákban jelentéssel bíró neveket, kifejezéseket félkövéren szedtük abban az esetben, amikor először jelennek meg a szövegben, vagy amikor szerepüket tovább pontosítjuk. A példákat Courier New betűtípussal szedtük. Amennyiben hosszabb példát közlünk, úgy azokat láthatóan elválasztottuk a szövegtől: Így jelöljük a példákat. A tömörség okán a példák le nem közölt kódrészletei esetében jelölést alkalmaztunk. A jelölés soha nem része a példának! Mivel az SGML és a HTML szintaxisa nagyon hasonlít az XML és az XHTML szintaxisára, ezért a félreértések elkerülése végett megjegyzésben közöljük, hogy éppen milyen kódrészletről van szó. <!-- SGML --> <!-- HTML --> <!-- XML --> <!-- XHTML --> <!-- CSS --> <!-- DSSSL --> <!-- XSL --> <!-- XSLT --> <!-- MathML --> stb. Gyakran előfordul, hogy a példák bizonyos részeit félkövéren kiemeltük, például: <kiemeles tipus="dolt"> Az ilyen megkülönböztetéseknek rendszerint kimeneti oldalról is megvan a párja, így könnyen beazonosítható, hogy az adott jelölés milyen megjelenést eredményez. Ez egy dőlt kiemelés. 3

14 Bevezetés A könyvben több helyen is említést teszünk gyártókhoz kapcsolódó, vagy ingyenes XML eszközökről, mivel az XML-t kezelő alkalmazások rendkívül gyorsan fejlődnek, egyre újabb és újabb termékcsoportok jelennek meg. Sok könyvben elfogultan kiválasztanak néhány eszközt és mindvégig azokról beszélnek. Ezzel szemben mi csak a lehetőségeket és azok alkalmazhatóságát fogjuk bemutatni és a kedves olvasóra bízzuk a választást, ugyanakkor mindvégig feltüntetjük azokat a weblapokat, amelyekről tovább lehet tájékozódni. A könyvben található példákból nem készült CD-ROM és a webről sem tölthetők le. A legtöbb forráskód rövid, kizárólag egy elv, módszer bemutatására szolgál és a gyakorlati alkalmazás megértését segíti. Meggyőződésünk, hogy ezen a szakterületen különösen igaz a mondás: gyakorlat teszi a mestert ha csak mintákat másolunk, kevés ismeret marad meg 4

15 2. fejezet - Az XML-hez vezető út áttekintés Ebben a fejezetben az XML ajánlás létrejöttét befolyásoló és formáló hatásokat vesszük számba, mégpedig anélkül, hogy mélyebb történeti áttekintésbe bonyolódnánk. 1. Hardver és szoftverkörnyezet, felhasználók, formátumok Az egyes adatformátumokban jelentkező probléma fontos tényező, de napjainkig csupán egy szűk kör, a számítástechnikai szakemberek belügye lenne, ha időközben nem találták volna fel a világhálót. 1 A web valóban mindent megváltoztatott, és nemcsak a számítástechnikában, hanem mindenhol a könyvtári világban is! Gondoljunk csak bele, az elmúlt évtizedekben a számítógépes szövegek tárolási és megjelenési módját bizony leginkább a mindenkori műszaki elsősorban hardver lehetőségek határozták meg. Az utóbbi 5 10 évben viszont teljesen átrendeződött a hardverpiac: előtérbe kerültek a hordozható számítógépek (laptop, notebook), s bár még mindig drágák, egyre többen használják őket. Tömegközlekedési eszközökön utazva nap mint nap találkozhatunk kézi számítógépekkel (PDA), és a jövő kommunikációs eszközeinek tekinthető ún. okos telefonokkal, melyek integrálják a PDA-k és a mobiltelefonok minden előnyös tulajdonságát. Információink tehát hordozhatóvá váltak, magunkkal vihetjük őket bárhova, dolgozhatunk velük ezáltal praktikusabban kihasználva az időt. A másik lényeges tényező melyet nekünk, digitális dokumentumokkal foglalkozó könyvtárosoknak soha nem szabad figyelmen kívül hagynunk a szoftverpiac. Ez szintén olyan terület, amely mára hatalmassá nőtt, s melynek eredményeként az előbb említett eszközökön többféle operációs rendszert futtathatunk (Windows, Linux, Mac OS), kereskedelmi és ingyenes programokat használhatunk, aszerint, hogy ki mit engedhet meg magának, mihez ért, vagy netán mit szeret. Következésképpen rengeteg dologra kell odafigyelnünk, ugyanis készülő vagy már meglévő elektronikus/digitális könyvtáraink nagy becsben tartott használói rendkívül sokfélék lehetnek. Őket elsősorban az érdekli, hogy: Megtalálják-e a számukra szükséges információt e-könyvtárunk állományában? Olvashatják-e PDA-jukon a Word RTF vagy az Adobe PDF formátumában Japánról letöltött útikönyvet? Linux operációs rendszeren, Mozilla alatt megfelelően látják-e pl. a HTML-ben letölthető PUKÁNSZKY NÉMETH-féle Neveléstörténet c. pedagógia tankönyvet? Ékezethelyesen kapják-e meg a szövegeket? 2 Minimális követelmény tehát, hogy az internetes formátumok megkapják a megfelelő nyilvánosságot ideális esetben pedig nyílt forráskódúak is lehessenek. Kijelenthetjük azt is, hogy a web két dokumentum publikálásra általánosan használt adatformátuma a HTML (Hypertext Markup Language) és a PDF (Portable Document Format). Az előbbi specifikációja nyílt, bárki szabadon elolvashatja, letöltheti az ajánlást kidolgozó W3C-n 3 kívül nincs olyan szervezet, amely további fejlődését kizárólagosan befolyásolhatná. Ezzel szemben a PDF az Adobe 4 cég tulajdona, s bár a formátum specifikációját a cég közreadta, fejlesztése meglehetősen nagy szaktudást igényel. Ugyanakkor mind a HTML, mind a PDF adatábrázolási formátumok; azt írják le, hogy az adatoknak miként kell festeniük a képernyőn és nyomtatásban. Tudjuk, hogy a PDF kifejlesztésével az Adobe célja az volt, hogy létrejöjjön egy olyan formanyelv, amellyel úgy lehet dokumentumokat formázni, hogy azok mindenhol ugyanolyan méretarányokkal, betűformákkal és tördeléssel jelenjenek meg. Tehát alapvetően megjelenítési, nyomtatáskész formátum. A HTML pedig kifejezetten webes megjelenítésre készült, tele van szórva színt, 1 BATES, Chris: XML: elmélet és gyakorlat. Bp.: Panem Kiadó, p KORA András: Szemben a változással: időtálló fájlformátumok, szövegfeldolgozás, digitalizálás. In: Negyvenéves a szombathelyi könyvtárosképzés. Szombathely: BDF, p World Wide Web Consortium. [Honlap.] URL: A letöltés időpontja Adobe Systems Incorporated. [Honlap.] URL: A letöltés időpontja

16 Az XML-hez vezető út áttekintés megjelenést, formázást leíró utasításokkal nem beszélve az esetleges szkriptnyelvek kódjairól. Mi tehát az oka, hogy időtálló, platformfüggetlen tárolási formátumokként mégsem ezeket szokták emlegetni? A válasz egyszerű: a szóban forgó formátumok nem választják szét a tartalmat a formától noha nem említettük, ugyanez természetesen igaz az RTF (Rich Text Format) állományokra is. Mindez pedig azzal jár, hogy a megjelenítési formátumban tárolt szövegek esetében a metajelek, vezérlőjelek stb. semmit sem mondanak a szöveg tartalmáról, szemantikájáról. A szöveg értelmezésének ugyanis három szintje, megközelítési módja lehetséges: formai (layout), logikai (szintaktikai) és tartalmi (szemantikai). Ez pedig bőven elegendő indok arra, hogy lehetőleg ne használjuk őket tárolási formátumokként, ugyanis az ilyen fájlok hosszú távon a technika/technológia fejlődésével veszíteni fognak értékükből, nem lesznek kompatibilisek a mindenkori értelmező és feldolgozó programokkal, felhasználási lehetőségeik gyakorlatilag nullára redukálódhatnak. 5 Következésképp olyan nyelvre keretrendszerre van szükség, amely kizárólag a tartalom leírására szolgál, a formai jellemzőket nem integrálja magába. 2. Kísérletek a tartalom és forma szétválasztására Az egyik lehetséges tartalomleíró nyelv XML, amely azonban nem egyik napról a másikra bukkant elő a semmiből, hanem a HTML-lel szembeni elégedetlenség hívta életre. Azé a HTML nyelvé, amely valójában nem más, mint az SGML első gyermeke. De mi is az SGML? 2.1. SGML az XML bátyja Az SGML (Standard Generalized Markup Language) szabványos jelölőnyelv dokumentumok belső szerkezetének leírására, beleértve az egyes elemeket jelölő címkék (tag-ek továbbiakban tegek) definiálásának módját is. A Nemzetközi Szabványügyi Szervezet (ISO) által elfogadott nemzetközi szabvány (ISO 8879:1986). Segítségével elvben bármilyen dokumentum leírható, függetlenül az azt tároló és megjelenítő számítógépes környezettől. Az SGML valójában metanyelv, vagyis formálisan, megadott szabályok alapján leírhatunk vele egy másik nyelvet. 6 Az információt annak tartalma, illetve szerkezete alapján jelöli meg, innen származik a jelölőnyelv elnevezés. Tervezésekor az egyik alapvető célkitűzés az volt, hogy az SGML szabályait követő dokumentumok információveszteség nélkül hordozhatók legyenek az eltérő hardver- és szoftverkörnyezetek között Az SGML létrejöttének körülményei A nyelv jelenlegi formáját négy különböző kezdeményezés közös eredményeként nyerte el: 1. Az általános kódolás elmélete Kezdetben az elektronikus dokumentumokat alapszintű jelölőkódokkal, ún. makrókkal látták el. A makrók segítségével egyedi formázást tudtak megvalósítani. Később a beiktatott makrókat, melyeket elsősorban csak a feldolgozóprogramok tudtak értelmezni (pl. format-17 ) közérthetőbb jelölőelemekre cserélték le (pl. heading ). Az 1960-as években New Yorkban egy könyvtervező, Stanley Rice egységesített katalógust tervezett, melyben paraméterekkel szerkesztői szerkezet-elemeket helyezett el. Norman Scharpf, a Graphic Communications Association (GCA) igazgatója felismerte a szerkezetleíró elemek jelentőségét, így új projektet indított el GenCode néven. Az említett projekt tagjai rájöttek, hogy különböző dokumentumokhoz különböző elemeket kell alkalmazni, továbbá, hogy a kisebb dokumentumok beolvaszthatók a nagyobb dokumentumokba. A projekt később a GenCode Bizottság része lett, ami a későbbi SGML munkálatok egyik alapszervezetévé vált. 2. GML és SGML: nyelvek az általános kódoláshoz 1969-ben Charles Goldfarb (IBM) és Edward Mosher, valamint Raymond Lorie kifejlesztették a GML nyelvet. Már a GML-ben megjelent az a kezdeményezés, hogy adott dokumentumhoz egyedi kódolási sémát lehessen definiálni, továbbá, hogy az egyes előre definiált elemek egymásba ágyazhatók legyenek. A GML-t kezdetben ipari szabványként az IBM hatalmas nyomdarendszere alkalmazta. 5 BÍRÓ Szabolcs: A szövegfeldolgozás modern eszközei az SGML és XML nyelvek. In: TMT, 51. köt. 10. sz p SGML (Standard Generalized Markup Language). [Elektronikus dokumentum.] URL: A letöltés időpontja

17 Az XML-hez vezető út áttekintés 3. Az SGML mint nemzetközi szabvány 1978-ban az Amerikai Nemzeti Szabványügyi Hivatal (American National Standards Institute, ANSI) létrehozta a Számítógépes Szövegfeldolgozó Nyelvek Bizottságát. Az SGML első igazán kidolgozott leírása 1980-ban készült el ben az Egyesült Királyságban megalapították az SGML Felhasználói Csoportot, ami szorosan együtt dolgozott az amerikai GCA-val a nemzetközi szabvány kidolgozásán októberében publikálták az első végleges leírást, majd 1986-ban jegyezték be a már említett ISO számmal (ISO 8879:1986). 4. Jelentősebb SGML-alkalmazások a kezdetekben Electronic Manuscript Project of the Association of American Publishers (AAP); Computer-aided Acquisition and Logistic Support (CALS); Az említett projektekről bővebb információt a A Brief History of the Development of SGML Az SGML fejlesztésének rövid története című angol nyelvű weblapról lehet szerezni. 7 Az SGML az 1986-os megjelenését követő 10 évben gyakorlatilag változatlan maradt. Ezzel természetesen lemérhető, hogy kezdetektől fogva milyen erőteljes volt, hiszen egy évtized elteltével is csak kisebb felülvizsgálatokra volt szükség. Sőt megkockáztatjuk, hogy specifikációja talán túl fejlett volt, számos jellemzőjét még ma sem igazán használjuk ki. Fő hátrányát azonban éppen a teljesítménye jelentette, ugyanis még egy, a nyelv valamelyik tipikus részhalmazát támogató szoftver kifejlesztése is hatalmas programozási feladatot jelent. Az SGML-kompatibilis alkalmazások ezért általában lassan készültek el, nem voltak teljesek vagy hibára hajlamosak voltak, ugyanakkor a szabadalmaztatott megoldásokhoz viszonyítva sokba kerültek Az SGML lehetséges használati területei A dokumentálás módja vagy a belső információs rendszer miatt számtalan szervezetnél jelentős összegek tűnhetnek el. Ennek oka, hogy a pénzeket elsősorban olyan feladatokra fordítják, mint a tervezés, az írás, az ellenőrzés, a korrekció, a keresés, a konvertálás, a formázás és a nyomtatás. Ez a folyamat azután minden apróbb termék-, piac- és információváltozásnál újra és újra lejátszódik. A lényeg ami nem más, mint a munkatársak tapasztalata, tudása és észrevételei, egyszóval az információ, amely magát az intézményt versenyképesebbé és sikeresebbé tehetné pedig eltűnik. Eltűnik, mert pusztán kiadványok készülnek jól kezelhető információ helyett. Aki adatfeldolgozással foglalkozik, hamar megtapasztalja, hogy az ismeretlen/idegen, nem dokumentált állományok konverziója mennyire időigényes feladat. A nehézség rendkívüli is lehet, ha például az előállító szoftvernek már a gyártója sem létezik. Gondoljunk csak a régi szövegszerkesztő programokkal készült állományokra! Joggal vetődhetnek fel bennünk a kérdések: Mi a jövő, van-e ezekre a problémákra megoldás? Milyen elvárásaink lehetnek? A megoldás már régóta létezik, hiszen mindmáig ezeket a problémákat igyekszik kiküszöbölni az SGML később látni fogjuk, hogy az XML is, ami olyan technológia, mely a dokumentumok és a bennük foglalt információ felett korábban nem tapasztalt uralmat nyújt, mégpedig páratlanul széleskörű alkalmazhatósága, illetve eszköz- és rendszerfüggetlensége miatt. Az alábbiakban áttekintjük, hogy elsősorban mely területeken célszerű és hasznos az SGML nyelv használata: 1. Szövegdigitalizálási projektek, programok A fejlett számítástechnikai infrastruktúrájú országokban elsősorban az USA-ban, Kanadában, Ausztráliában sok-sok éve folynak szövegdigitalizálási programok. Hazánkban ezek még gyerekcipőben járnak, ám észrevehetően egyre nagyobb a figyelem, az érdeklődés és a tenni akarás a digitalizálás területén, úgy állami, mint intézményi oldalról egyaránt. Többek között éppen ezeknek a fejlesztéseknek az eredményeképpen jött létre közel 20 évvel ezelőtt az SGML szabvány, hiszen a digitalizált szövegek hosszú távú archiválását, visszakeresését és sokoldalú feldolgozását csak ilyen, a hardver- és szoftvereszközöktől független formátum tudja biztosítani. 7 A Brief History of the Development of SGML. [Elektronikus dokumentum.] URL: A letöltés időpontja

18 Az XML-hez vezető út áttekintés Ha a szövegdigitalizálás egyszerűsített folyamatára gondolunk (papírlap szöveggel), digitalizálás (mentés képként), OCR felismertetés (mentés szövegként), a sor végén rögtön felmerül a kérdés: A végeredményt milyen formátumban tároljuk? Melyik ma létező cég formátumát kövessük? (Microsoft: RTF, DOC, Adobe: PDF); Melyik ma létező cég formátumát kövessük? (Microsoft: RTF, DOC, Adobe: PDF); Melyik verziót vegyük alapul? (RTF 1.6, HTML 4.0); Melyik szabványt kövessük? (ISO szabványok, W3C ajánlások); 2. Információkeresés; gépek számára is értelmezhető szövegek Manapság az elektronikus formában tárolt dokumentumokban nagyon nehéz esetenként lehetetlen megtalálni a számunkra fontos információkat, mivel az azokat kezelő szoftverek nem képesek értelmezni az ember számára értelmes szöveget. Amíg nincsenek nagy teljesítményű, majdnem emberi intelligenciával rendelkező számítógépeink, addig kénytelenek leszünk valamilyen módon megjelölni a szoftverek számára az információkat. Erre szolgál többek között az SGML. Vegyük az alábbi példát: A World Wide Web egyik legnépszerűbb keresőgépét, mondjuk a Google-t szeretnénk használni. Keresőkérdésünk igen egyszerű: meg szeretnénk tudni, hogy mi is az a Jáva. Ennek a szónak napjainkban már két értelmezése is ismert: Jáva mint sziget, és Jáva mint programozási nyelv. Milyen eredményeket kapunk, ha csupán az egyszerű Jáva szót adjuk meg? A jelöletlen szövegekben a keresőrobot mindkét értelmezést ugyanolyan értékűnek tekinti, tehát a találati listában szigetként és nyelvként is előfordul majd a Jáva szó. Jelölve viszont különbséget tud tenni közöttük: <sziget>jáva</sziget> <programozasi_nyelv>jáva</programozasi_nyelv> A következő példánk már egy fokkal bonyolultabb. Megpróbálunk egy, a gép számára is értelmezhető szöveget létrehozni. üzenet ahogyan mi, emberek értelmezzük: Feladó: Bíró Szabolcs Címzett: Cziráki Katalin Virág Tárgy: Telefonhívás Üzenet: Hívj fel ma délután! Szabolcs A gép számára is értelmezhető (feldolgozható, kereshető ) üzenet így írható le: <felado>bíró Szabolcs</felado> <cimzett>cziráki Katalin Virág</cimzett> <targy>telefonhívás</targy> <uzenet>hívj fel ma délután!</uzenet> <alairas>szabolcs</alairas> 3. Dokumentumok újrahasznosítása Dokumentumaink újrahasznosításának nem csak a különböző formátumok szabnak gátat, hanem a dokumentációhoz rögzített megjelenítés is. Hiszen egy cég minden munkatársa másként formázza meg az adott szöveget. Így ha több dokumentumból szeretnénk egy új dokumentumot létrehozni, a különböző forrásból származó részekről el kell távolítani a formázási stílusjegyeket, majd az egész dokumentumot újra kell 8

19 Az XML-hez vezető út áttekintés formázni. Az SGML nyelv azonban ezt a problémát is kiküszöböli, mégpedig azáltal, hogy a dokumentumok formai jellemzőit mindig egy, az SGML állományokon kívüli fájlban tárolja. Tehát a tartalom és a forma szétválik! Azok, akik mindennapi munkájuk során számítógépet használnak, tudják, hogy egyre-másra jelennek meg és tűnnek el a különböző szövegszerkesztő programok, újabb és újabb verziók kerülnek piacra, amelyek egyre többet tudnak, s gyakorlatilag nyomdai minőségű kiadványokat készíthetünk velük. Valójában azonban ezek a programok olyanok, mintha hatalmas tudással felvértezett elnyűhetetlen szövegszerkesztők írógépek lennének. Ennek oka, hogy mesterien megformált oldalakat készíthetünk velük újabban a konkurens, vagy az adott szerkesztőprogramtól független formátumokba is mentési lehetőséget kínálnak, de másra nem alkalmasak. Az adatbázis-kezelők tartalomcentrikus filozófiájával szemben az irodákban ma fellelhető szövegszerkesztők mind a megjelenítésre összpontosítanak. Büszkén a What You See Is What You Get (WYSIWYG) névvel jelölik őket, melynek jelentése: Amit látsz, azt kapod. A mottó is arra utal, hogy ezekben a szövegszerkesztőkben a külső a fontos, hogy egyszerűen és gyorsan nyomtatni lehessen a dokumentumot. Nem törődnek a dokumentumban lévő tartalom és a szövegben található struktúra felhasználásával. A probléma tehát abban rejlik, hogy a létrehozott állományok csak arra használhatók hatékonyan, amire készültek, vagyis a szöveg oldalakon való megjelenítésére, ráadásul általában csak annak a gyártónak a szoftverével, amivel készültek. Más gyártmányú szoftver, sőt sok esetben az azonosnak egy másik verziója is problémát okoz. Emlékezzünk csak, hányszor volt abból gond, ha egy újabb verziójú Wordben megírt dokumentumot valahol máshol, egy régebbiben akartunk megnyitni! De, hogy az említett program más gyártmányú szoftverekkel való kompatibilitási problémáira is rámutassunk, nagyon jó példa a Word XP és az OpenOffice esete. Ezt a könyvet az előbb említett programmal készítettük és formáztuk, ám az utóbbiban megnyitva formailag éppen a tartalmi rész és a formázási utasítások egy fájlban való tárolása miatt nehezen használható és sokhelyütt szétesik. [Megj.: A szövegszerkesztő programok által nap mint nap kezelt adatmennyiség gigantikus. Sok százmillió oldalt kitevő tudásanyag van beágyazva egy-egy szoftvergyártó cég saját, állandóan változó, alig dokumentált, oldalszemléletű, tipográfiai utasításokkal teletűzdelt formátumaiba. Ellentétben az adatbázis-kezelő rendszerekkel, az ilyen szövegszerkesztő szoftverekben a gépi felhasználás szempontjából nézve elvész az információ és lehetetlen, vagy meglehetősen nehézkes újrahasznosítani a bennük rejlő tartalmat.] Az említett, nagyon is valós problémákat látva/tapasztalva jó tudni, hogy az ellenszer ami nem más, mint az SGML nyelv már jó ideje létezik, rendelkezésünkre áll és sokan használják is! [Megj.: Nem véletlen, hogy 2005 első felében a Microsoft is bejelentette: szövegszerkesztőjének 2006-ban megjelenő változata már az SGML egyszerűsített változatát, az XML nyelvet fogja használni belső formátumként.] Az SGML előnyei és hátrányai Az alábbiakban összegyűjtöttük, hogy a dokumentum-feldolgozáshoz választott tárolási formátumunkkal, az SGML-lel szemben milyen igényeket támaszthatunk ezek gyakorlatilag lefedik a nyelv használatának előnyeit is. A felsorolásból világosan látható lesz, hogy mennyiben több az SGML, mint a szövegszerkesztők által felkínált, mindennapjainkban használatos formátumok. (A nyelv természetesen megfelel az alábbi igényeknek.) 1. Legyen az információ a továbbiakban információ alatt szöveges információt értünk tárolására általánosan elfogadott, dokumentált, gyártófüggetlen a szabvány. 2. A szóban forgó szabványnak legyenek alkalmazott területei, referenciái, melyek adott esetben átültethetők más projektekbe is. 3. Az információ szerkezete legyen tervezhető. Legyen olyan elfogadott szabvány, amellyel az ember és a gép számára le lehet írni az információ szerkezetét. 4. Meg lehessen jelölni a felhasználás számára lényeges elemeket. 5. Az információ legyen számítógéppel könnyen feldolgozható, a könnyű és gyors feldolgozhatóság viszont ne függjön az alkalmazott számítógépes platformtól. 9

20 Az XML-hez vezető út áttekintés 6. A tárolt információ legyen sokoldalúan újrafelhasználható, azaz hordozza magában a más formátumokba való konverziós lehetőséget. 7. A tárolt információ legyen hordozható, vagyis bármilyen számítógépes környezetben használható. 8. A választott tárolási formátum révén a kívánt információt gyorsan, pontosan meg lehessen találni. 9. Végezetül pedig, az alkalmazandó technológia rendelkezzen biztos és használhatóságát alátámasztó múlttal, illetve egy olyan kiszámítható jövőképpel, amely további alkalmazását sem kérdőjelezi meg. Az SGML használatának azonban nemcsak előnyei, hanem hátrányai is vannak, amikkel nem árt tisztában lenni: 1. A nyelv alkalmazása kissé bonyolult nehezen integrálható, mivel egy SGML dokumentum nem csak egyetlen fájlból áll. Értelmezéséhez szükség van egy dokumentumtípus-definíciót tartalmazó fájlra is. Ez a DTD-t tartalmazó fájl. Szükség lehet egy speciális stíluslapra is. Ezt egy XSL fájl tartalmazhatja. 2. Körülményes, speciális terjesztés, hiszen egységes formában feldolgozott dokumentumokat csak egységes, közös DTD-vel készíthetünk. 3. Bonyolultságából adódóan speciális szaktudást igényel. Egyszerűsített formája az XML igen népszerű, de ezeknek a szabványoknak megismeréséhez sok idő és alapos háttértudás szükséges. 4. A teljes körű SGML-feldolgozó szoftvercsomagok meglehetősen drágák. Kevés a jó szakember, ami szintén drágítja az SGML-alapú technológiák alkalmazását. 5. Manapság a legtöbb szoftvert, feldolgozó alkalmazást már nem az SGML-hez, hanem annak utódjához, az XML-hez fejlesztik HTML az SGML gyermeke Az elmúlt 10 esztendőben mindnyájan tapasztalhattuk, az internet az információ-visszakeresés és -csere alapvető médiumává vált, s mint a hypertext szolgáltatás természetes platformja, a világ különböző részein lévő dokumentumokat az információ világméretű hálójává (World Wide Web) kapcsolta össze. Sokan nem tudják, de a HTML jelölőnyelvet az említett rendszer igényeinek kielégítésére fejlesztették ki, mégpedig az SGML nyelvből. Így nagymértékben átvette annak szintaxisát, ám elveit nem, éppen ezért csak később lett kompatibilis és ekkor lehetett SGML alkalmazásként leírni DTD-vel definiálni. Bár a HTML fejlesztéséért és karbantartásáért a W3C felelős, kezdetben a jelentős böngészőgyártók mégis saját elemeket adtak hozzá a versenyelőny megszerzése érdekében, ezzel jelentős zavart okozva a megjelenítésben. A HTML legfőbb hátránya azonban mégis az, hogy nem biztosít olyan mechanizmust, amely lehetővé tenné, hogy a szövegfeldolgozók a saját jelölőelemeiket hozzáadva kiterjeszthessék a nyelvet, nem beszélve a tartalom és a forma integrációjának problematikájáról XML az SGML öccse Az SGML bonyolultsága és ismertetett hátrányai, illetve a HTML lezártsága és megjelenítés-orientáltsága miatt 1996-ra a szövegjelölés területének több szakértője úgy gondolta, elérkezett az idő az SGML egyszerűsített verziójának létrehozására, amely a nagyközönség számára vonzóvá tenné az általánosított jelölés megközelítését. Mivel az egyszerűsítésre irányuló törekvések éppen egybeestek a HTML fejlesztésére irányuló nyomással, a W3C egy gyökeresen új tartalomleíró felépítésébe kezdett, melyhez értelemszerűen az SGML szolgáltatta az alapot. A tervezési munka 10 olyan cél definiálásával kezdődött, amelyet az új nyelvnek kötelezően ki kellett elégítenie. A következőkben áttekintjük az egyes célokat, és véleményt mondunk azok specifikáció szerinti megvalósulásáról: 8 1. Könnyű használhatóság 8 BRADLEY, Neil: Az XML-kézikönyv. Bp.: Szak Kiadó, p

21 Az XML-hez vezető út áttekintés Az XML-nek nyíltan használhatónak kell lennie az interneten keresztül. Ennek érdekében szándékosan nem vett át bizonyos SGML-ből származó HTML konvenciókat, hogy a lehető legegyszerűbben lehessen áttérni az XML-re és DTD nélkül is alkalmazható legyen. A cél megvalósult. 2. Széles körű alkalmazhatóság Az XML-nek sokféle alkalmazást kell támogatnia. Az XML széleskörű információ leírására alkalmas: strukturált adatbázismezők, félig strukturált közzétételi anyagok, információ-szolgáltató technológiák, kliensoldali feldolgozás, dokumentum-feldolgozás, több médián való közzététel. Az ajánlás megjelenését követő 3 éven belül az XML már elterjedt, alapvető technológiává vált, azóta pedig mindez csak fokozódott a cél tehát megvalósult. 3. SGML kompatibilitás Az XML-nek kompatibilitást kell mutatnia az SGML-lel. Az XML-t a nagy testvér részhalmazaként definiálták néha bizony az egyszerűség csorbítása árán, így az feldolgozható SGML eszközök segítségével is. Ha mégis netán olyasmit fedezünk fel, hogy az XML nyelv adott részlete felesleges, vagy nem oda tartozó, az mindig azért van, hogy a visszafele-kompatibilitás megvalósulhasson. Tehát a kitűzött cél ebben az esetben is teljesült. 4. Könnyű támogathatóság Könnyen lehessen XML feldolgozó programokat írni. Bár a következő fejezetben szereplő példákban látni fogjuk, azért előrevetítjük, hogy az SGML és az XML közti fő különbség a minimalizálás és más opciók eltávolításában rejlik, valamint a fennmaradó jelölések formátumára vonatkozó szigorúbb szabályokban. Ebből adódik, hogy XML-hez könnyebb feldolgozót fejleszteni, mint SGML-hez kevesebb variánssal kell számolni a szintaxisban. A cél tehát megvalósult, ugyanakkor az új XML szintaxisú ajánlások névterek 9, sémák 10 stb. megjelenésével ez az előny vélhetően csökkenni fog, hiszen nagy nyomás, igény van ezek támogatására is. 5. Korlátozott opcionális lehetőségek Az XML-ben az opcionális lehetőségek számát abszolút minimumon, lehetőleg nullán kell tartani. Ha abból a szemszögből vizsgáljuk a dolgot, hogy XML-ben ugyanazt a hatást szemben az SGML-lel ritkán lehet többféle módon elérni, akkor a cél teljesítettnek tekinthető. Más oldalról nézve viszont egy XML állomány elemkészlete annak összes jellemzőjével együtt akár szabadon választható is lehet, így viszont a cél teljesülését már nehéz felbecsülni. Ettől függetlenül észrevehetjük, a célkitűzés szorosan kapcsolódik a 4. pontban megfogalmazotthoz. 6. Érthetőség és emberek általi olvashatóság Az XML dokumentumoknak az emberek által olvashatónak, érthetőnek kell lenniük. Mivel az XML az SGMLen, vagyis egy ASCII 11 szövegformátumon alapuló ember által is olvasható jelölőnyelven alapszik és nem rendelkezik minimalizálási jellemzőkkel lásd 10. pont, a cél egyértelműen megvalósult. 7. Az XML-szabvány gyors fejlesztése Az XML tervezésének gyorsan kell végbemennie. Figyelembe véve, hogy a fejlesztés 1996 közepén kezdődött és az XML 1.0 első elfogadott ajánlása 1998 februárjában jelent meg, mindenki eldöntheti, hogy gyors volt-e a munka vagy lassú. Mielőtt döntünk, azért vegyük figyelembe, ennyi idő kell egy új ajánláshoz még akkor is, ha csak a már meglévő SGML-t kellett egyszerűsíteni. 8. Formális és tömör tervezés 9 A névtér (namespace) valójában olyan környezet, melyben minden elem és attribútum neve garantáltan egyedi. Egy DTD definiál egy névteret, ám ha a dokumentum több DTD-ből vagy sémából használ elemeket, akkor jelentkezik a névtér probléma. Namespaces in XML. [Elektronikus dokumentum.] URL: A letöltés időpontja A séma (schema) valójában a dokumentumszerkezet definíciója, beleértve az egyes attribútum-értékekre tett megkötéseket és az elemek közti kapcsolatokat. Funkcionalitásában hasonló a DTD-hez, ám felépítésében azzal ellentétben XML alapú és gépi automatizmusok számára potenciálisan hatékonyabb. Több séma-szabvány is létezik, ám a legszélesebb körben az XML Schema támogatott. 11 Az ASCII (American Standard Code for Information Interchange amerikai szabványos információ-csere kód). Az ASCII karakterkészlet 128 db hétbites kódot tartalmaz, mindegyikük egy egyedi karaktert reprezentál. A 8 bites ASCII, két karakter kivételével tartalmazza az összes magyar ékezetes karaktert is. A két hiányzó karakter a hosszú ő és ű. HTML ASCII Reference. [Elektronikus dokumentum.] URL: A letöltés időpontja

22 Az XML-hez vezető út áttekintés Az XML tervezésének formálisnak és tömörnek kell lennie. Mivel a nyelvet olyan szabálykészlettel hozták létre, amely megfelel a formális nyelvtannak, így a cél teljesült. 9. Dokumentumok könnyű létrehozhatósága Könnyen lehessen létrehozni XML dokumentumokat. Az egyszerű ASCII-exportra képes programok Jegyzettömb, TextPad, jedit, EditPlus stb. segítségével már előállíthatunk XML állományokat; és akkor még nem ejtettünk szót az olyan XML szerkesztőkről, mint az XMLSpy, oxygen stb., ezért egyértelműen kijelenthetjük: a cél teljesült. 10. Lényegtelen a minimalizálás Az XML jelölésben a tömörségnek minimális jelentősége van. Az SGML nyelv sok olyan választható jelölőelemet tartalmaz, amelyet adott esetben a szövegjelölést végző személy elhagyhat a munka során a dolognak történeti okai vannak, lásd.: Minimalizálási lehetőségek c. alfejezet. Ez nem jelent problémát, hiszen az SGML feldolgozó szoftverek a környezetből ki tudják következtetni a jelölés meglétét. Jól tudja mindenki, hogy a HTML-ben is kihagyhatók bizonyos jelölők záró részei, például a </li>; </p> anélkül, hogy ez problémát okozna a böngészőknek. Nos, az XML nem rendelkezik ilyen minimalizálási jellemzőkkel. Minden jelölőelemnek jelen kell lennie, hiszen ez segíti elő a 4. célt, sőt a modern XML szerkesztők is csak így teszik lehetővé, hogy ne kelljen begépelnünk a jelölőkarakterek lezáró részét. A kitűzött cél tehát tökéletesen megvalósult. Most már tudjuk, hogy az XML két létező nyelv, az SGML és a HTML konvencióira és elveire épül, hogy ezáltal egyszerű, ugyanakkor mégis hatékony mechanizmust hozzon létre az információk feldolgozására, tárolására, illetve szolgáltatására. Ez az a formátum, amely meg fogja menteni a digitális világot vallják sokan, és igazuk lehet, hiszen amellett, hogy az XML levetette elődje hátrányos tulajdonságait és megvalósította a tartalomleírás követelményeit, egyúttal nemcsak dokumentum-, hanem alkalmazásorientált is lett. A fejezet summázataként az alábbi időskálát is tartalmazó ábrán mutatjuk be az egyes formátumok létrejöttét, tükröztetve azok egymásra hatását: 12 A jelölőnyelvek fejlődése napjainkig 12 BRADLEY, Neil: Az XML-kézikönyv. Bp.: Szak Kiadó, p

23 3. fejezet - Az SGML/XML jelölésrendszer kódolás Mielőtt az XML ismertetésébe kezdenénk, tisztáznunk kell, hogy a nyelv nem programozási nyelv sokan tévesen ezt feltételezik, emiatt gyakran hallani az XML-programok kifejezést a helyes XML-struktúrák helyett tehát jelölésrendszerének elsajátítása senki számára nem okozhat különösebb nehézséget, bár a HTML nyelvet ismerőknek egy merőben új szemléletet kell megtanulniuk. Az XML jelölésrendszer egyes részeinek bemutatásakor igyekszünk kitérni azokra a különbségekre is, melyek az SGML-lel szemben tapasztalhatók. Ugyanakkor már most felhívjuk a figyelmet arra, hogy a kötet keretei nem engedik meg az említett különbségek teljes körű ismertetését és részletes taglalását, így kénytelenek vagyunk a lényegesebb összetevőkre szorítkozni. 1. Leíró kontra műveleti jelölés Akik szövegjelöléssel foglalkoznak, tudják, hogy alapvetően két nagy jelölésrendszert különböztethetünk meg. Az egyik a leíró, a másik pedig a műveleti jelölés. A következőkben az e kettő közti különbségekre igyekszünk rávilágítani, hiszen leginkább így válhat egyértelművé, miben rejlik az SGML, s még inkább az XML ereje Leíró jelölés Az SGML és az XML leíró jelölést alkalmazó jelölőrendszer, vagyis olyan jelölőkódokat használ, amelyek nevekkel azonosítják (kategorizálják) a dokumentumok bizonyos részeit. Az olyan jelölőkódok, mint például <cim> vagy <bekezdes> csupán a dokumentum bizonyos részeinek azonosítására szolgálnak, és mindössze annyit jelentenek, hogy a következő elem egy cím, vagy most egy bekezdés következik. Az SGML/XML nyelvben a dokumentumok bizonyos célú feldolgozásához pl. formázott megjelenítéséhez szükséges utasítások élesen elválnak a dokumentumban található leíró jelölésektől, rendszerint a dokumentumon kívül, külön eljárásokban vagy programokban találhatók lásd.: A megjelenítésről általában c. fejezet. Ez azt jelenti, hogy ha például az SGML/XML állományainkat a weben HTML formátumban szeretnénk megjeleníteni, akkor készítenünk/írnunk kell egy feldolgozó programot, amely értelmezi a fájlokban használt jelölőelemeket, majd azokat a meghatározott formázási utasításokkal látja el. Ebből viszont az is következik, hogy a leíró jelölés használatával ugyanazt a dokumentumot többféle programmal is feldolgoztathatjuk, amelyek mindegyike akár más és más utasítást hajthat végre a dokumentum megfelelő részein. Például egy tartalmi elemző program teljes mértékben figyelmen kívül hagyhatja a szövegbe ágyazott lábjegyzeteket, viszont egy tördelőprogram összegyűjtheti őket és együtt, a fejezet végén jelenítheti meg azokat. Az is elképzelhető, hogy ugyanazt a szövegrészt különböző programok másként dolgozzák fel. Például az egyik kigyűjti a személy- és helységneveket és létrehoz egy bibliográfiát vagy helységnévmutatót, a másik pedig ugyanabban a szövegben a személy- és helységneveket vastag dőlt betűkkel látja el. Mindez nagyon jól hangzik, ám nem hagyhatjuk figyelmen kívül, hogy feldolgozó programjaink csak akkor képesek végrehajtani a fentebb említett utasításokat, ha a leíró jelölést tartalmazó SGML/XML dokumentumainkban a megfelelő jelölőelemeket használtuk. Nem várhatjuk el, hogy programunk kigyűjtse a személyneveket, vagy a dokumentum végén jelenítse meg a lábjegyzeteket, ha nem úgy kódoltuk őket, hogy pl. a személyneveket <szemelynev>...</szemelynev>, a lábjegyzeteket pedig <labjegyzet>...</labjegyzet> jelölőelemek közé tettük Műveleti jelölés A műveleti jelölést alkalmazó jelölőrendszer azt határozza meg, hogy milyen utasításokat kell végrehajtani a dokumentum meghatározott pontján: a dokumentum címe legyen 14 pixel nagyságú, félkövér és Verdana betűtípusú, vagy a bekezdés első sorát 12 mm-rel kezdjük beljebb, majd a szövegben szereplő idézeteket szedjük dőlttel, a bekezdés vége után pedig álljunk az új bekezdés elejéhez. Vegyük észre, tulajdonképpen ez a jelölésmód bújik meg a HTML dokumentumok forráskódjában is, hiszen a HTML nyelvnél a jelölőelemekben adjuk meg, hogy a bennük/közöttük lévő tartalom milyen formát öltsön, ha egy böngészőprogramban megnyitjuk. A módszer nagy hátránya, hogy használatakor a tartalom és a forma 13

24 Az SGML/XML jelölésrendszer kódolás keveredése miatt részben vagy teljes egészében elveszítjük dokumentumunknak azt a hasznos tulajdonságát, hogy abból egy hozzá írt feldolgozó segítségével szinte bármilyen információ kinyerhető. [Megj.: Logikusan szerkesztett HTML állományokhoz lehet olyan feldolgozót írni, amely XML-lé alakít vissza és az egyes szövegegységeket értelmes jelölőelemekkel látja el. Persze ez korántsem egyszerű, és eltérő forráskódú HTML állományok esetében teljesen nem is automatizálható.] 2. Szintaktika SGML/XML Az SGML/XML filozófiája szerint a dokumentum leírásakor nemcsak annak formai jegyei lényegesek, hanem a szöveg értelmi tagolása is. Ha például egy dokumentumban valamely könyv legfontosabb bibliográfiai adatait szeretnénk leírni, akkor abban biztosan szerepelni fog annak szerzője, címe, kiadója, kiadási helye és kiadási éve. Azt, hogy miként fog kinézni mindez, ha SGML/XML szintaktika szerint végezzük el a szövegjelölést, az alábbi forrás mutatja: <konyv> <szerzo> <vezeteknev>petőfi</vezeteknev> <keresztnev>sándor</keresztnev> </szerzo> <cim>petőfi Sándor összes költeményei</cim> <kiado>szépirodalmi Könyvkiadó</kiado> <hely>budapest</hely> <ev>1955</ev> </konyv> Megfigyelve a példát, több észrevételt is tehetünk. Látható, hogy a kódban szereplő elemneveinkben nincsenek ékezetes karakterek ennek oka, hogy az egyes platformok közötti tökéletes hordozhatóság garantálása csak 7 bites ASCII karakterek használatával oldható meg. [Megj.: Ettől függetlenül a nyelv lehetőséget nyújt ékezetes karakterek használatára elemnevekben. Ugyanakkor tudnunk kell, hogy az ékezetek használatának nincs sok értelme a jelölés során, hiszen a jelölőelemek beszédességüket azok nélkül sem veszítik el.] A forrásból az is jól látszik, hogy az elemnevek párokban fordulnak elő, relációs jelek határolják őket, sőt egyértelmű, hogy ugyanezeket az információkat HTML-ben egyáltalán nem lehetne értelmileg tagolni. De mik azok az elemek és miért párokban láthatók? Miért éppen relációs jelek határolják őket? 2.1. Elemek Az SGML/XML dokumentumok alapvetően elemekből épülnek fel az SGML szabvány és az XML ajánlás a szövegegységek mint szerkezeti összetevők megnevezésére egyaránt az elem (angolul: element ) szakszót használja. Az elemek a dokumentumnak azok a szerkezeti egységei, amelyek jelölőkódokkal vannak körülvéve, így utalnak arra, hogy a rendszer hol érzékelje az adott elem határait: az elejét és a végét. Hangsúlyoznunk kell, hogy az SGML/XML nyelvben a szövegegységek jelentése szemantikája teljességgel érdektelen, csakis az alkalmazástól függ. Gondoljunk csak bele, mekkora szabadság ez a hagyományos jelölőnyelvekkel szemben! Itt az adott alkalmazásban kialakítandó elemkészlet létrehozójára van bízva, hogy elemeinek beszédes, érthető nevet ad-e, és megfelelőképpen dokumentálja használatuk módját a szöveg jelölése/strukturálása során. Nyilvánvaló, hogy nem teljesen ugyanazokat az elemneveket használjuk, ha drámai szövegeket, vagy például verseket dolgozunk fel, hiszen mindkettő más szövegegységekből épül fel. Egy strukturált, vagyis különböző szerkezeti elemekből felépülő dokumentumban akár ennek a könyvnek a szövegét is vehetjük példának valamilyen módon minden szerkezeti elemet világosan jelölnünk, tagolnunk kell. Például egy lehetséges módszere ennek, hogy a fejezetcímet nagyobb betűvel írjuk a folyószövegénél, sőt félkövéren is szedjük, hogy jobban kiemelkedjen. A tartalmilag elkülönülő szövegrészeket új alfejezetként, a megjegyzéseket pedig lábjegyzetben vagy a szövegben megkülönböztetve közöljük stb. 14

25 Az SGML/XML jelölésrendszer kódolás Valójában tehát kimondhatjuk azt, hogy a jól strukturált szöveg elrendezése az anyag hierarchikus és szisztematikus kifejezését is tükrözi. Ugyanez természetesen igaz az SGML/XML-re is, ám azzal a különbséggel, hogy a feldolgozott szöveg magától a jelölőkódokkal körülvett jelölőelemektől tegeléstől lesz strukturált, vagyis jelölt. [Megj.: Ebben az értelemben a teg egy elem kezdetét vagy végét jelöli, a tegelés pedig valójában a szöveg jelölőkódokkal körülvett elemekkel való ellátását, strukturálását, tehát a leíró jelölés definíciója szerint a tartalmi elemekre bontását, tagolását jelenti.] Jelölőkódok A jelölőkód kifejezést a jelölőelemet körülvevő karakterek megnevezésére használjuk. A jelölőkódok karaktereit angol megnevezésekkel és magyar megfelelőikkel így írhatjuk le: < STAGO (Start Tag Open) = a kezdő jelölőelem nyitó eleme > STAGC (Start Tag Close) = a kezdő jelölőelem záró eleme </ ETAGO (End Tag Open) = a befejező jelölőelem nyitó eleme > ETAGC (End Tag Close) = a befejező jelölőelem záró eleme A hordozóelemek felépítése A kezdő és a befejező/záró jelölőelem magával a közte lévő szöveggel elemtartalom együtt alkotja a hordozóelemet. Pusztán érdekességképp jegyezzük meg, hogy az SGML nyelv lehetőséget biztosít a 2. ábrán bemutatott jelölőelemek egyébként mindkét nyelvben alapértelmezett nyitó és záró karaktereinek átdefiniálására. [Megj.: Az átdefiniálás más határérték-beállításokkal együtt rendszerint az sgml.def és a *.dtd állományokban végezhető el.] Ennek eredményeként például egy szövegben szereplő bekezdés a következőképpen is kinézhet: <bekezdes>alapértelmezett elemjelölő karakterek SGML/XML-ben.</bekezdes> <!-- SGML --> //bekezdes??átdefiniált elemjelölő karakterek, kizárólag SGML-ben.!!bekezdes?? Elemnevek Mivel sem az SGML, sem pedig az XML nem definiál előre elemneveket, ezért amikor SGML/XMLalkalmazásról beszélünk, akkor a jelölőnyelv olyan használatát vizsgáljuk, melyhez számos elemet definiáltunk. 15

26 Az SGML/XML jelölésrendszer kódolás Ezért mondhatjuk, hogy a HTML valójában SGML-alkalmazás, a WML vagy az XHTML pedig XMLalkalmazás. Az elemnevek hossza nincs korlátozva, persze nyilvánvalóan legalább egy karakterből kell állniuk. A névben megengedett karaktereket illetően azonban annál inkább vannak megszorítások. Minden elemnévnek betűvel, alsó vonással ( _ ), vagy kettősponttal ( : ) kell kezdődnie bár ez utóbbira ismét léteznek korlátozások. Az elemnév tartalmazhat számjegyeket, pontot (. ) és kötőjelet ( - ) is, ennélfogva érvényes elemnévnek tekinthető pl. a <P>, az <N:112> vagy <barmiegyebhosszunev>. Nagyon fontos viszont, hogy egyetlen elemnév sem tartalmazhat ún. whitespace 1 karaktereket. Ha szövegfeldolgozásba kezdünk és saját jelölésrendszert akarunk kialakítani 2, akkor a következőkre mindenképp oda kell figyelni: 1. Kisbetűk és nagybetűk Mivel az XML elemnevei egyaránt kis- és nagybetű érzékenyek SGML esetében nincs ilyen, ezért legnyilvánvalóbb a vagy csupa <kisbetűs>, vagy csupa <NAGYBETŰS> elemnévhasználat. A kisbetűk azért jobbak, mert egyrészt könnyebben olvashatók, másrészt tömörített dokumentumok esetén kisebb fájlméretet eredményeznek ennek oka a szóelőfordulással magyarázható. A vegyes alkalmazásnak viszont az a nagy előnye, hogy összetett elemnevek esetén tisztábban elkülöníthetők a név egyes részei, pl. <KepLeiras>; <KépLeírás>. 2. Szoftveres hagyományok Feldolgozásra szánt programok esetén gyakori az a megközelítés, hogy az elemeket ugyanúgy nevezik el, mint ahogy azok értékeit a memóriában tárolják. Példával illusztrálva: String intézménynév = Neumann-ház ; <intézménynév>neumann-ház</intézménynév> 3. HTML és XHTML örökség Egy másik általánosan elterjedt módszer szerint, ha nem muszáj, akkor ne találjunk ki új elemneveket, használjuk a HTML jelölőelem elnevezési hagyományokat. Több jelenleg is érvényben lévő szabvány vette alapul a HTML jelölésrendszerét és hagyta el belőle a szükségtelen elemeket, illetve vette fel a kívánatosakat WML 3, OEB 4. A módszer előnye, hogy az egyes elemnevek jelentésével mindenki tisztában van, ráadásul HTML2XML átalakítások 5 és szöveges tartalom beemelések is kevés bajlódással megoldhatók. 4. Elemnévhossz A névhosszúság megállapításakor két alapvető szempontot kell figyelembe vennünk. Az egyik az, hogy neveink önleíróak/beszédesek legyenek, ami egyúttal a hosszabb névhasználat szükségességét sugallja. Nyilvánvaló, hogy az <intézménynév> sokkal többet mond, mint az <in>. Ennek a szemléletnek viszont az a hátránya, hogy a hosszú nevek nagyobb fájlméretet eredményeznek. Köztes és egyben gyakorlatias megoldásként szolgál, ha a gyakran használt elemeket rövid névvel illetjük, a ritkán előfordulókat hosszabbakkal. Valahogy úgy, mint a HTML nyelv, ahol a <p> rövid jelölőelem és bekezdésre utal, ám a <textarea> hosszabb és a ritkán használt szövegdoboz jelentése. 5. Következetesség A felsorolt konvenciók közül bármelyiket is választottuk, nagyon fontos, hogy konzekvensen azt alkalmazzuk. A modell megbízhatóságát ugyanis könnyen megkérdőjelezi, ha annak alkalmazott jelölésrendszere nem, vagy csak kismértékben konzekvens. Nagyobb gyűjtemények, szövegtárak kialakításakor ezért célszerű 1 Whitespace (térköz) a szöveg szavainak és a jelölés paramétereinek elkülönítésére szolgáló karakter, beleértve a szóköz, tabulátor és a sorvégjel CF, LR karaktereket is. 2 Természetesen kisebb gyűjtemények kialakításakor ez is előfordulhat, különösen akkor, ha nincs meg a kellő háttértudás nemzetközileg is elismert jelölésrendszerek alkalmazásához. 3 WML (Wireless Markup Language vezeték nélküli jelölőnyelv), melyet a WAP használ. 4 OEB (Open Electronic Book nyílt elektronikus könyv) szabvány, melynek felhasználásával pl. LIT formátumú e-könyvek készíthetők. 5 HTML2XML átalakítások alatt HTML állományok XML formátumúvá való átalakítását értjük. 16

27 Az SGML/XML jelölésrendszer kódolás nemzetközileg elfogadott és alkalmazott rendszerek mellett letenni a voksot, pl. TEI, DocBook lásd.: A DTD-k szerkezeti felépítése c. fejezet Elemek egymásba ágyazása Még a legegyszerűbb szöveges dokumentumokban is vannak olyan elemek, amelyek más elemekbe vannak beágyazva. Sőt, dokumentumaink valójában akkor válnak igazán SGML/XML anyagokká, ha megtalálható bennük az ún. gyökér-/szülőelem (root). 6 Ez az elem keretbe foglalja a többi részegységet. A szülőelemnek van gyermeke (child), és esetenként a gyermekelemnek is lehetnek gyermekei (subchild). Tehát ez azt jelenti, hogy az elemeket rendszerint más típusú elemekbe beágyazva találjuk, vagyis a külső elemek teljes mértékben tartalmazzák a belső elemeket. Nagyon fontos, hogy az SGML/XML-elemek párokat alkotnak persze ez alól is van kivétel, lásd.: Üres elemek és Minimalizálási lehetőségek c. alfejezetekben, hiszen közöttük helyezkedik el a szöveges tartalom, így válhatnak hordozóelemekké, következésképp megnyitásukhoz képest fordított sorrendben kell lezárni őket. Egyszerű példával illusztrálva: <bekezdes>a szövegben lehet <kiemeles>kiemelés</kiemeles> és <labjegyzet>lábjegyzet</labjegyzet> is.</bekezdes> Üres elemek Előfordul, hogy egyes elemek, melyek egyébként tartalmazhatnának szöveget, egyszerűen üresen maradnak. Ilyenkor nem hordozóelem szerepét töltik be, hanem helyfoglalókként funkcionálnak. Gondoljunk csak egy regényre, melyben oldaltörések és sortörések szerepelnek. Ekkor az említett jelölőelemeknek nem kell magukba foglalniuk valamiféle szöveges információt, szerepük pusztán az egyes töréspont-típusok megkülönböztetésében keresendő. SGML/XML-ben üres elemeket kétféleképpen ábrázolhatunk, ebből az első lehetőség: <sortores></sortores> Vagyis a záró jelölőelemet közvetlenül a nyitó jelölőelem után írjuk. Üres, helyfoglaló elemek esetében azonban semmi nem indokolja két jelölőelem használatát. Egyrészt nincs hordozott szöveg, tehát a záró jelölőelem felesleges. 7 Másrészt ezzel egyúttal kiküszöbölhetjük azt a záró jelölőelem jelenlétéből fakadó bizonytalanságot, ami azt sugallja, hogy szöveget illeszthetünk a két elem közé. A második lehetőség tehát jobb és tömörebb alternatívát kínál: <sortores/> Mivel az SGML nyelvben nem kötelező az üres elemek lezárása 8, így a teljesség kedvéért mutatunk harmadik lehetőséget is ez értelemszerűen XML-ben nem használható: <sortores> 6 Gondoljunk csak a HTML, vagy az XHTML nyelvre, ahol a <html> </html> elemek között helyezkedik el a strukturált szöveges tartalom. Ebben az esetben értelemszerűen a <html> elem tölti be a gyökér szerepet. 7 Mivel az XHTML egy XML-alkalmazás, ezért az abban alkalmazott sortörés <br/> esetében is ugyanez a szabály érvényesül. 8 Mivel a HTML egy SGML-alkalmazás, ezért az abban alkalmazott sortörés <br> esetében is ugyanez a szabály érvényesül. 17

28 Minimalizálási lehetőségek Az SGML/XML jelölésrendszer kódolás Az SGML nyelv megalkotásakor a lemezterület és a memória nagyságrendekkel drágább és nehezebben hozzáférhető volt, mint manapság nem beszélve kapacitásuk mai szemmel nézve igencsak elenyésző voltáról. Egyik fő szempontnak ezért a létrejövő dokumentumok méretét tartották, így elengedhetetlennek bizonyult a jelölés minimumon tartása. Ezt csak tetézte, hogy a szövegjelölést végző személyeknek a jelölőelemek minden egyes karakterét egyenként be kellett gépelniük. Nem csoda tehát, ha az SGML választható jellemzőként lehetőséget biztosít az elem-minimalizálásra. Az XML kialakulásakor a felsorolt szempontok már értelmüket vesztették, így XML-ben nem lehet minimalizálni, lásd.: XML az SGML öccse c. alfejezet 10. pontját. Ennek bemutatására vegyünk egy nagyon egyszerű szerkezeti modellt. Tegyük fel, hogy egy versgyűjteményben a verseket, szerzőket, verscímeket, versszakokat és az őket alkotó verssorokat akarjuk azonosítani. A terminológia szerint a dokumentumtípusunk antológia, mely különböző szerzők válogatott verseiből áll. Példánk minden versében egyetlen címelem van, melyet egy másik fajta elem, a versszak többszörös előfordulással követhet, a versszakokban pedig ismét egy újabb elem, a verssor fordulhat elő többszörös gyakorisággal. Teljes tartalmi tagolás után egy ilyen modellnek megfelelő szöveg az alábbiak szerint nézhet ki: <antologia> <vers> <szerzo>petőfi Sándor</szerzo> <cim>méz és csók</cim> <versszak> <sor>kis méh! te a füvet, fát,</sor> <sor>s virágokat leped,</sor> <sor>hogy édes kelyheikből</sor> <sor>gyüjthessed mézedet.</sor> </versszak> <versszak> <sor>kis méh! Lidim füvet, fát</sor> <sor>s virágokat nem lep,</sor> <sor>mézednél csókja mégis</sor> <sor>mi sokkal édesebb.</sor> </versszak> </vers> <! - Antológiáról lévén szó, itt további versek következnek. --> </antologia> Mivel bemutatott modellünk mentes mindennemű minimalizálási technikától, ezért teljes mértékben normalizáltnak tekintjük. Néhány jelentéktelen kivételtől eltekintve a normalizált SGML ugyanúgy néz ki, mint az XML ez jól látszik a jelölt versből is Befejező jelölőelem elhagyása A példában azonban nem vettünk figyelembe semmiféle olyan előfeltételt, amely szerint például a cím nem jelenhet meg másutt, mint az első versszak előtt, vagy, hogy nem lehetnek verssorok a versszakokon kívül. Ezért is tűnik olyan bőbeszédűnek a jelölésünk. A gyakorlatban azonban a DTD lásd.: A DTD-k szerkezeti felépítése c. fejezet segítségével megfogalmazhatunk olyan szabályokat, amelyekkel kiküszöbölhetjük a fenti tagolás jelentős részét. Versmodellünknél maradva, felállított szabályaink a következők lehetnek: 1. Az antológia csakis verseket tartalmazhat, semmi mást. 2. A versnek mindig egyetlen címeleme van, mégpedig az első versszak előtt, a címelemet pedig a szerző neve előzi meg. 3. A címtől eltekintve a vers versszakokból áll. 4. A versszakok csak sorokat tartalmaznak, és minden sor csakis versszakon belül állhat. 5. A versszak után vagy egy másik versszak következik, vagy a vers vége. 18

29 Az SGML/XML jelölésrendszer kódolás 6. A sor után vagy egy másik sor következik, vagy egy új versszak. A felsorolás szabályaiból adódóan számos záró jelölőelem elhagyása megengedett. A 2. szabályból következik, hogy nem kell külön jeleznünk a cím végét, mert az első versszak kezdete ezt egyértelműen jelöli, ugyanez érvényes a szerző nevére is. Hasonlóképpen a 3. és 1. szabályból az következik, hogy nem kell külön jeleznünk a vers végét, mivel a versek nem lehetnek verseken belül, csak antológiákon belül, a vers végét egyértelműen jelzi a következő vers kezdete vagy az antológia vége. Az 5. és 6. szabályból levezethető, hogy nincs szükség a versszakok vagy a sorok végének külön jelölésére. Ennek alapján új, immár SGML alapú versmodellünk a következő formát ölti: <!-- SGML --> <antologia> <vers> <szerzo>petőfi Sándor <cim>méz és csók <versszak> <sor>kis méh! te a füvet, fát, <sor>s virágokat leped, <sor>hogy édes kelyheikből <sor>gyüjthessed mézedet. <versszak> <sor>kis méh! Lidim füvet, fát <sor>s virágokat nem lep, <sor>mézednél csókja mégis <sor>mi sokkal édesebb. <!-- Antológiáról lévén szó, itt további versek következnek. --> </antologia> Kezdő jelölőelem elhagyása Az SGML azonban nem áll meg ennyinél, néhány esetben a nyitó jelölőelem elhagyását is megengedi. Erre akkor van lehetőség, ha a környezetből nyilvánvaló, hogy az elem elkezdődött. Modellünknél maradva, ha elkezdődik egy versszak, akkor utána biztosan egy sor fog következni, melynek nyitó eleme elhagyható, mivel a zárót megtartjuk. A befejező jelölőelem után egy új sor következik, melynek ismét nem szükséges jelölni az elejét: <!-- SGML --> <versszak> Kis méh! Lidim füvet, fát</sor> S virágokat nem lep,</sor> Mézednél csókja mégis</sor> Mi sokkal édesebb.</sor> </versszak> Üres befejező jelölőelem Az is előfordulhat, hogy a befejező jelölőelem ugyan szerepel, annak nevét azonban kihagyjuk. Ezeket üres záró jelölőelemnek nevezzük: <!-- SGML --> <versszak> <sor>kis méh! te a füvet, fát,</> <sor>s virágokat leped,</> <sor>hogy édes kelyheikből</> <sor>gyüjthessed mézedet.</> 19

30 Az SGML/XML jelölésrendszer kódolás </versszak> Üres kezdő jelölőelem A jelölőelem kezdő része is üres lehet, ha megegyezik az előző nyitó jelölőelemmel. Ezt nevezzük üres nyitó jelölőelemnek: <!-- SGML --> <versszak> <sor>kis méh! Lidim füvet, fát</sor> <>S virágokat nem lep,</sor> <>Mézednél csókja mégis</sor> <>Mi sokkal édesebb.</sor> </versszak> Versszakunkban a <> jelölőelem kezdő karakterek következtetett jelentése <sor>, mivel ez az előző elem az adatfolyamban. Az SGML-ben még van néhány nagyon hatékony minimalizálási lehetőség null záró jelölőelem; rövid hivatkozások stb., ám ezek ismertetésétől eltekintünk, mivel használatuk ritka, szövegfeldolgozás során szinte soha nem fordulnak elő. Összegzésként elmondható, hogy az a lehetőség, amellyel az elemek egymásba ágyazását meghatározó szabályokat fogalmazhatunk meg a jelölés egyszerűsítése érdekében, az SGML-nek igen fontos tulajdonsága! Azonban azt se felejtsük el, hogyha az átláthatóságot és a későbbiekben pl. feldolgozás szempontjából való könnyebb kezelhetőséget tartjuk szem előtt, akkor nem célszerű élni az ismertetett minimalizálási lehetőségekkel. Inkább javasoljuk, hogy használjunk normalizált SGML-t, vagy eleve XML alapokra helyezzük épülő szövegarchívumunkat! 2.2. Attribútumok Az SGML/XML terminológiában az attribútum (jellemző) szónak különleges értelme van. Segítségével olyan információt írunk le, amely bizonyos értelemben hozzátartozik az elem adott előfordulásához, jellemzi azt, de ténylegesen nem része az elem tartalmának. Az attribútum tulajdonképpen az elem paramétere, amely módosítja vagy pontosítja annak jelentését. Neve megkülönbözteti az elemben szereplő összes többi attribútumtól Attribútumok felépítése Noha különböző elemek attribútumainak nevei akár megegyezők is lehetnek, mindig különbözőnek tekintjük őket, hiszen más elemhez tartoznak. Ez viszont lehetővé teszi számunkra, hogy az egyes attribútumokhoz eltérő értékeket rendeljünk hozzá. Ha egy elemet úgy definiálunk, hogy van attribútuma, akkor az attribútum értékét mindig az attribútum nevével együtt, az elem előfordulásának kezdő jelölőelemében adjuk meg, mégpedig egyenlőségjellel ( = ) elválasztva, az értéket idézőjelbe ( ), vagy aposztrófok ( ) közé téve. 9 Legalább egy szóköz kell, hogy álljon az elemnév és az első attribútum, illetve a többi attribútumok között. Opcionálisan akár még szóközök is állhatnak az egyenlőségjel mellett: <kep filenev= images/neumann.160x200.png hely= jobb > <kepleiras>neumann János arcképe</kepleiras> 9 A HTML nyelvet jól ismerők számára biztosan ismerős pl. a <hr noshade> rövidített forma. Itt az attribútumnév nincs jelen és csak egyetlen megengedett értékkel rendelkezik jelen esetben noshade. Amennyiben az érték sincs jelen, akkor burkolt értékről beszélünk shaded, így jelenléte egyszerű kapcsoló utasításként működik. Mivel az XML megköveteli az attribútumnév, az egyenlőségjel és a határoló idézőjelek meglétét, ezért ez a technika csak SGML-nél használható. 20

31 Az SGML/XML jelölésrendszer kódolás </kep> Láthatjuk, hogy a <kep> elemben a filenev és a hely szerepel attribútumként. A fájlnév paraméter többletinformációval látja el a képelemet megmondja a forrásállomány helyét és nevét, a hely attribútum pedig a kép egy jellemzőjét árulja el, azaz hol helyezkedik el. Természetesen bárki joggal mondhatná, hogy teljesen felesleges ezeket attribútumokként szerepeltetni, hiszen elemnevekben is elhelyezhető ugyanez a tartalom ahogy a képleírás esetében. Igen, rajtunk áll a választás, hogy az SGML/XML-ben mikor használunk attribútumokat és mikor külön elemeket. Ha döntésre kerül a sor, akkor legcélszerűbb a definíciókból kiindulni: Elemként a dokumentum szerkezeti összetevőit jelöljük. Az elemek neve mindig az általuk hordozott tartalomra utal. Attribútumként azokat a tulajdonságokat jelöljük, amelyek az elemet többletinformációval látják el jellemzik az elemet. Ha esetleg valakit még nem győztünk meg az attribútumok fontosságáról, akkor korábbi versmodellünknél maradva nézzünk egy másik példát: <antologia> <vers azon= V1 statusz= publikalt > <szerzo>petőfi Sándor</szerzo> <cim>méz és csók</cim> <versszak> <sor>kis méh! te a füvet, fát,</sor> "..." A <vers> elemet úgy definiáltuk, hogy két attribútuma legyen: azon és statusz. A <vers> azon attribútumának értéke "V1", a statusz attribútum értéke pedig publikalt. [Megj.: Az attribútumok nevére ugyanolyan megszorítások vonatkoznak, mint a nevekre általában az SGML/XML-ben: nem kell egyedieknek lenniük a teljes szövegben, csak az adott elemre vonatkozó attribútumlistában.] Az SGML/XML feldolgozóprogram ezeket az attribútumértékeket tetszőleges célra használhatja; például egy tördelőprogram a "vazlat" attribútumértékkel rendelkező verseket másképpen formázhatja, mint mondjuk a "jovahagyott", vagy a "publikalt" attribútumértékkel rendelkező verseket; egy másik feldolgozó program ugyanazon attribútum alapján pedig eldöntheti, hogy az adott verset egyáltalán feldolgozza, publikálja-e vagy sem Attribútumnevek Az elemnevekhez hasonlóan az attribútumnevek is érzékenyek a kis- és nagybetűkre. Nagyon figyelni kell tehát itt is a név pontos írására, hiszen pl. hivatkozás céljának meghatározásakor nem ugyanazt jelenti a CÉL, vagy a cél, netán a Cél attribútum. Az attribútumnevek esetében nincsenek külön szabályok, az elemneveknél ismertetettek itt is helytállóak lásd.: Elemnevek c. alfejezet. Léteznek azonban olyan univerzális attribútumok, amelyek azonosak a különböző alkalmazások elemeiben. Éppen ezért, hogy a felhasználók által definiált attribútumnevekkel való összeütközést elkerüljék, az XML ajánlás készítői az xml: előtagot lefoglalták a nyelvben. Az alapajánlás két foglalt attribútumot rögzít, melyek közül az egyik a szövegben alkalmazott nyelvek azonosítására szolgál, a másik pedig arra, hogy alkalmazzuk-e a térközkaraktereket a jelölés vagy a dokumentum szövegének formázásához Nyelv rögzítése 21

32 Az SGML/XML jelölésrendszer kódolás Több oka is lehet, hogy miért fontos egy adott elemben tárolt szöveg nyelvének azonosítása. Az xml:lang attribútumnév a nyelv és bizonyos esetekben az ország adatainak tárolására van fenntartva mivel ugyanaz a nyelv eltérhet egyes országokban. A jellemző értéke token 10, vagy kód, amely 4 lehetséges séma valamelyikének felel meg: 1. Az ISO 639 szabvány szerint a nyelvek megnevezésére használt kódok két karakterből állhatnak: <!-- XML --> <bekezdes xml:lang= en >Designed for information professionals such as librarians.</bekezdes> 2. Ha felhasználó által definiált a kód, akkor x-szel kell kezdődnie: <!-- XML --> <bekezdes xml:lang= x-hungarian >Egyéni attribútumérték.</bekezdes> 3. Lehet az érték IANA-nál 11 regisztrált is, ilyenkor kis vagy nagy i betűvel kezdődik: <!-- XML --> <bekezdes xml:lang= i-hungarian >IANA attribútumérték.</bekezdes> 4. Nem utolsó sorban pedig léteznek olyan részkódok is, melyek kötőjellel ( - ) vannak elválasztva egymástól és a főkódtól. Amennyiben az első részkód két betűből áll és nem része a felhasználó által definiált kódnak, úgy a részkódnak az ISO 3166 szerinti országkódnak kell lennie. Magyarország esetében például ez a HU formát ölti: <!-- XML --> <bekezdes xml:lang= en-us >John von Neumann Digital Library and Multimedia Center.</bekezdes> <!-- XML --> <bekezdes xml:lang= en-gb >John von Neumann Digital Library and Multimedia Centre.</bekezdes> Mivel az attribútumértékek érzékenyek a kis- és nagybetűkre, a kódok értelmezése viszont nem, így azok bármilyen kombinációban elhelyezhetők. A bevett szokás azonban az, hogy nyelvkódok esetén kisbetűt, országkódok esetén nagybetűt használunk ahogy a példában is látható Üres helyek megtartása SGML/XML dokumentumokba szóközöket, tabulátorokat, soremeléseket és kocsi visszákat 12 szúrhatunk be annak érdekében, hogy átláthatóbbá tegyük azok forrását. Mindez természetesen nincs hatással a tényleges tartalomra, tehát az alábbi példákat a kimenet szövegének szempontjából teljesen egyenértékűnek tekinthetjük: 10 Token olyan információs egység, amely rendszerint csoportban szerepel. Lehet egyetlen objektum, pl. elemnév, vagy egész beágyazott csoport, amely szintén tokeneket tartalmaz. A token az XML és az XLink ajánlások szabályait leíró definíciók építőeleme. 11 IANA Internet Assigned Numbers Authority (Internet Számkiosztási Felügyelőség). 12 Ignorable whitespaces (figyelmen kívül hagyható térközök) Olyan elemek belsejében fordulnak elő, amelyek csak további elemeket tartalmaznak, szöveges részeket nem. Az ilyen térközök nem részei a dokumentum tartalmának, csupán a jelölőelemek átláthatóságát segítik. 22

33 Az SGML/XML jelölésrendszer kódolás <resz tipus="fejezet"><fejresz><cim tipus="cim1">névadónk, Neumann János</cim></fejresz> <resz tipus="fejezet"> <fejresz> <cim tipus="cim1"> Névadónk, Neumann János</cim> </fejresz> "..." Névadónk, Neumann János Egyes szoftverek ugyan képesek különbséget tenni elem-elem közti szóköz karakterek, illetve szöveget tartalmazó elemek szóköz karakterei között ez utóbbit nevezzük jelentéssel bíró üres helynek, más feldolgozó alkalmazások viszont hajlamosak a több szóközt egyre csökkenteni és a sorvégi kódokat szóközre cserélni normalizálás. Amennyiben a szóközöket jelentéssel bírónak tekintjük, úgy XML-ben az xml:space attribútum használatával felülbírálhatjuk az alapértelmezett kezelési módot. Ha az attribútumot a kódoló alkalmazza egy elemre és értékként a preserve (megtart) szót használja a default (alapértelmezett) helyett, akkor az elem összes üres helyének jelentősége lesz: <!-- XML --> <bekezdes xml:space= preserve >Neumann-ház 1014 Budapest, Színház utca 1-3.</bekezdes> Neumann-ház 1014 Budapest Színház utca 1-3. Érdekes formázási lehetőséget biztosít jóllehet meglehetősen ritkán használjuk a halmozott szóközhasználat szövegigazítás során. Ha ilyet alkalmazunk, akkor arra kell ügyelni, hogy melyik betűtípus jeleníti meg a tartalmat, ugyanis legtöbbükben az egyes karakterek eltérő szélességűek. Az egyedüli üdvözítő megoldás tehát a fix szélességű betűtípusok használata: <!-- XML --> <bekezdes xml:space= preserve > \ / o </bekezdes> Fix szélességű betűtípussal, pl. Courier New tökéletes a megjelenítés: \ /

34 Az SGML/XML jelölésrendszer kódolás o Amennyiben az anyag megjelenítéséhez változó szélességű betűtípust veszünk igénybe, a tartalom nagy valószínűséggel eltorzul, pl. Times New Roman esetén. Ennek oka, hogy a szóköz karakter szélessége eltér a többi karakterétől: \ / o Attribútumértékek Az attribútum-értékeket idézőjelek vagy aposztrófok határolják. Ennek különösen akkor van jelentősége, ha szóközök fordulnak elő az érték nevében, hiszen csak így lehet rendesen felismerni az adott érték végét. Nézzünk egy példát: <kiemeles kover= fat 1 dolt= 1 >Félkövér és dőlt szöveg.</kiemeles> Félkövér és dőlt szöveg. A kover attribútum jelenleg fat 1, a dolt pedig 1 értékkel rendelkezik. Ha nem tennénk ki az idézőjeleket, akkor azt feltételezhetnénk, hogy a kover attribútum értéke fat 1 dolt=1 lenne, ha pedig a szóközt lezáró karakterként értelmeznénk, akkor a kover attribútum feltételezett értéke csupán fat lenne. Noha az esetek többségében idézőjelet használunk, találkozhatunk olyan jelöléssel is, amelyben aposztrófot alkalmaztak. Az aposztróf használatának semmi akadálya, ám rendszerint akkor fordul elő, ha az idézőjeleket az attribútumérték részeként akarjuk feltüntetni. Ha az értékekben mindkét idézőjeltípust használjuk, akkor a már ismertetett vezérlőkódokat célszerű elhelyezni (idézőjel: ", aposztróf: &apos;). Fontos megjegyezni azt is, hogy a határoló jeleket mindig kötelező kitenni és az attribútumnévnek is mindig jelen kell lennie. Az attribútum-értékekben a kocsi visszát, az új sort és a tabulátort mindig megegyezőnek tekintjük a szóköz karakterrel, tehát arra is fordítjuk le. Ennek függvényében tehát az alábbi példák is egyenértékűek: <lista tipus="lower alpha"> <lista tipus="lower alpha"> 2.3. Entitások Az SGML/XML eddig tárgyalt sajátságai mind a dokumentumon belüli strukturális összetevők jelölésével foglalkoztak. A technológia azonban rugalmas és egyszerű módszert kínál arra is, hogy a dokumentumon belüli aktuális tartalom tetszőleges részeit hordozható módon kódoljuk és azonosítsuk. Ennek a hordozhatóságnak a 24

35 Az SGML/XML jelölésrendszer kódolás megvalósításához ún. entitásokra (egyedekre) van szükségünk. Az entitások segítségével az összetevők megoszthatók és még könnyebben kezelhetők, a speciális karakterek pedig megjeleníthetők lesznek, ráadásul nem SGML/XML adatokat is elhelyezhetünk az állományokban. Fontos azonban megemlíteni, hogy szövegfeldolgozás során entitásalapú megoldásokkal leginkább speciális karakterek kódolása esetén találkozunk. Mindez azzal magyarázható, hogy ez az XML ajánlás egyik legkevésbé kedvelt része, ugyanis bizonyos kiegészítő ajánlások XLink, XInclude, XSLT, XML Schema saját megoldásokat nyújtanak, hogy elkerüljék az entitások használatát. Ettől függetlenül az egyedek az SGML/XML technológia nagyon fontos szegmensét képezik és az SGML-t ismerő alkalmazások mindmáig erősen támogatják használatukat. Az alábbiakban általánosságban SGML/XML jelölés szintjén beszélünk az entitásokról, ugyanis a A DTD-k szerkezeti felépítése c. fejezet részletesen, példákkal illusztrálva foglalkozik velük Az entitásokról általában Az SGML/XML-ben az egyed (entitás) szó sajátos értelemmel rendelkezik: a jelölt dokumentum valamely azonosított, névvel ellátott részét jelenti, függetlenül bármely szerkezeti megfontolástól. Tehát az entitások olyan változók, amelyek más szövegelemekre mutatnak. Sokszor előfordul, hogy az entitást az elem szinonimájának tartják, pedig az entitások nagyban különböznek az elemektől. Míg az előbbiek a fizikai összetevőkre, addig az utóbbiak a logikai szerkezetre helyezik a hangsúlyt. Az entitások ráadásul sokkal bonyolultabbak, mint az elemek, mert többféle célra használhatók. Valójában az SGML/XML számos kulcsmegoldása az entitásokra épül, következésképp a teljesség igénye nélkül érdemes számba venni néhány okot, amiért használjuk őket: Speciális, vagy idegen karaktereket (pl. görög betűket) szeretnénk a szövegbe illeszteni. Külső fájlból szeretnénk adatokat átemelni. Rövidítéseket szeretnénk alkalmazni a teljes szövegen (ami később változhat). Hivatkozások révén elérhető külső bináris adatokat, pl. képeket akarunk beilleszteni Entitáshivatkozások Az egyedhivatkozás általában olyan egyszerű jelölésszerkezet, mely egy és ( & ) jellel kezdődik és egy pontosvesszővel ( ; ) végződik. 13 A szerkezet törzsrésze hivatkozás az entitás nevére. A következő példa egy DIA nevű entitás hivatkozása, melynek behelyettesítési értéke lehet például a Digitális Irodalmi Akadémia : A &DIA; program kortárs szerzők életművét dolgozza fel. Az entitáshivatkozást a feldolgozóprogram veszi észre, miközben értelmezi az SGML/XML dokumentum forrását. Miután észrevette az egyedet, eltávolítja azt, és helyét átveszi a behelyettesítési érték, melyet aztán ugyanúgy értelmez a feldolgozó, mintha kezdettől fogva része lett volna a dokumentumnak: A Digitális Irodalmi Akadémia program kortárs szerzők életművét dolgozza fel. Ugyanez a mechanizmus működik ékezetes, speciális, illetve idegen karakterek esetében is. A következő egyszerű versmodell-példa azt szemlélteti, hogy ékezetes karakterek esetén miként illesztünk be entitáshivatkozásokat: 13 A pontosvesszőre mindig szükség van, még abban az esetben is, ha szóköz követi. 25

36 Az SGML/XML jelölésrendszer kódolás <szerzo>petõfi Sándor</szerzo> <cim>méz és csók</cim> <versszak> <sor>kis méh! te a füvet, fát,</sor> <sor>s virágokat leped,</sor> <sor>hogy édes kelyheikbõl</sor> <sor>gyüjthessed mézedet.</sor> Petőfi Sándor Méz és csók Kis méh! te a füvet, fát, S virágokat leped, Hogy édes kelyheikből Gyüjthessed mézedet Karakterentitás-hivatkozások Már említést tettünk arról, hogy entitáshivatkozásokkal bármilyen karaktert helyettesíthetünk, és hogy ezt speciális karakterek esetében ki is használjuk. Alapvetően tehát kijelenthetjük: alkalmazásának legáltalánosabb esete az, amikor olyan karakterek szerepeltetése miatt használunk egyedeket, melyeket normális beviteli eszközzel lehetetlen lenne a dokumentumba begépelni, vagy beolvasni. Gondoljunk csak bele, hogy billentyűzetünkkel mennyire korlátozott számú karakterkészlet vihető be SGML/XML állományainkba Ha karakterentitásokat akarunk használni, akkor tudnunk kell, hogy a karakteregyedekre vonatkozó referenciák az entitáshivatkozásokhoz hasonlóan és ( & ) jellel kezdődnek, majd kettős kereszt ( # ), vagy kettős kereszt x ( #x ) szimbólummal folytatódnak, végül pontosvesszővel ( ; ) záródnak: &#...; &#x...; A név további része egy szám, ami a karakter karakterkészletében elfoglalt helyét jelenti Decimális hivatkozások A karakterkészletben elfoglalt hely, rendszerint egy 0 és 127 közé eső 7 bites ASCII 14 karaktert jelöl. Az A például a nagy A betűre való hivatkozás. Amennyiben az érték 0 és 255 közé esik, úgy kiterjesztett ASCIIkészletről ISO (latin-1) beszélünk, ami már 8 bites és két karakter kivételével tartalmazza az összes magyar ékezetes betűt. A két hiányzó karakter a hosszú ő és ű. Példa decimális hivatkozások használatára. Példa decimális hivatkozások használatára. Jól látszik, hogy amíg az é hivatkozás é, addig az ÿ á karaktert jelent a szövegben. Ha az említett hosszú ő és ű betűket akarjuk decimális hivatkozásként szerepeltetni állományaink forrásában, akkor már a 256 és közé eső számértékekhez tartozó Unicode 15 ISO készletet kell igénybe vennünk: 14 ASCII American Standard Code for Information Interchange (amerikai szabványos kód az információ kölcsönös cseréjére). Az ASCII karakterkészlet 128 db hétbites kódot tartalmaz, mindegyikük egy egyedi karaktert reprezentál. 15 Unicode 2 bájtos, azaz 16 bites karakterkészlet, melyet a Unicode Consortium hozott létre. Valójában úgy is tekinthető, mint egy ASCII felett elhelyezkedő készlet, amely 0000-tól 00FF-ig megegyezik az ASCII 00 FF készlettel. 26

37 Az SGML/XML jelölésrendszer kódolás Könnyű bőbeszédűen írni a szövegjelölésről. Könnyű bőbeszédűen írni a szövegjelölésről. Ezek a hivatkozások minden körülmények között azonnal behelyettesítődnek az általuk képviselt karakterekkel, amint a feldolgozó program beolvassa a szöveget a forrásfájlból vagy az adatfolyamból. A cserekaraktereket a behelyettesítést követően már nem értelmezi újra az elemző, ám ha netán mégis ragaszkodnánk az újbóli elemzéshez, akkor egy nagyon egyszerű trükkhöz folyamodhatunk. Az és ( & ) jelet felcserélhetjük annak decimális karakterhivatkozásával: Tr&#252;kk az &#250;jb&#243;li elemz&#233;shez. Mindez azt eredményezi, hogy első elemzés esetén csak az és jelek jönnek létre a karakterhivatkozásokból & -> & létrehozva ezzel az ékezetes karakterek hivatkozásait. Ezek viszont már kizárólag újbóli elemzés során lesznek értelmezve: Trükk az újbóli elemzéshez Hexadecimális hivatkozások A számítógépek köztudottan kettes számrendszerben végzik a számításokat, ami azt jelenti, hogy a 0 és az 1 számjegyek segítségével építik fel a számokat. Mindez azzal a hátránnyal jár, hogy még a kis számok is nehezen hosszan írhatók le e két karakter használatával. Valami tömörebb jelölésre van tehát szükség, ami ráadásul szintén a kettes szám valahányadik hatványán alapul. Erre a feladatra a tizenhatos számrendszer 2 hatvány tökéletesen megfelel, ugyanis meglehetősen röviden képes jelölni még a nagy számokat is, ezért már régóta alkalmazzák számítógépen tárolt értékek kényelmesebb rögzítésére. A jelzés értelemszerűen 16 számjegy számára igényel karaktereket, így a 0-9-ig terjedő számokból és az angol ABC első 6 betűjéből áll. (A=10; B=11; C=12; D=13; E=14; F=15;). A hexadecimális karakterentitás-hivatkozásokban a 16-os számrendszerbeli értéket a korábban már említett x karakter előzi meg. á vagy á á á A bemutatott hivatkozás az á karaktert jelenti, mivel az E1 érték megegyezik a 225-ös decimális értékkel. A 8 bites ASCII-készlet karakterei tehát jól látható módon 2 karakterrel leírhatók 16-os számrendszerben ezért hagyható el az adott esetben jelentéssel éppen nem bíró 00 a hivatkozásból. Természetesen nagyobb értékekkel bármilyen Unicode 16 karakterre hivatkozhatunk, például: ő - ő ű - ű. 16 Sajnos a mindent megváltani akaró Unicode-nak is van némi közvetett hátránya. Mégpedig az, hogy hiába vagyunk képesek a segítségével szinte bármilyen karakterre hivatkozni hexadecimális formában, ha ezek egy részét a manapság leggyakrabban használt böngészőprogramok sem képesek megjeleníteni. 27

38 Az SGML/XML jelölésrendszer kódolás Példa hexadecimális hivatkozások használatára. Példa hexadecimális hivatkozások használatára Beépített entitáshivatkozások foglalt karakterek Magától értetődik, hogy a relációs karakterek fontos szerepet játszanak az SGML/XML dokumentumokban, hiszen ezek veszik körül az elemneveket. Ugyanakkor, ha az állományok szövegében is megjelennének, az megzavarná az értelmező szoftvereket. A félreérthetőség elkerülése érdekében tehát az említett karaktereket valamilyen ekvivalens módon helyettesíteni kell. Ezt könnyedén meg lehet oldani egy karaktersorozattal, ami tulajdonképpen vezérlőkód vagy ahogy SGML/XML-ben nevezik entitásnév, karakterreferencia. <bekezdes>a <bekezdes> elemek között használhatunk <kiemeles> elemeket is.</bekezdes> A <bekezdes> elemek között használhatunk <kiemeles> elemeket is. Az SGML/XML nyelvben az < (kisebb mint less than) entitásnév jelöli a < karaktert, és a > (nagyobb mint greater than) kód fejezi ki a > karaktert. A bemutatott karakterreferenciák használata azonban felvet még néhány példát. Jól látható, hogy az és ( & ) karakter is fontos jelölőkarakter, így szövegben való használatához szükség van entitásnévre. Valóban, ha és jelet akarunk elhelyezni, akkor az & (és ampersand) karakterhivatkozást kell használni: <cim>sgml & XML</cim> SGML és XML Kettő olyan karakterről nem tettünk még említést, amely szintén foglaltként szerepel a szóban forgó nyelvekben. Az egyik az aposztróf ( ), a másik az idézőjel ( ), mindkettő attribútumokban fordul elő innen a foglaltság. Míg az előbbi az &apos;, addig az utóbbi a " entitással helyettesíthető. Összefoglalva tehát: < a < helyett decimális ASCII kódja: < > a > helyett decimális ASCII kódja: > & az & helyett decimális ASCII kódja: & &apos; a helyett (attribútum-értékekben) decimális ASCII kódja: &#39; " a helyett (attribútum-értékekben) decimális ASCII kódja: " Megjegyzések Aki figyelmesen tanulmányozta a fejezet példáit, észrevehette, hogy néhol szerepeltek benne olyan szövegrészek is, amelyeket nem az eddig ismertetett kezdő és befejező jelölőkódok vettek körül. Ezek ún. megjegyzések voltak, melyek mindig nyitó csúcsos zárójellel ( < ), majd ezt követően egy felkiáltójellel (! ) és két kötőjellel ( -- ) kezdődnek, illetve két kötőjellel ( -- ) és egy lezáró csúcsos zárójellel ( > ) végződnek. Az ilyen jelzések után található szöveget az értelmező/feldolgozó program mindig figyelmen kívül hagyja a sor, vagy a sorok végéig. 28

39 Az SGML/XML jelölésrendszer kódolás A megjegyzések általában a dokumentum forrásával, vagy annak egy adott részével kapcsolatban hordoztak magukban valamilyen plusz információt. Használatuk rendszerint inkább programozás során gyakori, ám a szövegjelölésnél is hasznosak lehetnek. Ha például bizonyos szövegrészek speciális jelölést igényelnek, ott előnyös lehet megjegyzést fűzni a dokumentum adott részéhez: <!-- Ez egy nagybetűs római számozott lista. --> <!-- Persze ugyanez a nagybetűs római számozott listához tartozó megjegyzés akár több sorba tördelt is lehetne, akkor sem venné figyelembe a feldolgozó program. --> <lista tipus="upper-roman"> <elemertek>a kettes számrendszer alkalmazása.</elemertek> <elemertek>programvezérlés és tárolt adatok.</elemertek> </lista> I. A kettes számrendszer alkalmazása. II. Programvezérlés és tárolt adatok. Mivel a megjegyzéseknek nincs hatása a feldolgozás folyamatára, így a dokumentumokban sem jelennek meg. A szövegjelölés során bárki írhat megjegyzést SGML/XML dokumentumokba, ha szükségesnek ítéli annak magyarázó jelenlétét Nem elemzett karakteres adatok Az SGML/XML dokumentumok tartalmának nagy részét rendszerint teljes egészét a feldolgozó programok tudják kezelni. Amikor a dokumentum szerzője jelöléshatárolókkal összetéveszthető karaktereket (pl. >, <, & ) használ, a bevett gyakorlat a már ismertetett vezérlőkódok (pl. >, <, & stb.) segítségül hívása. Olykor azonban a dokumentumok nagy mennyiségben tartalmaznak ilyen karaktereket, ami azt eredményezi, hogy e kódok használata is kényelmetlenné válik: Szövegszerkesztőkben az <<<ENTER>>> billentyű megnyomásával lehet új bekezdés nyitni. Szövegszerkesztőkben az <<<ENTER>>> billentyű megnyomásával lehet újbekezdést nyitni. Látszik, hogy a jelölt szöveg forrása nehezen olvasható és értelmezhető, sőt létrehozása sem annyira egyszerű a sok vezérlőkód miatt. Szélsőséges esetben még az is előfordulhat, hogy a fájlméret is indokolatlanul megnő, illetve a feldolgozás lassabb lesz. Mi tehát a megoldás? Nos, kétségkívül hasznos lenne, ha olyan szövegtartományokat tudnánk azonosítani, amelyek a feldolgozás szempontjából jelentéktelennek minősülnek és azokban helyezhetnénk el a szóban forgó szövegrészeket. Erre az SGML/XML lehetőséget biztosít, ugyanis karakteradatként olyan adat, ami jelölést nem tartalmaz, karaktereket viszont igen szövegblokkokat lehet azonosítani ezeket nevezik CDATA-szakaszoknak. 17 A CDATA-szakasz kezdetét a <![CDATA[ karaktersorozat jelzi, végéről pedig a ]]> karakterek gondoskodnak. 18 Mivel a karakteradatban nem szoktak jelölőkarakterek előfordulni, a ]]> sorozattól eltekintve nem keletkezik zavar, ha a szövegben jelöléshez kapcsolódó karaktereket használunk: <![CDATA[Szövegszerkesztőkben az <<<ENTER>>> billentyű 17 SGML-ben a CDATA szakasztípuson kívül más RCDATA, TEMP, IGNORE, INCLUDE szakasztípusok is rendelkezésre állnak. XMLben az utóbbi kettő használható még, de azok is csak a DTD külső részhalmazában. 18 A CDATA szakaszok kezdetét és végét jelző karakterek az SGML nyelvben átdefiniálhatók. 29

40 Az SGML/XML jelölésrendszer kódolás megnyomásával lehet új bekezdést nyitni.]]--> Szövegszerkesztőkben az <<<ENTER>>> billentyű megnyomásával lehet új bekezdést nyitni. Ha vezérlőkódok vannak jelen CDATA-szakaszokban, nem tekintjük őket jelentéssel bírónak, tehát a kimenetben is karakterreferenciaként jelennek meg: <![CDATA[Az <, >, & stb. vezérlőkódok a kimeneti állományban is ugyanezt a formát öltik.]]--> Az <, >, & stb. vezérlőkódok a kimeneti állományban is ugyanezt a formát öltik XML-deklaráció Az eddig tárgyalt témakörök és az ott bemutatott példák mind az SGML/XML alapú szövegjelölés szabályaival álltak kapcsolatban. Arról azonban még egyáltalán nem ejtettünk szót, hogy az XML és az SGML állományok rendszerint milyen utasítással kezdődnek. Az XML ajánlás feldolgozási utasítást alkalmaz, hogy magáról a dokumentumról fontos információkat közöljön a feldolgozó alkalmazások felé. A szóban forgó utasítást XML-deklarációnak nevezzük és a következőképpen ábrázoljuk: <!-- XML --> <?xml...?> <dokumentum> </dokumentum> Az XML-deklaráció mindig <? karakterekkel kezdődik,?> karakterekkel végződik és ideális esetben három részből jobban mondva paraméterből áll, melyek közül kettő használata opcionális. A kötelező version (verzió) paraméter azt mondja meg a feldolgozó programnak, hogy a jelölt dokumentum az XML melyik verziójával van összhangban. Mivel a jelenlegi alkalmazások leginkább az 1.0-ás 19 változatot támogatják, ezért mindig ezt a verziószámot adjuk meg a deklarációban: <!-- XML --> <?xml version= ?> Az opcionális encoding (kódolás) a dokumentum készítésénél használt kódolási sémát takarja latin 2-es kódolás esetén pl. ISO Ha szerepel, akkor kötelezően a verziót meghatározó paraméter után kell állnia. Ha nincs jelen, akkor az alapértelmezett kódolás mindig UTF-8 20 : 19 Az XML-deklaráció opcionális az 1.0-ás verzióban, így ha nincs jelen, akkor 1.0 a feltételezett érték. 20 UTF UCS Transformation Format (UCS transzformációs formátum) Az UCS-2, ill. UCS-4 kódolású adatok adatmozgatás előtti tömörítési eljárása. A 2 és 4 bájtos karakterábrázolás pazarló, ha sok gyakran előforduló karakter szerepel a dokumentumban. Egy szövegfájl viszont akár 75%-kal is tömöríthető. Két változata, az UTF-8 (8 bites) és az UTF-16 (16 bites) különböző szintű támogatást nyújt az átvihető karakterek számához. 30

41 Az SGML/XML jelölésrendszer kódolás <!-- XML --> <?xml version= 1.0 encoding= iso ?> A szintén opcionális standalone (egyedülálló) paraméter azt jelzi, hogy a dokumentum feldolgozását befolyásolja-e valami külsőleg meghatározott deklarációkészlet. A paraméter értéke yes, vagy no formát ölthet, az előbbi egyedülállóságra, míg az utóbbi befolyásoltságra utal: <!-- XML --> <?xml version= 1.0 encoding= UTF-8 standalone= yes?> Amennyiben az XML-deklaráció jelen van a dokumentumban, úgy mindent meg kell előznie. Még egy előtte álló szóköz karakter is érvénytelenné teheti az egész állományt. SGML esetében nem beszélhetünk XMLdeklarációról, tehát az SGML állományok soha nem ilyen utasítással kezdődnek, hanem ún. dokumentumtípusdeklarációval! 2.7. Dokumentumtípus-deklaráció (DTD) A dokumentumtípus-deklarációk XML esetében bizonyos szempontból visszatérést jelentenek az SGML gyökerekhez, mivel alapvetően SGML dokumentumokban kötelező a használatuk, XML-nél csak opcionális. Az ilyen típusú deklarációk mindig <! karakterekkel kezdődnek és > karakterrel végződnek. SGML állományoknál a <! nyitó jelölőkaraktereket mindig DOCTYPE kulcsszó követi: <!-- SGML --> <!DOCTYPE név kulcsszó külső-azonosító [definíciók]> XML forrásban a DOCTYPE kulcsszó sorát megelőzendő, az XML-deklaráció kap helyet: <!-- XML --> <?xml version= ?> <!DOCTYPE név kulcsszó külső-azonosító [definíciók]> A DOCTYPE-ot követő név mindig a dokumentum gyökércsomópontját azonosítja, pl.: <!DOCTYPE dokumentum... > <dokumentum> </dokumentum> A kulcsszó SYSTEM vagy PUBLIC elnevezésű lehet. Az előbbi akkor használatos, ha a DTD egy meghatározott személyhez vagy szervezethez kötött, az utóbbi pedig, amikor a DTD-t egy szabványalkotó testület hozta létre, vagy egyszerűen csak a nagyközönség rendelkezésére áll: <!DOCTYPE dokumentum SYSTEM... > vagy 31

42 <!DOCTYPE dokumentum PUBLIC... > Az SGML/XML jelölésrendszer kódolás Negyedikként a külső-azonosító kap helyet, ami SYSTEM kulcsszónál egy URI-t 21 takar, PUBLIC használatakor pedig valamilyen publikus azonosítót és egy URI-t: <!DOCTYPE dokumentum SYSTEM dokumentum.dtd... > <!DOCTYPE dokumentum PUBLIC -//NEUMANN//DTD DigLib.TEIP4.DTD//HU > A szögletes zárójelben [ ] lévő definícióknak akkor van szerepük a deklarációban, ha a dokumentum entitásokat használ, vagy belső DTD-hez kapcsolódik. Valós esetekben azonban a dokumentumtípus-deklaráció csak akkor jelenik meg, amikor egy külső fájlban található DTD-re hivatkozunk, egyébként ritkán. Az alábbiakban minden dokumentumtípus-deklarációkkal kapcsolatos tudnivalót ábrán is összefoglaltunk: Külső DTD deklarációk Külső DTD deklarációt tartalmazó SGML/XML állományok szerkezeti váza Belső DTD deklarációk Belső DTD deklarációt tartalmazó SGML/XML állományok szerkezeti váza Vegyes DTD deklarációk 21 URI Uniform Resource Identifier (egységes erőforrás azonosító) Az internet címzési rendszere, amely magában foglalja az URL és az URI szabványokat is. Addressing. [Elektronikus dokumentum.] URL: A letöltés időpontja

43 Az SGML/XML jelölésrendszer kódolás Külső és belső DTD deklarációt tartalmazó SGML/XML állományok szerkezeti váza A jelölésrendszer ismertetésének összegzéseként hangsúlyoznunk kell, hogy az SGML/XML-t sokféleképpen használhatjuk, így nem is tudtunk minden apróságra kitérni. Ennek ellenére bátran kijelenthetjük, aki figyelmesen áttanulmányozta a kapcsolódó témaköröket, az a gyakorlati alkalmazás során biztosan tisztában lesz a szövegjelölésnél használatos lehetőségekkel és szabályokkal. 33

44 4. fejezet - A DTD-k szerkezeti felépítése Az SGML szabvány és az XML ajánlás jelentős része a dokumentummodellezéssel foglalkozik. A DTD szolgálja azt a célt számunkra, hogy minden dokumentumunk megfelelhessen az előre meghatározott szabályoknak. Éppen ezért ebben a fejezetben a DTD-k céljával, hatáskörével és szintaxisával ismerkedünk meg. Ugyanakkor tudnunk kell azt is, hogy szövegjelölés esetén nem kell elsajátítani az általunk használt DTD vagy DTD-k szerkezeti felépítését ahhoz, hogy tökéletes munkát végezzünk, mivel e terhet az egyes szerkesztőeszközök leveszik a vállunkról! 1 Elég pusztán annyit tudni, hogy mely elemek milyen szövegrészek jelölésére szolgálnak és azokon belül milyen attribútum mely tulajdonság rögzítésére használható fel. 1. A DTD-kről általában Az SGML/XML nyelvek az állományok szerkezetének meghatározásához a dokumentumtípus fogalmát, és ezen keresztül a dokumentumtípus-definíciót vagy DTD-t használják. A dokumentumtípus meglehetősen összetett adatszerkezet, melyet formálisan mindig a feldolgozni kívánt szöveg/szövegek alkotóelemeivel és azok szerkezetével definiálunk. Típusdefiníció, amely leírja, hogy az adott dokumentumtípushoz tartozó dokumentumok milyen elemeket, attribútumokat, értékeket és hivatkozásokat tartalmazhatnak. Itt kell megadnunk a használatos karakterkészleteket, és azt, hogy az egyes elemek hogyan helyezkedhetnek el a dokumentumban. A DTD-vel adjuk meg a dokumentum hierarchikus szerkezetét is, így a dokumentumot leíró hierarchikus struktúra akár faszerkezetben is ábrázolható. Minden SGML dokumentumhoz tartoznia kell DTD-nek. A DTD elhelyezkedhet a dokumentum belsejében, de gyakoribb, hogy a dokumentumban csak egy hivatkozás található a DTD-re, amely külső fájlként helyezkedik el a rendszerben lásd.: Dokumentumtípus-deklaráció (DTD) c. alfejezet. Az SGML/XML dokumentumot helyesnek (valid) nevezzük, ha minden tekintetben megfelel a hozzá tartozó DTD-nek. XML esetében a DTD elhagyható, illetve helyettesítheti úgynevezett XML Schema. 2 Ha DTD-t készítünk, vagy előre legyártott szabványos DTD-t alkalmazunk, az abban szereplő kulcsszavak és szintaktikai egységek az alábbiak lehetnek: deklarációk; ELEMENT elem-típus deklarációk (element type declaration); ATTLIST attribútum-lista deklarációk (attribute-list declaration); ENTITY entitás deklarációk (entity declaration); NOTATION adatformátum deklarációk (notation declaration); paraméter-egyed definíciók és hivatkozások; feldolgozási utasítások; megjegyzések; A deklarációk szintaxisa XML esetén a következő formát ölti: <!kulcsszó név (tartalmi modell)> 1 Bonyolultabb DTD-k létrehozását, módosítását inkább bízzuk fejlesztőkre! 2 XML Schema XML szintaxist használó alkalmazási nyelv, amelynek a célja megegyezik a DTD céljával, tehát típusdefiníciók leírására szolgál. Kifejezetten az XML-hez készült, a DTD-nél egyszerűbb gépi au-tomatizmusok számára mindenképpen, ráadásul kínálja azt az előnyt, hogy XML szintaktikájú, tehát használatához a DTD-vel ellentétben nincs szükség új szintaxis megtanulására. XML Schema. [Elektronikus dokumentum.] URL: A letöltés időpontja

45 A DTD-k szerkezeti felépítése Ugyanez SGML-hez készült DTD-nél: <!kulcsszó név minimalizálási szabályok (tartalmi modell)> 1.1. Elem-típus deklarációk Az elemdeklarációk segítségével új elemet adhatunk meg, illetve meghatározhatjuk hozzá a megengedett elemtartalmat. A legkönnyebben úgy érthetjük meg a DTD-k szerkezeti felépítését, ha például megnézzük azt az erősen leegyszerűsített példát, amely a szövegjelölés során megismert versmodellünkön alapul: <!-- XML --> <!ELEMENT antologia (vers+) > <!ELEMENT vers (szerzo?, cim?, versszak+) > <!ELEMENT szerzo (#PCDATA) > <!ELEMENT cim (#PCDATA) > <!ELEMENT versszak (sor+) > <!ELEMENT sor (#PCDATA) > A fenti hat sor szemlélteti a formális XML elemdeklarációkat. A deklarációkat az elemekhez hasonlóan mindig csúcsos zárójelek fogják közre. A nyitó zárójelet ( < ) követő első karakter kötelezően egy felkiáltójel (! ), melyet valamely, az XML szabványban definiált kulcsszó követ jelen esetben ELEMENT, kijelölve, hogy milyen elem típusú objektumot deklarálunk. Maga a deklaráció XML esetén kettő részből áll: első helyen egy név szerepel, melyet a tartalmi modell követ. Ezek mindegyikét az alábbiakban tárgyalni fogjuk. A deklaráció egyes elemeit üres hely az angol terminológiában white space, azaz szóköz, tabulátor vagy sorvégjel új sor, vagy ezek tetszőleges kombinációja választja el egymástól. A deklarációk első része nemcsak XML, hanem SGML esetén is annak az elemnek az általános azonosítóját nevesíti, amelyet éppen deklarálunk, vagyis: antologia, vers, szerzo, cím, versszak és sor Minimalizálási szabályok SGML esetében az elemnév és a tartalmi modell közé ékelődik be az úgynevezett minimalizálási szabály, tehát a deklaráció második része az elemek minimalizálásával kapcsolatos szabályokat írja le. Ezek a szabályok határozzák meg, hogy az elem egyes előfordulási helyein a kezdő és a záró jelölőelemeknek szerepelniük kell-e. A minimalizálási szabály mindig két, egymástól üres hellyel (szóközzel) elválasztott karaktert tartalmaz, melyek közül az első a kezdő elemre, a második a záró elemre vonatkozik. A karakter mind a kezdő, mind a záró elem esetén: ( - ) (kötőjel, divíz), vagy egy ( O ) betű. A kötőjel azt jelzi, hogy az elemnek kötelező szerepelnie, az O betű az angol omissible (kihagyható) vagy optional (választható) értelmében azt jelzi, hogy az elemnek nem muszáj szerepelnie. Nézzük meg, hogy néz ki versmodellünk SGML DTD-je: <!-- SGML --> <!ELEMENT antologia - - (vers+) > <!ELEMENT vers - O (szerzo?, cim?, versszak+) > <!ELEMENT szerzo - O (#PCDATA) > <!ELEMENT cim - O (#PCDATA) > <!ELEMENT versszak - O (sor+) > <!ELEMENT sor - O (#PCDATA) > A példában minden elemnek kötelezően rendelkeznie kell egy kezdő jelölővel, viszont csak az <antologia> elemhez írtuk elő, hogy záró jelölőelem-párral szerepeljen. Emlékeztetőül a DTD alapján felépíthető SGML versmodell: 35

46 A DTD-k szerkezeti felépítése <!-- SGML --> <antologia> <vers> <szerzo>petőfi Sándor <cim>méz és csók <versszak> <sor>kis méh! te a füvet, fát, <sor>s virágokat leped, <sor>hogy édes kelyheikből <sor>gyüjthessed mézedet. <versszak> <sor>kis méh! Lidim füvet, fát <sor>s virágokat nem lep, <sor>mézednél csókja mégis <sor>mi sokkal édesebb. <!-- Antológiáról lévén szó, itt további versek következnek. --> </antologia> Tartalmi modell A deklaráció utolsó része, amely kerek zárójelek közt áll, az elem tartalmi modellje. Ez szabja meg, hogy az adott elem a dokumentumokban ténylegesen mit tartalmazhat. A tartalom, elsősorban más elemekkel való összefüggéssel, vagy különleges, a szabványban lefoglalt kulcsszavakkal adható meg. Több kulcsszó is létezik ezekkel a jellemző-lista deklarációknál foglalkozunk, melyek közül messze a leggyakrabban előforduló a PCDATA, amint példánkban is látható. Ez az angol Parsed Character Data kifejezés rövidítése, és azt jelenti, hogy a deklarálandó elem tetszőleges, elemzett karakteres adatot tartalmazhat. Ha a DTD szerkezetet úgy képzeljük el, mint egy családfát, melynek a tetején egyetlen ősapa van példánkban az <antologia>, akkor a fa ágait lefelé követve a végén majdnem mindig PCDATA tartalmat találunk. Példánkban a <szerzo>, <cim> és <sor> elemeket definiáltuk ily módon. A tartalmi modell különleges esete, amikor egy elem nem tartalmaz semmit pl. <sortores/>, ilyenkor a tartalmi modelljét az EMPTY (üres) kulcsszóval adjuk meg: <!ELEMENT sortores EMPTY> Ha egy elemen belül lehet gyermekelem, akkor a deklaráció rögzítheti a tartalmi modellcsoportot, vagy szerepelhet benne ANY kulcsszó is. Az ANY -t tartalmazó elem bármely más, a DTD-ben deklarált elemet tartalmazhat, ám éppen emiatt ritkán alkalmazzák, mert túl nagy szabadságot ad és egyúttal aláaknázza a dokumentumszerkezet definiálásából adódó előnyöket: <!ELEMENT sortores ANY> Előfordulási gyakoriság jelzése Példánk <versszak> elemének deklarációja kimondja, hogy egy versszak egy vagy több sorból áll. Annak jelzésére, hogy a tartalmi modellben megadott elem (<sor>) hányszor fordulhat elő, a deklaráció egy gyakoriságjelzőt, ebben az esetben + jelet használ. Az SGML/XML szintaxisban három gyakoriságjelző van, megegyezés szerint a ( + ) (plusz), a (? ) (kérdőjel) és a ( * ) (csillag). Jelentésük az alábbi: + (plusz): a kérdéses elem legalább egyszer, de akár többször is előfordulhat; 36

47 A DTD-k szerkezeti felépítése? (kérdőjel): a kérdéses elem legfeljebb egyszer fordulhat elő (tehát lehet, hogy egyszer sem); * (csillag): a kérdéses elem vagy egyszer sem, vagy egyszer, vagy akár többször is előfordulhat; Így tehát ha a <versszak> tartalmi modellje (sor*) lenne, akkor olyan versszakok is előfordulhatnának, amelyek egyáltalán nem tartalmaznak sorokat, és olyanok is, amelyek egynél több sort tartalmaznak. Ha pedig a tartalmi modell (sor?) lenne, megint előfordulhatnának üres versszakok, de egyetlen versszak sem tartalmazhatna egynél több sort. A bemutatott versmodell DTD deklarációja szerint az antológia mindig egy vagy több verset tartalmaz. A versnek nem lehet egynél több szerzője és címe, de előfordulhat az is, hogy egyik sincs. Egy vers mindig egy vagy több versszakból áll, mely versszakok szintén egy vagy több sort tartalmazhatnak Sorrendiség, csatolójelek Mivel <vers> elemünk tartalmi modellje (szerzo?, cim?, versszak+) egynél több komponenst tartalmaz, ezért további finomításra van szükség, hogy megmondjuk, a <szerzo>, <cim> és <versszak> közül melyik milyen sorrendben szerepelhet. Ezt a sorrendiséget az összetevők közti csatolójel jelen esetben a (, ) vessző határozza meg. SGML-ben három, XML esetében pedig kettő lehetséges csatolójel van, megegyezés szerint a (, ) (vessző), a ( ) (függőleges vonal) és az ( & ) (és-jel) ez utóbbi csak SGML-nél használható:, (vessző): az általa összekapcsolt összetevők megfelelnek annak a sorrendnek, amelyben a dokumentumban megjelennek; (függőleges vonal): az általa összekapcsolt összetevők közül csak az egyik jelenhet meg; & (és jel): mindkét általa összekapcsolt összetevőnek meg kell jelennie, de sorrendjük tetszőleges lehet. Ha a vers elemünknél a vessző helyett az &-jel szerepelne, a szerző és a cím akár a versszakok előtt és után is megjelenhetne, de nem szerepelhetne a versszakok közt szembetűnő az SGML DTD nyújtotta lazaság. Abban az esetben, ha a vessző helyett a függőleges vonal szerepelne, akkor a vers vagy egy szerzőt, vagy egy címet, vagy pedig versszakokat tartalmazna, de nem együtt! Vegyük észre, hogy az eddig tárgyalt struktúránk egyszerű hierarchikus elrendezésű volt, tehát a fa bármely szintjén minden egyes elem teljesen benne volt a szülő elemében. Az alábbi ábra bemutatja annak a dokumentumnak a szerkezetét, amely megfelel az eddig definiált DTD szerkezetnek. Korábban már láttuk, hogyan lehet a példánkban szereplő költeményt szerzőre, címre és két négysoros versszakra osztani. Az alábbi ábrába felvettünk még egy verset, amely címből és egy versszakból áll, így téve teljesebbé az antológiánkat: Az antológia DTD-jének fa-szerkezete SGML nyelvben különösen, de XML használatakor is létrehozhatunk a bemutatottaknál sokkal bonyolultabb tartalmi modelleket, de ezek ismertetésétől itt és most eltekintünk. Annyit azonban még fontos megemlíteni, 37

48 A DTD-k szerkezeti felépítése hogy akik SGML-lel dolgoznak, azok a kapcsolódó DTD használatakor tartalmi modellekben elhelyezett kivételkezeléssel is találkozhatnak ezt a funkciót az XML DTD-khez már nem implementálták Attribútum-lista deklarációk Egyes SGML/XML-elemek attribútumokkal is rendelkeznek. Az attribútumok melyek önmagukat tekintve nem részei az elemeknek további információval szolgálnak az elemről, vagy annak tartalmáról. Minden egyes attribútumot az elemtől függetlenül, de vele összefüggésben kell deklarálni. A DTD-kben a jellemzőket az ATTLIST deklarációval adhatjuk meg. Az attribútum-deklaráció az alábbi szerkezet szerint épül fel: <!ATTLIST elem-név attribútum-név attribútum-típus alapérték> A szintaxis jól mutatja, hogy mindenképpen meg kell adnunk az attribútum nevét és azt az elemet, amelyhez kapcsolódik, emellett lehetőségünk van arra is, hogy bizonyos korlátok között megadjuk, milyen értéket vehet fel az attribútum, mi a kezdőértéke és az alapértelmezése. Amikor például <vers> elemünket azonosító és státusz attribútumokkal bővítettük <vers azon="v1" statusz="publikalt">, akkor ahhoz, hogy ezek a jellemzők az SGML/XML dokumentumban érvényesek legyenek, a DTD-ben attribútumként definiálni kell őket, mégpedig az elemdeklarációval összefüggésben, az alábbi módon: <!ELEMENT vers (szerzo?, cim?, versszak+) > <!ATTLIST vers azon ID #IMPLIED statusz (vazlat jovahagyott publikalt) "publikalt"> A deklaráció az ATTLIST kulcsszóval kezdődik, ez nyitja meg az attribútum-lista deklarációt. Az első része azt az elemet nevezi meg, amelyhez az attribútum kapcsolódhat példánkban csak a <vers> elemhez csatoltunk attribútumot. A nevet követően soronként egy-egy attribútumot deklaráltunk, amely három részből áll: az attribútum nevéből, az általa felvehető érték típusából és az alapértelmezett értékből. Megj.: Az attribútum nevére példánkban az azon és a statusz ugyanolyan megszorítások vonatkoznak, mint a nevekre általában az SGML/XML-ben: nem kell egyedieknek lenniük a teljes DTD-ben, csak az adott elemre vonatkozó attribútum-listában. Az attribútum deklaráció harmadik része az attribútum-típus. Itt bizonyos kulcsszavak közül adunk meg egyet, amely meghatározza, hogy az attribútum milyen típusú értéket vehet fel. A fenti példában az ID kulcsszót használtuk annak jelzésére, hogy az azon nevű attribútum minden egyes vershez egy egyedi azonosítót rendeljen. Természetesen más kulcsszavak is léteznek ezekben az SGML és XML között néhol különbségek vannak. Az alábbiakban összegyűjtöttük az összes lehetséges kulcsszót és megfeleltettük a két nyelvben használatosakat egymásnak: 4.1. táblázat - Kulcsszavak SGML/XML-ben SGML XML Értelmezés CDATA CDATA Az attribútum csak karakteres adat lehet. Ezt az adattípust az értelmező nem dolgozza fel, változatlan formában átengedi az ellenőrzésnél. ENTITY ENTITY Az attribútumban egy entitásra vonatkozó hivatkozás található. 38

49 A DTD-k szerkezeti felépítése ENTITIES ENTITIES Több entitást is meg lehet adni referenciaként. Az egyedeket egy listában, egymástól térköz karakterekkel elválasztva kell megadni. ID ID Az attribútum egyedi azonosító, mely a dokumentum egy meghatározott pontját adja meg. IDREF IDREF Az attribútum referenciát tartalmaz egy ID-re, mely a DTD egy más pontján van deklarálva. (Az ID-ket a dokumentum tartalmának hiperhivatkozásokkal való jelölésére használhatjuk.) IDREFS IDREFS Olyan, mint az IDREF, de itt az attribútum ID-k egy listáját tartalmazza. NAME NMTOKEN Az attribútum értéke lehet bármilyen szó vagy lexikális elem szám, betű, írásjelek (kötőjel, kettőspont, aláhúzásjel). NAMES NMTOKENS Egymástól szóközzel elválasztott NMTOKEN értékek listája. NMTOKEN NMTOKENS NUMBER NUMBERS NUTOKEN NUTOKENS NMTOKEN NMTOKENS NMTOKEN NMTOKENS NMTOKEN NMTOKENS NOTATION NOTATION Az attribútum értéke egy NOTATION adattípus, melynek deklarációja a DTD egy másik pontján helyezkedik el. Felsorolás Felsorolás A lehetséges értékek egy listáját tartalmazza. A listát zárójelek közt kell elhelyezni, ahol az adatok függőleges vonallal vannak elválasztva egymástól. A konkrét érték mindig a felsorolás valamelyik eleme kell, hogy legyen. 39

50 A DTD-k szerkezeti felépítése A minta attribútum deklarációnkban felsoroltuk a statusz attribútum lehetséges értékeit. Ez teszi lehetővé, hogy az SGML/XML elemző ellenőrizze, ne definiáljunk úgy egy <vers> elemet, hogy annak statusz attribútuma fel ne venné a "vazlat", "jovahagyott", "publikalt" értékek valamelyikét. Az attribútum definíció utolsó eleme azt jelzi az értelmezőprogram számára, hogy mit kell tennie az adott attribútum hiánya esetén. Ezt úgy jelöljük, hogy vagy az alább felsorolt kulcsszavak valamelyikét adjuk meg, vagy azt az attribútumértéket, amelyet alapértelmezett értékként minden olyan elem visel majd, amelynél nem szerepel más, előre megadott attribútumérték. Példánkban, ha egy vers jelölésekor csak a <vers> elemet adjuk meg, az értelmező pontosan ugyanúgy fogja kezelni, mintha az elem a <vers statusz="publikalt"> alakot öltötte volna. A deklarációban az attribútum-típust követően egy kulcsszó is szerepelhet, mely az attribútum alapértelmezett értékének jelölésére szolgál. Ezek a kulcsszavak az alábbiak lehetnek: #REQUIRED (kötelező): Mindenképpen meg kell adnunk valamely értéket; #IMPLIED (hallgatólagos, bennfoglalt): Nem muszáj megadnunk értéket ilyen például az előzőekben az ID esete; #FIXED (rögzített): jelzi, hogy az attribútum neve után megadott érték rögzített, tehát nem változik, állandó; #CURRENT (aktuális, legutóbbi): Ha az adott elemnél nem adunk meg attribútumot, akkor az attribútum az ilyen típusú elemnél legutóbb megadott attribútumértéket veszi fel; 3 Miután áttekintettük az attribútum-deklarációk szintaxisát, nézzünk meg néhány egyszerű példát. Tegyük fel, hogy feldolgozás során olyan listát szeretnénk kódolni, melynek elemei előtt a felsorolások egyik leggyakoribb szimbóluma, a disk szerepel alapértelmezettként. Mindemellett jó lenne, ha listánk lehetőséget biztosítana decimális decimal és nagybetűs római upper-roman számozásra, illetve jelöletlen felsorolás none készítésére is: <!ELEMENT lista (elemertek, elemertek+)> <!ATTLIST lista tipus (disk decimal upper-roman none) "disk"> <!ELEMENT elemertek (#PCDATA)> <lista> <elemertek>deklarációk;</elemertek> <elemertek>feldolgozási utasítások;</elemertek> </lista> deklarációk; feldolgozási utasítások; Példánkban a <lista> kettő vagy több <elemertek>-et tartalmazhat. Ezt a megszorítást azért tettük, mert úgy véljük, felsorolást csak abban az esetben szabad használni, ha annak legalább két eleme van. A tartalmi modellben tehát beállítottuk, hogy a <lista> tartalmazhasson egy <elemertek> elemet, majd ezt kövesse a vessző (, ) jel miatt egy vagy több <elemertek> a plusz ( + ) jel miatt. A <lista> elem kapott egy tipus attribútumot, ami a felsorolt értékek valamelyikét veheti fel a függőleges vonal ( ) jel miatt, a "disk" pedig alapértelmezett. Mindez azt eredményezi, hogy listatípus beállításának elmaradása esetén körrel jelölt lesz a felsorolás. Az <elemertek> tartalma bármilyen normál, feldolgozható karakteres adat lehet #PCDATA Attribútum-minimalizálás 3 A #CURRENT kulcsszó kizárólag SGML-ben használható! 4 PCDATA Parsable Character Data (feldolgozható karakteres adat) Normál karakteres adatokat jelölő kulcsszó. Mindig megelőzi a kettőskereszt karakter, így nem összekeverhető egy modellcsoporton belüli azonos elemnévvel. Pl.: (#PCDATA PCDATA)*. 40

51 A DTD-k szerkezeti felépítése Abban az esetben, ha valamely attribútum értéke egyetlen számra vagy szóra korlátozódik, nem szükséges idézőjelet használnunk, mivel a következő relációs jel vagy szóköz egyértelműen zárja az értéket: 5 <!-- SGML --> <!ELEMENT bekezdes (...tartalmi modell helye...)> <!ATTLIST bekezdes fuggo NUMBER 0 behuzas ( ) #IMPLIED> <bekezdes fuggo=10 behuzas=5> </bekezdes> <!-- XML --> <!ELEMENT bekezdes (...tartalmi modell helye...)> <!ATTLIST bekezdes fuggo NMTOKEN "0" behuzas ( ) #IMPLIED> <bekezdes fuggo="10" behuzas="5"> </bekezdes> Ez a bekezdés 10 pontos függő behúzást tartalmaz, ráadásul az első sor 5 ponttal beljebb kezdődik a többinél. A fuggo tulajdonság bármilyen számértéket felvehet, de alapértelmezetten 0 értéket adtunk neki. A számértékekhez természetesen tetszőleges mértékegységek társulhatnak, melyeket a megjelenítésért felelős stíluslapban kell beállítani. Ha az attribútum-típus értéket tovább korlátozzuk egy szócsoportról egyetlen szóra, akkor névcsoportképzésről beszélünk. A következő példában listánkhoz rendelünk egy eltolas tulajdonságot, amely igen vagy nem értéket vehet fel ezt a már ismertetett módon beállíthatjuk a DTD-ben. Ebben az esetben az attribútum neve és az egyenlőségjel (értékjelölő) ( = ) elhagyható: <!-- SGML --> <lista igen> <!-- XML --> <lista eltolas= igen > </lista> Attribútum-öröklődés Az attribútumérték örökölhető a jellemző előző megjelenésétől. Ez akkor lehet hasznos, ha az érték csak alkalmanként változik, hiszen így nem kell minden egyes elem esetében megadni ugyanazt a tulajdonságot. 6 A deklarációban ennek alkalmazására használható a #CURRENT kulcsszó. Az alábbi példában a második és harmadik bekezdés örökölten angol nyelvű, ám az ötödik már magyar: <!-- SGML --> <bekezdes nyelv= en >English paragraph.<bekezdes> <bekezdes>english paragraph.<bekezdes> <bekezdes>english paragraph.<bekezdes> <bekezdes nyelv= hu >Magyar bekezdés.<bekezdes> <bekezdes>magyar bekezdés.<bekezdes> 5 Az attribútum-minimalizálás az SGML nyelv tulajdonsága, XML-ben nem használható! 6 Az attribútum-öröklődés szintén SGML specifikus tulajdonság, XML-ben nem alkalmazható! 41

52 A DTD-k szerkezeti felépítése [Megj.: Amennyiben XML-t használunk, úgy bekezdésenként meg kell adni a nyelvi tulajdonságot és az értéket. Ennek kiküszöbölésére alkalmazhatjuk azt a megoldást, hogy egy szülőelemben állítjuk be a nyelvet így az összes gyermekelem örökli a tulajdonságot. Ahol pedig ettől el akarunk térni, ott helyben az adott elemhez társítjuk a nyelv beállítását.] 1.3. Entitás deklarációk Az SGML/XML nyelv jelölésrendszerével foglalkozó fejezetben elméleti szinten már megismerkedtünk az entitások (egyedek) jelentőségével, tehát itt az ideje, hogy azt is megtudjuk, hogyan kell használni őket. Mielőtt azonban ismertetnénk őket, tisztázzuk, hogy milyen típusaik léteznek: általános entitások; belső entitás-deklarációval megadott entitások; külső entitás-deklarációval megadott entitások; paraméter entitások; Általános entitások Entitás lehet egyszerűen karakterfüzér, de lehet egy teljes szöveges állomány is. Ahhoz, hogy az entitást behelyezzük a dokumentumba, az entitáshivatkozásnak nevezett szerkezetet használjuk. Ez a hivatkozás lehet belső, illetve külső forrásra utaló is Belső entitás deklaráció Belső entitás deklaráció szintaxisa mindkét nyelv esetében a következőképpen néz ki: <!ENTITY entitás-név "entitás-érték"> Adjunk meg egy olyan entitást, amelynek neve BHI, értéke pedig a Bibliotheca Hungarica Internetiana karakterfüzér. <!ENTITY BHI "Bibliotheca Hungarica Internetiana"> Ez a sor egy olyan belső entitást deklarál, mely létrehoz egy BHI nevű egyedet, amit az SGML/XML szövegben meghívhatunk és így létrejöhet a szöveghelyettesítés karakterentitás-hivatkozások esetében is ugyanez érvényesül. Magyarul, ha az entitást egyszer már deklaráltuk, a dokumentumon belülről bárhonnan hivatkozhatunk rá. Ezt úgy kell megtennünk, hogy az entitás nevét egy és jel ( & ), valamit egy pontosvessző ( ; ) közé írjuk. Amikor az SGML/XML értelmező egy ilyen entitáshivatkozást talál, erre a helyre azonnal behelyettesíti az entitás deklarációjánál megadott tartalmat/értéket. Vagyis, ha az entitáshivatkozást tartalmazó példamondatunk így hangzana: &BHI; - Magyar Szövegtár. akkor ezt az értelmező az alábbiak szerint bontaná ki: 42

53 A DTD-k szerkezeti felépítése Bibliotheca Hungarica Internetiana Magyar Szövegtár Külső entitás deklaráció Külső entitás deklaráció szintaxisa SGML/XML esetén az alábbi formát ölti: <!ENTITY entitás-név SYSTEM "URI/URL"> Ugyanez, konkrét példával alátámasztva: <!ENTITY FejKetto SYSTEM "xml2.txt"> Az előbbi deklaráció egy külső, más néven rendszer-entitást határoz meg, amelynek neve FejKetto úgy, mint második fejezet, értéke pedig az a szöveg, amelyet a rendszerazonosítóval kapcsoltunk össze jelen esetben a rendszerazonosító egy operációs rendszerbeli szövegállomány neve (xml2.txt), és az entitáshivatkozás során ennek a szövegállománynak a tartalmát helyettesítjük be. A rendszer-entitások esetében természetesen az adott operációs rendszerbeli állomány tartalma kerül behelyettesítésre, tehát a következő példamondat: Az alábbi szöveget behelyettesítettük: &FejKetto; úgy kerülne kibontásra, hogy a teljes xml2.txt szövegállomány tartalma behelyettesítődne az entitáshivatkozás helyére. URL megadása esetén is hasonlóképpen működik a dolog, csak itt a bemásolandó adatokat az entities.xml fájl tartalmazza: <!ENTITY egyedek SYSTEM " Összefoglalva tehát: a külső egyedek lehetővé teszik, hogy másik fájl tartalmára hivatkozzunk az SGML/XML dokumentumból, így tartalmazhatnak szöveges és bináris adatot is. Ha a külső állomány szöveges adatot tartalmaz, akkor az eredeti dokumentumba illesztődik a referencia helyére, és úgy kerül feldolgozásra, mintha a hivatkozó dokumentum része lenne. A bináris adatokat értelemszerűen nem elemzi az értelmező Paraméter-entitások Ha a DTD egy összetett részét több helyen is szerepeltetni kívánjuk a fájlban, akkor szokás a kérdéses részt egy paraméter-egyeddel vagy más szóval paraméter-entitással helyettesíteni. Deklarációja után az egyedre a DTDn belül bárhonnan lehet hivatkozni. A paraméterentitások használatával a DTD-k sokkal könnyebben olvashatóvá és egyszerűbben szerkeszthetővé válnak. A deklaráció az általános entitások deklarációjához nagyon hasonlít, de itt az ENTITY kulcsszó és az entitás neve közé még egy százalékjelet ( % ) is beszúrunk. A százalékjel mindkét oldalán üres helynek szóköznek, tabulátor-karakternek vagy sortörésnek kell lennie. Nézzünk egy nagyon egyszerű példát: 43

54 A DTD-k szerkezeti felépítése <!ENTITY % igazitasok "kozep bal jobb"> <!ELEMENT bekezdes (...tartalmi modell helye...)> <!ATTLIST bekezdes igazitas (%igazitasok; sorkizart) "sorkizart"> Jól látszik, hogy a bekezdés lehetséges igazításait paraméter-entitásként definiáltuk. Ennek az a rendkívül nagy előnye, hogy a DTD bármely más részén, ahol szükségünk van ezekre az értékekre mondjuk egy kép igazításához ott ugyanígy hivatkozhatunk rájuk. A globálisan, több elemben használatos attribútumokat tehát ildomos egyetlen paraméter-entitásban definiálni, így bármelyik elem attribútum-listájába beépíthetőek lesznek. Sőt, nem árt tisztában lenni azzal a lehetőséggel sem, hogy paraméter-entitások definiálásakor más, már korábban létrehozott paraméter-egyedeket is meghivatkozhatunk ezzel mégjobban kibővítve a rendelkezésre álló jellemzők listáját. Példával illusztrálva: <!-- XML --> <!ENTITY % link "...jellemzők, értékek és kulcsszavak helye..."> <!ENTITY % term "...jellemzők, értékek és kulcsszavak helye..."> <!ENTITY % global " %term; %link; azonosito ID #IMPLIED nyelv (en de hu) #IMPLIED betumeret ( ) #IMPLIED betukoz (normal ritka suru) #IMPLIED igazitas ( bal jobb kozep sorkizart) #IMPLIED balmargo NMTOKEN #IMPLIED jobbmargo NMTOKEN #IMPLIED behuzas NMTOKEN #IMPLIED kover (0 1) #IMPLIED dolt (0 1) #IMPLIED alahuzott (0 1) #IMPLIED rejtett (0 1) #IMPLIED fuggo NMTOKEN "0" "> <!ELEMENT bekezdes (...tartalmi modell helye...)> <!ATTLIST bekezdes %global;> <!ELEMENT kiemeles (...tartalmi modell helye...)> <!ATTLIST kiemeles %global;> <bekezdes nyelv= hu igazitas= sorkizart jobbmargo= 10 >Ebben a bekezdésben a paraméter-entitásként létrehozott globális attribútumok használatára látunk példát. <kiemeles kover= 1 >A szerkezet SGML-ben is ugyanígy használható, mindössze az NMTOKEN kulcsszavakat NUMBER-re kell átírni.<kiemeles></bekezdes> Ebben a bekezdésben a paraméter-entitásként létrehozott globális attribútumok használatára látunk példát. A szerkezet SGML-ben is ugyanígy használható, mindössze az NMTOKEN kulcsszavakat NUMBERre kell átírni. Előre elkészített, nemzetközileg is elfogadott szabványos DTD-kben rengeteg paraméter-egyeddel találkozhatunk ilyen pl. a következő fejezetekben tárgyalt TEI, illetve DocBook is. Ennek oka, hogy ezek a dokumentumtípus-definíciók rendkívül összetettek, ráadásul több 10 különálló DTD-t tartalmazó állományból 44

55 A DTD-k szerkezeti felépítése tevődnek össze, melyekben egymásra való hivatkozások találhatók. Az ilyen rendszerek szerkesztése értelemszerűen sokkal könnyebb paraméter-entitásokkal Megjelölt részek Ha paraméter-egyedekkel foglalkozunk, akkor szembekerülhetünk olyan megoldásokkal is, mint amilyen az alábbi: <!ENTITY % NEUMANN.bevitel "INCLUDE"> <![ %NEUMANN.bevitel; [ <!-- Ide kerülnek az egyes elemek paraméter entitásai. --> <!ENTITY % bekezdes "INCLUDE"> <!ENTITY % sortores "INCLUDE"> <!ENTITY % kiemeles "INCLUDE"> <!ENTITY % lista "INCLUDE"> <!ENTITY % listaelem "INCLUDE"> "..." Ez a deklaráció elsőre szokatlannak tűnhet az eddig tanultak alapján, ezért megértéséhez beszélnünk kell az ún. megjelölt részekről, melyek szintén a DTD-ben kapnak helyet, és szorosan a paraméter entitásokhoz kapcsolódnak. Alkalmanként kényelmes lehet, ha bizonyos szövegrészeket meg tudunk jelölni valamely különleges kezelés céljából. Például az Egyesült Államokban bizonyos szövegformulákat szisztematikusan be kell helyezni a jogi szövegbe, vagy ki kell venni onnan, annak függvényében, hogy melyik államra vonatkozik a szöveg. (Például: A felelősség felső határa $ szöveget be kell helyezni Delaware állam esetén, de ki kell hagyni Maryland állam esetén.) Bizonyos hasonló termékek műszaki kézikönyvei például sok egyforma információt tartalmazhatnak, de bizonyos részekben különbözhetnek. Hasznos lehet tehát, ha a rokon termékekre vonatkozó teljes információmennyiséget egyetlen dokumentumban foghatjuk össze, és csak megjelenítéskor vagy nyomtatáskor választjuk ki az éppen aktuális termékre vonatkozó részeket. [Megj.: Az SGML/XML a megjelölt részek mechanizmusával kezeli a dokumentumgyártás ehhez hasonló gyakorlati követelményeit. Általánosságban igaz, hogy amint azt a fenti példa már sugallja, ennek a módszernek nyilvánvalóbb a haszna új szövegek létrehozásakor, mint régi szövegek újrafeldolgozásakor. A szövegkódolók többsége valószínűleg nem találkozik majd a megjelölt részek mechanizmusával, de mivel a nagy szövegjelölési rendszerek DTD-i kiterjedten alkalmazzák, ennek ismerete is fontos lehet.] Az SGML/XML által a megjelölt részek feldolgozására rendelkezésre álló különleges kezelés többféle is lehet, és mindegyikhez az alábbi kulcsszavak valamelyikét rendelhetjük: 7 INCLUDE (bennfoglalás): a megjelölt részt be kell helyezni a dokumentumba, és szokásos módon fel kell dolgozni; IGNORE (kihagyás): a megjelölt részt teljesen ki kell hagyni a dokumentumból; ha az SGML feldolgozóprogram a dokumentumból például nyomtatott formátumot készít, a megjelölt rész nem szerepelhet a keletkező termékben; CDATA (karakteres adat): a megjelölt rész olyan karakterfüzéreket és kódrészleteket is tartalmazhat, amelyek úgy néznek ki, mint az érvényes SGML/XML tegek vagy entitás-hivatkozások, de a CDATA kulcsszóval megjelölt részben a tegeket és az entitásokat a feldolgozó programnak nem szabad felismernie és értelmeznie. (Például így vihetünk be a szövegbe a nyelvet magyarázó program- vagy kódrészleteket.) RCDATA (karakteres adat referenciával): a megjelölt rész olyan karakterfüzéreket és kódrészleteket is tartalmazhat, amelyek úgy néznek ki, mint érvényes SGML tegek, de az RCDATA kulcsszóval megjelölt 7 HALPERN-HAMU, Charlie: Using an XML Audit to Move SGML Data towards XML. [Elektronikus dokumentum.] URL: A letöltés időpontja

56 A DTD-k szerkezeti felépítése részben a tegeket az SGML feldolgozónak nem szabad felismernie és értelmeznie. Másrészről viszont az RCDATA által megjelölt rész tartalmazhat entitás-hivatkozásokat, amelyeket a feldolgozóprogramnak a szokásos módon fel kell ismernie és be kell helyettesítenie. 8 TEMP (ideiglenes): az ilyen módon megjelölt rész csak ideiglenesen van benne a dokumentumban. A jelölés elsődleges célja az, hogy az ideiglenes részek előfordulási helyét könnyen lehessen azonosítani, és amikor kell, egyszerűen el lehessen távolítani, vagy kényelmesen át lehessen dolgozni. 9 A szövegben a megjelölt rész kezdetét és végét egy-egy különleges karakterfüzér jelzi. A megjelölt rész kezdetén szerepel az az egy vagy több kulcsszó a fentiek közül, amely a megjelölt szöveg kezelését írja elő. Példánkban a megjelölt szövegrészt ki kell hagyni: Ezekben az esetekben a bank megtéríti az ügyfél kárát. <![ IGNORE [A felelősség felső határa dollár.]]> A komplex nemzetközi DTD-k megértéséhez a legfontosabb két kulcsszó az INCLUDE és az IGNORE. Ezekkel lehet bevonni a feldolgozásba, vagy abból kihagyni bizonyos szövegrészeket vagy akár egy DTD-t is. Ily módon az adott körülményekhez alkalmazkodhatunk (például egy felhasználó kiválaszthatja a DTD-nek azt a részét, ami az általa vizsgált dokumentumra vonatkozik). Fontos, hogy maguk a betű szerinti INCLUDE és IGNORE kulcsszavak kevésbé használatosak a DTD vagy a dokumentum testre szabásában. Például ahhoz, hogy a fenti példában a megjelölt részt mégis inkább befoglaljuk a szövegbe, a felhasználónak kézzel meg kellene nyitni a dokumentumot, és ki kellene cserélni az IGNORE kulcsszót INCLUDE-ra. Ez semmivel sem lenne egyszerűbb, mint magát a kérdéses szövegrészt teljes egészében törölni vagy behelyezni. Szerencsére a kulcsszavakat nem kell betű szerint beírnunk, hiszen remekül felhasználhatunk helyettük egy paraméter-entitást. Ha például egy dokumentumban sok olyan rész van, amelyet csak Maryland állam esetén kell belefoglalni, akkor minden ilyen mondatot egy megjelölt részben helyezhetünk el, amelynek kulcsszavát egy Maryland nevű paraméter-entitásra történő hivatkozás képviseli. Ekkor az előző példa az alábbi alakot öltené: Ezekben az esetekben a bank megtéríti az ügyfél kárát. <![ %Maryland; [A felelősség felső határa dollár.]]> Ha a Maryland nevű entitás értékét IGNORE-ként definiáljuk, a megjelölt szakasz kimarad a dokumentumból. Ha viszont a definíciót az alábbiak szerint változtatjuk meg, a megjelölt rész bekerül a dokumentumba: <!ENTITY % Maryland "INCLUDE"> Amikor a paraméter-entitásokat ilyen módon használjuk a DTD megjelölt részeinek vezérlésére, akkor a külső vagy belső DTD állomány rendszerint megad valamely alapértelmezett, kezdeti értéket. Ha a felhasználó ezt az alapértelmezett értéket felül kívánja bírálni mint a Maryland-ről szóló példában, elég, ha a saját DTD részkészletében beírja a megfelelő deklarációt, ezzel máris eléri célját. Most már jobban érthető az alfejezet elején bemutatott példa is: 8 Az RCDATA kulcsszó kizárólag SGML-ben használható! 9 A TEMP kulcsszó kizárólag SGML-ben használható! 46

57 A DTD-k szerkezeti felépítése <!ENTITY % NEUMANN.bevitel "INCLUDE"> <![ %NEUMANN.bevitel; [ <!-- Ide kerülnek az egyes elemek paraméter entitásai. --> <!ENTITY % bekezdes "INCLUDE"> <!ENTITY % sortores "INCLUDE"> <!ENTITY % kiemeles "INCLUDE"> <!ENTITY % lista "INCLUDE"> <!ENTITY % listaelem "INCLUDE"> "..." A deklaráció hatására minden olyan megjelölt rész, amely a NEUMANN.bevitel-lel kapcsolatos, bekerül a DTDbe tehát használhatóvá válik a szövegjelölés során, mivel a külső vagy belső DTD állomány(ok)ban ezek a részek olyan módon vannak megjelölve, hogy használatukat a NEUMANN.bevitel paraméter-entitással szabályozhatjuk. A bekezdés paraméter-entitásként való deklarációja például a következőképpen bontható ki: <!-- XML --> <!ENTITY % bekezdes "INCLUDE" > <![ %bekezdes; [ <!ELEMENT %bekezdes; "..."> <!ATTLIST %bekezdes; behuzas NMTOKEN "5" %a.global;> ]]> Ha tehát úgy döntünk, hogy ezentúl nem akarjuk jelölésrendszerünkben használni a <bekezdes> elemet, akkor annak paraméter-egyed definíciójában egyetlen elegáns mozdulattal ignorálhatjuk minden tulajdonságával együtt NOTATION deklarációk Amikor valamely egyed nem SGML/XML adatot tartalmaz, akkor a feldolgozóprogramnak fel kell ismernie az adott objektum típusát, és hogy miként ágyazza be az adott dokumentumba, vagy hogy egyáltalán mit is kezdjen vele. Bár a NOTATION deklaráció rendszerint magát az adatot vagy adatokat feldolgozó alkalmazást adja meg, nem kötelező a használata. Még ha meg is adunk egy alkalmazást, az egyáltalán nem jelenti azt, hogy kezelni is tudja az adatainkat. Az alábbiakban bemutatunk egy egyszerű példát NOTATION használatára, ahol a megadott program egy képfájlt dolgoz fel: <!NOTATION PNG SYSTEM /usr/bin/display > <!ENTITY nemzetimuz SYSTEM NDATA PNG> <kep entity= nemzetimuz hely= kozep > <kepleiras>magyar nemzeti Múzeum</kepleiras> </kep> 47

58 A DTD-k szerkezeti felépítése SYSTEM típusú definíciót kell tennünk minden saját formátumhoz és természetesen a feldolgozás folyamán az eszközöknek ennek segítségével kell definiálni a kezelés módját. Amennyiben egy ismert és definiált formátumot akarunk felhasználni, akkor a PUBLIC kulcsszót ajánlott alkalmazni, mivel így egyértelműen azonosítható a hivatkozott fájl formátuma: <!NOTATION BMP PUBLIC "+//ISBN ::Graphic Notation//NOTATION Microsoft Windows Bitmap//EN"> <!ENTITY vetitogep SYSTEM../kepek/vetitogep.bmp NDATA BMP> <kep entity= vetitogep hely= kozep > <kepleiras>magyar mozgó és diafilm-vetítő gép.</kepleiras> </kep> [Megj.: PUBLIC kulcsszó használatakor az értékadás elején plusz + vagy mínusz - jel szerepelhet. Az előbbi hivatalosan is bejegyzett azonosítóra utal.] 48

59 5. fejezet - Szövegjelölés TEI DTD alapján Az SGML/XML, ahogyan nevük is mutatja, a jelölések általános és bővíthető célú formáját képviselik, mégpedig DTD-k, XML esetében pedig DTD-k vagy Schema-k felhasználásával. Mivel sokan, sok projektben szeretnék ugyanazokat a feladatokat végrehajtani, ráadásul a dokumentumokat is hasonló módon szeretnék strukturálni, néhány DTD már évek óta egyre szélesebb körben terjed és de facto szabvánnyá vált. A szövegfeldolgozás területén az egyik ilyen nemzetközileg elfogadott jelölésrendszer a TEI nevet viseli. 1. TEI A TEI 1 (Text Encoding Initiative - Szövegkódolási Kezdeményezés) fontos nemzetközi projekt, amelyet ben három számítógépes nyelvészeti és irodalmi kutatásokkal foglalkozó angolszász tudományos társaság, az Association for Computers and the Humanities (ACH), az Association for Computational Linguistics (ACL), és az Association for Literary and Linguistic Computing (ALLC) indított el. A projekt feladata irányvonalak kifejlesztése, terjesztése volt a géppel olvasható szövegek kódolására, közvetíthetőségére, és cserélhetőségére, valamint javaslatok tétele új szövegek kódolására. A TEI fejlesztésében mára számos tudományos társaság és tanszék vállal szerepet, évente konferenciákat tartanak, az egyes részterületeket például a kéziratok kritikai kiadását vagy a karakterkódolást munkabizottságok vizsgálják. A közös munka eredménye mindig egy DTD, vagyis dokumentumtípusdeklaráció, amely a nyelv jelölőelemeit és egymáshoz való viszonyukat határozza meg. A TEI-t elsősorban általános tartalmú szövegek, szépirodalmi művek, kritikai kiadások, történeti források, illetve élőszöveg átiratok elektronikus feldolgozására alkalmazzák. Megjelenése óta 4 verzióját adták ki, ezek közül a legutóbbi TEI P4, mely 2002-ben jelent meg már tartalmazza az XML támogatást is, tehát a DTDnek az SGML mellett egyaránt létezik XML és XML Schema változata. Jelenleg a TEI P5-ös verzióján dolgoznak a szakemberek 2, melyből egy nem végleges dokumentáció már el is érhető az iniciatíva honlapján. [Megj.: Jóllehet nem tartozik szorosan a témához, de mindenképp meg kell említenünk, hogy a TEI új honlapja már TEI alapú XML-ben jelölten készült és ugyanazt az Apache Cocoon nevű ingyenes XML publikáló tartalom-szolgáltatási keretrendszert használja, amire a Neumann-ház alapozta új intézményi weblapjának működését.] A TEI 2000-től konzorciális keretek között működik, ráadásul az USA és Kanada kormányzati támogatását is élvezi. Az ajánlások noha teljesen hozzáférhetőek nem könnyű olvasmányok, megismerésükhöz szükség van SGML/XML ismeretekre. Kezdő TEI alkalmazóknak nagy segítséget jelent a TEI Lite 3, amely egy leegyszerűsített, de a teljes változattal kompatíbilis kódkészletet tartalmaz. Szintén a szélesebb közönség számára készült a Pizza Chief = Pizza főnök 4, amely saját kialakítású TEI konform DTD-k készítését teszi lehetővé az interneten keresztül A TEI alapelvei és előnyei A TEI ajánlás készítői abból indultak ki, hogy egy olyan csereformátum létrehozásához, amely platformfüggetlen, szükség van egy sajátságos szintaxisra, jól, előre definiált elemekre. Azt is tudták, hogy szövegkódolások készítéséhez szükség van olyan ajánlásokra, amelyek a felvételre kerülő szövegtulajdonságokat határozzák meg az egyes helyzetekben. Ehhez a már ismertetett SGML, majd később az XML nyelv kitűnő megoldásnak bizonyult. A megvalósítás karakterkészletéül induláskor az ISO 646-os szabványát, vagyis a 7 bites ASCII-t választották azóta természetesen a világ sokat változott, így mostanra már a Unicode használatát tekintjük előremutató választásnak a TEI-ben is Alapelvek 1 TEI: Yesterday's information tomorrow. [Honlap.] URL: A letöltés időpontja A projekt vezetője az egyik nagy guru : Sebastian RAHTZ. 3 TEI Lite. [Elektronikus dokumentum.] URL: A letöltés időpontja Pizza Chief. [Elektronikus dokumentum.] URL: A letöltés időpontja

60 Szövegjelölés TEI DTD alapján Alapjában véve kijelenthetjük, hogy a TEI ajánlás az esetek többségében nem ad sem tanácsokat, sem pedig korlátozásokat arra nézve, hogy milyen tulajdonságokat kell kódolni! A rendszer filozófiája a következő: ha valamit kódolni akarsz, akkor mi megmutatjuk, miként tedd azt. Ettől függetlenül továbbra is vannak olyan tulajdonságok, amelyeknek kötelező a jelölése! A szövegek vizsgálatánál számos esetben szükség van több nézőpontra is. Nincs olyan abszolút ajánlás, amely magában foglalná a szöveg egy jellemző nézőpontját, és ez alkalmazható lenne bármilyen megközelítésben mindenféle szövegre. A megoldás az összetett szempontok szerinti szövegjelölés, ugyanis ez lehetővé teszi többféle kódolás elkészítését, amiből kiválasztható, hogy melyik áll legközelebb az eredeti szöveghez. Általában a kódolás pontossága és megbízhatósága, valamint az értelmezés helyessége a meghatározó az egyéni felhasználók számára. Az ajánlás a kódolásokat oly módon definiálja, hogy a felhasználó megtudja belőle, mi miért történt a jelölés során. Ezt segíti elő a TEI fejléc használata, mivel számot ad a kódolás különféle szempontjairól is Előnyök A TEI ajánlás egy általános célú kódolási formát definiál, amely lehetővé teszi a szövegek egyidejű különböző szempontú feldolgozását különböző alkalmazásoknál, kiszolgálva a tudományos célú szövegkutatások legnagyobb részét. Minden ilyen szerkezet szerint felépített dokumentum rendelkezik azokkal az előnyös tulajdonságokkal, amivel az SGML/XML dokumentumok általában: értelmezhető, automatikusan feldolgozható, platform- és nyelvfüggetlen, logikus szerkezeti felépítésű és testre szabható. Számos szoftver támogatja, pl. Emacs, Altova XMLSpy, oxygen, OpenOffice és más XML szerkesztő programok. 5 A formátum immár 18 éve létezik, tehát kiforrott, kipróbált jelölésrendszernek tekinthető, alkalmazásában nincs bizonytalansági tényező. Ráadásul a megfelelő szoftvereszközökkel TEI forrásállományokból gyakorlatilag nagyon sokféle kimenetet konvertálhatunk: HTML, XHTML, RTF, PDF, Text stb., mindössze a szükséges konverziós stíluslapoknak kell rendelkezésre állniuk A TEI felépítése Az alábbiakban röviden és lényegre törően bemutatjuk a TEI dokumentumok felépítését és a benne használt legfontosabb elemeket. 7 Azonban tudnunk kell, hogy a TEI alapján felépített szövegjelölés legtöbbször bonyolultabb, mint amilyen például DocBook esetén készíthető. Ugyanakkor, ha általános felépítésű dokumentumokkal dolgozunk, akkor nagyon egyszerűen el lehet sajátítani az abban használható jelölőelemkészletet. A projekt honlapján természetesen elérhető mindenki számára a teljes dokumentáció! Mielőtt azonban a szerkezeti felépítésbe merülnénk, hasznos tudni, hogy a TEI programnak kezdetben két központi kérdése volt: az elektronikus szövegeknek mely tulajdonságait kódolják; hogyan kódolják a tulajdonságokat, hogy a kódolás minél kevesebb veszteséggel járjon és a végeredmény platformfüggetlen és átjárható legyen; Az utóbbi kérdésre a megoldás egyszerű volt: a TEI-nek a metaadatokat az SGML szabványnak megfelelően kellett rögzíteni ben nem volt más alkalmas eszköz az ajánlás kidolgozására. Ennek eredményeként létrehoztak egy minden szövegre érvényes alap kódkészletet (core tag sets), amely nemcsak a legelemibb szövegelemek metakódját tartalmazza, hanem benne foglaltatik a fejléc (header) is, amelyben a szöveg egészére vonatkozó bibliográfiai adatok vannak. Az ajánlásban sokféle információ rögzítését javasolják, de megengedett a pusztán azonosításra szolgáló, minimális fejléc alkalmazása is. A TEI kezdetben hat fő szövegtípust, ennek alapján hat fő kódkészletet (base tag sets) használt: <!ENTITY % TEI.prose 'INCLUDE' > próza; <!ENTITY % TEI.verse 'INCLUDE' > vers; 5 TEI Software page. [Elektronikus dokumentum.] URL: A letöltés időpontja A TEI egyetlen hátránya a DocBook-kal szemben, hogy a konverzióhoz szükséges eszközök csak részben vagy kezdetlegesebb formában állnak rendelkezésre testre szabásuk, alkalmazásuk jóval több időt igényel. 7 The TEI Guidelines. [Elektronikus dokumentum.] URL: A letöltés időpontja től már az XML ajánlásnak megfelelően is lehet metaadatokat rögzíteni! 50

61 Szövegjelölés TEI DTD alapján <!ENTITY % TEI.drama 'INCLUDE' > dráma; <!ENTITY % TEI.spoken 'INCLUDE' > lejegyzett beszéd; <!ENTITY % TEI.dictionaries 'INCLUDE' > nyomtatott szótárak; <!ENTITY % TEI.terminology 'INCLUDE' > terminológiai adatállományok; A későbbiekben ez bővült, ugyanis a TEI P4 és P5-ös verziója már két újabb kódkészletet tartalmaz: <!ENTITY % TEI.general 'INCLUDE' > általános típusú dokumentumok; <!ENTITY % TEI.mixed 'INCLUDE' > vegyes típusú dokumentumok; A szövegrögzítés céljától függően további tíz kiegészítő kódkészletet (additional tag sets) különböztettek meg, melyek a következők: TEI.linking hypertext kapcsolatok, mutatók jelölése; TEI.analysis analitikus információk kódolása; TEI.fs strukturális nyelvészeti és más elemzések eredményének kódjai; TEI.certainty a szöveg értelmezésekor, rögzítésekor felmerülő bizonytalanságok jelölése; TEI.transcr kéziratos források átírásánál használatos jelek; TEI.textcrit kritikai szövegrögzítés; TEI.names.dates nevek és dátumok kódolása; TEI.nets gráfok, fák és hálózatok ábrázolása; TEI.corpus nyelvi korpuszok; Jelenleg tizenegy kiegészítő kódkészlet van a TEI-ben, tehát a lista egy új taggal gyarapodott: TEI.msdescription kéziratos, vagy korai nyomtatású anyagok leírásához szükséges elemkészlet; Egyértelműen látszik tehát a TEI moduláris felépítettsége, ami azzal az előnnyel jár, hogy a kódolás és a további feldolgozás során nem kell minden szabályra ügyelni, csak azokra, melyek az adott dokumentumtípusra (pl. vers, próza, dráma, szótár), vagy a szöveg kiegészítő elemeire (kritikai apparátus, ugrópontok) vonatkoznak TEI P5 fejléc metainformációk Minden TEI alapú szöveg elé be kell illeszteni a TEI fejlécet 9, amely a dokumentum leírását tartalmazza. A fejléc <teiheader> tulajdonképpen a dokumentum kezdetét jelenti, melynek tulajdonsága <teiheader type=> meghatározza a dokumentum típusát, ami lehet text (egy önálló szöveg leírásánál), vagy lehet corpus (amikor a szöveg egy gyűjtemény része). Szöveggyűjtemények esetén az egyes szövegek előtt és az egész gyűjtemény előtt is szükség van fejléc készítésére. A TEI fejlécnek 4 alapvető eleme van, ezek a következők: <filedesc> <encodingdesc> <profiledesc> <revisiondesc> 9 The TEI Header.[Elektronikus dokumentum.] URL: A letöltés időpontja

62 Szövegjelölés TEI DTD alapján Az említett jelölőelemek közül csak a <filedesc> elhelyezése kötelező minden fejlécben, a másik három használata opcionális, tehát szabadon választható. A teljes TEI fejléc szerkezet a következőképpen néz ki: <teiheader> <filedesc> <!-- Az adott elektronikus fájl teljes bibliográfiai leírását tartalmazza. --> </filedesc> <encodingdesc> <!-- Leírja az elektronikus és a forrásszöveg közötti kapcsolatot. --> </encodingdesc> <profiledesc> <!-- A szöveg nem bibliográfiai jellegű tulajdonságait írja le, különös tekintettel a megjelenítésre, a nyelvhasználatra és az elrendezésre. --> </profiledesc> <revisiondesc> <!-- Összegzi a fájlon végzett javításokat. --> </revisiondesc> </teiheader> Az alapelvekből következően a TEI nem teszi kötelezővé itt sem a bemutatott teljes fejléc szerkezet használatát. Elegendő, ha csak a már említett <filedesc> elemet helyezzük el. Ez viszont minimális követelmény, tehát kötelező! Ez alapján a minimális TEI fejléc szerkezet a következőképpen néz ki: <teiheader> <filedesc> <!-- Az adott elektronikus fájl teljes bibliográfiai leírása. --> </filedesc> </teiheader> Nagyon fontos, hogy mindvégig fejléc szerkezetről beszéltünk, egy teljes TEI fejléc azonban nem építhető fel ilyen egyszerűen. Ezt alátámasztandó csak a <filedesc> elemben, pl. további 7 újabb elem fordulhat elő, azok mindegyike lebontható újabb elemekre. Természetesen a sor nem végtelen, de jól szemlélteti a struktúra összetettségét. Az alábbi példa a minimális TEI fejléc szerkezetet mutatja, egy szinttel lejjebb minden lehetséges alelemre bontva: <teiheader> <filedesc> <titlestmt/> <editionstmt/> <extent/> <publicationstmt/> <seriesstmt/> <notesstmt/> <sourcedesc/> </filedesc> <!-- Ide kerül a TEI fejléc maradék része. --> </teiheader> A lebontott hét alelemből sem kötelező mindet használni, a TEI mindössze három használatára kötelez minket: <titlestmt>, <publicationstmt> és <sorcedesc>. Így végül eljutottunk ahhoz a szerkezethez, amelyet az ajánlás minimális fejlécként kötelezővé tesz. Az alábbiakban egy XML vezérlési utasítással és DTD deklarációval ellátott TEI dokumentumvázat mutatunk be, amely a minimális fejlécet tartalmazza: 52

63 Szövegjelölés TEI DTD alapján <!-- TEI P5 XML --> <?xml version="1.0" encoding="utf-8" standalone= no?> <!DOCTYPE TEI PUBLIC "-//TEI P5//DTD Main Document Type//EN" "tei2.dtd"> <TEI> <teiheader type= text > <filedesc> <titlestmt> <title>az aranyember: elektronikus verzió</title> <author>jókai Mór ( )</author> <respstmt> <resp>a TEI konform XML fájlt összeállította:</resp> <name>hámory Zsófia</name> </respstmt> </titlestmt> <publicationstmt> <publisher>akadémiai Kiadó</publisher> <pubplace>budapest</pubplace> <date>1964</date> <idno type="isbn"> </idno> <availability> <p>copyright 1964, Akadémiai Kiadó</p> </availability> <distributor>neumann-ház</distributor> <address> <addrline>budapest</addrline> <addrline>színház utca 1-3.</addrLine> <addrline>h-1014</addrline> </address> <availability> <p>ez az elektronikus dokumentum szerzői jogi védelem alatt áll.</p> <p>magáncélokra és oktatási vagy tudományos kutatási tevékenységre szabadon felhasználható (letölthető, másolható, nyomtatható). Üzleti célú felhasználása csak a jogosulttal történő előzetes megállapodás alapján lehetséges.</p> </availability> </publicationstmt> <sourcedesc> <biblstruct lang= hu> <monogr> <author>jókai Mór</author> <title>az aranyember</title> <imprint> <pubplace>budapest</pubplace> <publisher>akadémiai Kiadó</publisher> <date value="1964">1964</date> </imprint> </monogr> </biblstruct> </sourcedesc> </filedesc> </teiheader> <!-- Ide kerül a kötet jelölt szövege. --> <text> <front/> <body> <div> <p/> </div> </body> <back/> </text> <TEI> Minél bővebb, teljesebb, beszédesebb a fejlécünk, annál jobb, hiszen sok könyvtár, szövegarchívum kutatói és más hasonló intézmények gyűjtik a bibliográfiai és dokumentációs adatokat a számítógépes szövegekről úgy, 53

64 Szövegjelölés TEI DTD alapján hogy a tényleges szövegeket nem mondhatják magukénak. 10 Ezek az intézmények csak pl. a TEI fejléchez, vagy annak bizonyos részéhez akarnak hozzáférni, hogy katalógusokat, indexeket, adatbázisokat állítsanak össze. A fejléc függetlenül a dokumentumtól, amit leír önállóan is felhasználható könyvtárak, szövegarchívumok és más gyűjtemények számára. A fájl, ami tartalmazza a fejlécet, felhasználható bibliográfiai rekordok készítéséhez is. A profil, a kódolás és a javítások leírása létrehozhatja a bibliográfiai leírás egy részét, vagy még alkalmasabb lenne arra, hogy magyarázatként hozzáfűzzék a teljes dokumentumvizsgálathoz. Ez a fejléc tulajdonképpen egy elsődleges eszköz arra, hogy az intézmények hozzájuthassanak teljes dokumentációs információkhoz olyan elektronikus szövegekről, amelyek távoli számítógépeken vannak. Ma már lehetőség van arra is, hogy a TEI fejléc adatait más adatcsere formátumok metaadatainak feleltessük meg, pl. MARC 11, Dublin Core, Qualified Dublin Core 12 stb. Gondoljunk csak bele, hogy így gyakorlatilag bármilyen szabványhoz igazodva XML-ben átadhatjuk metaadatainkat a keresőrendszerekkel egybekötött adattárak számára. De ha egyszerűen csak arra használjuk a fejlécet, hogy a szolgáltatandó (X)HTML állományok <head> részének <meta> elemeit a konverzió során automatikusan abból nyerjük ki, akkor már megérte fáradozni az elkészítésével TEI P5 szövegstruktúra A TEI P5 13 alapján jelölt könyvek szöveges tartalma a <TEI> gyökérelemet és a <teiheader> fejlécet követően ún. <text> elembe kerül. A <text> továbbiakban rendszerint a címoldal leírásával folytatódik, mely a <front> elemben kap helyet. Ezt követi a <body> a tényleges szövegtartalommal, majd a glosszáriumot, jegyzeteket, indexet, bibliográfiát és appendixet tartalmazó <back> zárja a sort: <TEI> <teiheader/> <text> <front/> <body/> <back/> </text> </TEI> Mivel a könyvek címoldala általában annak címét, alcímét, a szerző nevét és a kiadással kapcsolatos adatokat tartalmazza, ezért pl. a TEI <front>-ban szereplő címlap <titlepage> az alábbi formát öltheti: <front> <titlepage> <doctitle> <titlepart type="main">a kőszívű ember fiai</titlepart> </doctitle> <docauthor>jókai Mór</docAuthor> <docimprint> <publisher>akadémiai Kiadó</publisher> <pubplace>budapest, Magyarország</pubPlace> </docimprint> </titlepage> </front> 10 Ilyen elven működik a begyűjtéshez OAI-PMH protokollt használó Nemzeti Digitális Adattár is, hiszen csupán a metaadatokat aratja le (harvesting) és azokat gyűjti saját adatbázisában. 11 MARC 21 XML Schema. [Elektronikus dokumentum.] URL: A letöltés időpontja Dublin Core Metadata Initiative (DCMI). [Elektronikus dokumentum.] URL: A letöltés időpontja The TEI Guidelines. [Elektronikus dokumentum.] URL: A letöltés időpontja

65 Szövegjelölés TEI DTD alapján A <front> szerkezeti egységben helyezhetjük el a feldolgozandó dokumentum előszavát, köszönetnyilvánítását, ajánlását, összegzését (abstract), tartalomjegyzékét és az esetleges címlapfotót. 14 A dokumentum tényleges szövegében az egyes fejezetektől, szakaszoktól elkezdve a mottón, ajánláson át egészen a nyelvhasználatig, rengeteg szemantikai tulajdonságot jelölhetünk. Azonban kétségkívül legfontosabb a megfelelő címhierarchia megállapítása, mert a HTML/XHTML formátumba való konvertáláskor szinte mindig ez jelenik meg <h1>...<h6> szintű címsorokként. A TEI <body> magyarul nevezhetjük műnek elemében az egyes fejezeteket hét szintre tagolhatjuk <div0>...<div7> ha nem akarunk effajta struktúrát, akkor a <div> önmagában, számozás nélkül is alkalmazható 15, az ezeken belüli bekezdés szövegegységeket pedig <p>-vel jelölhetjük. Az adott fejezethez tartozó címet vagy a <div> után következő <head> elemben, vagy a <head>-ben lévő <title> elemben rögzíthetjük: <body lang= hu > <div0> <div1 type="chapter" n="1"> <head> <title type="title1">hatvan perc!</title> </head> <p/> </div1> <div1 type="chapter" n="2"> <head> <title type="title1">a temetési ima</title> </head> <p/> </div1> <div1 type="chapter" n="3"> <head> <title type="title1">tallérossy Zebulon</title> </head> <p>a tor mindenképpen... nem tósztoznak benne.</p> <p/> </div1> </div0> </body> A példából egyértelműen látszik, hogy <div1> a tulajdonképpeni fejezetszint ezt a type attribútumában adjuk meg, sőt az is kiderül, hogy az egyes fejezetek értelemszerű számozást kapnak. A <title> jellemzője jelen esetben mindenhol "title1", azaz cím1 értéket vesz fel, tehát ilyen típusú fejezetcímet is takar. Többnyelvű dokumentumok esetén a magasabb szinten megadott lang= hu, vagy lang= de stb. tulajdonságot alacsonyabb szinteken, pl. bekezdésnél felülbírálhatjuk. A TEI alapján jelölt dokumentumok utolsó nagy részegysége a már említett <back>, erre KOVÁCS Győző: Válogatott kalandozásaim Informatikában c. könyvéből hozunk példát: <back> 14 Default Text Structure: Front Matter. [Elektronikus dokumentum.] URL: A letöltés időpontja Default Text Structure: Division of the Body. [Elektronikus dokumentum.] URL: A letöltés időpontja

66 Szövegjelölés TEI DTD alapján <div type="appendix"> <head>utószó</head> <p>nem fejeztem be a könyvet, csak abbahagytam az írást, az oldalak fogytak el és nem a történeteim.... számítástechnika történetnek a folytatását még hitelesebben tudjuk átadni a mai fiataloknak. Köszönöm!</p> <signed>sok szeretettel: <name>kovács Győző</name> </signed> </div> </back> A <back> használatakor mindig a <div> elem type tulajdonságában kell megadni, hogy éppen milyen tatalmi egységet kódolunk. Ez példánkban appendix értéket vett fel, de ide kerülhet a glosszárium, a jegyzetek, a bibliográfia, az index és a kolofon is Szövegformázás A szerzők gyakran élnek olyan formázási lehetőségekkel, melyek a szöveget dőltté, aláhúzottá és félkövérré teszik. Bár döntés kérdése, hogy az elektronikus szöveg kódolásakor formahűen tükrözzük-e a könyvet, a lehetőséget nem szabad elvenni. Természetesen a TEI is lehetővé tesz szövegformázást, méghozzá a <hi> elem segítségével. 17 Az attribútum nélkül megadott <hi> az esetek többségében dőlt betűs írásmódot eredményez, ám a rend attribútum bevonásával könnyedén szabályozhatjuk a megjelenést: <p>tei-ben így lehet <hi rend= italic >dőlt</hi>, <hi rend= bold >félkövér</hi> és <hi rend= underline >aláhúzott</hi> szöveget létrehozni.</p> "... Természetesen a formázási utasítások a Az SGML/XML jelölésrendszer kódolás c. fejezetben leírtak alapján kombinálhatók, vagyis ha egy szöveget egyszerre mindhárom utasítással el akarunk látni, akkor az alábbi formát kell alkalmazni: <p>tei-ben így lehet <hi rend= italic bold underline >dőlt félkövér és aláhúzott</hi> szöveget létrehozni.</p> A megoldás sajnos nem tökéletes ennek több oka is van: 1. Mivel több érték szerepel az attribútumban, ezért pl. a(z) (X)HTML-t végző konverziós stíluslapban mindhárom tulajdonság lehetséges kombinációját fel kell venni a lekezelhetőség végett. 2. A rend attribútum a DTD alapján bármilyen karakteres adatot felvehet magyarul nem határozza meg a lehetséges értékeket. Így viszont az XML szerkesztő programok sem kínálják fel kódolás során a választási lehetőségeket, tehát bármilyen értéket bevihetünk a tulajdonság értékeként ezzel hibalehetőséget kínálunk fel. 16 Default Text Structure: Back Matter. [Elektronikus dokumentum.] URL: A letöltés időpontja Elements Available in All TEI Documents: Emphasis, Foreign Words, and Unusual Language. [Elektronikus dokumentum.] URL: A letöltés időpontja

67 Szövegjelölés TEI DTD alapján 3. Ha azt szeretnénk, hogy ellenőrizhető legyen a rend tulajdonságba bevitt értékek érvényessége, akkor azokat fel kell venni a DTD-ben. Ezt viszont azért nem célszerű megtenni, mert a rend globális attribútum, tehát számos más elem is használhatja esetlegesen eltérő értékekkel, ami újabb hibalehetőséghez vezet. Ráadásul a nemzetközileg elfogadott DTD-kben minél kevesebb egyéni módosítást ajánlott elvégezni a frissítésekre és új verziókra való könnyebb áttérés végett. A felvázolt problémák kiküszöbölésére egy lehetséges megoldás lehet, ha az XSL-FO 18 szabványból a legfontosabb formázási attribútumokat beemeljük a DTD-be, és a rend attribútum helyett ezeket használjuk. Mivel az XSL-FO ajánlás saját DTD-vel rendelkezik, ami definiál egy névteret, így nem szabad elfeledkezni a kódolás során a névtér URL-jének elhelyezéséről sem, pl. a gyökér elemben: <!-- XML --> <TEI xmlns:fo=" <p>tei-ben így lehet <hi fo:inline font-style="italic">dőlt</hi>... szöveget létrehozni.</p> </TEI> Ha a szövegben olyan szavakat, szócsoportokat vagy számokat találunk, amelyek alsó illetve felső indexbe kell, hogy kerüljenek, akkor a <sub> és <sup> elemeket alkalmazhatjuk a jelölés során: <p>a víz képlete H₂O.</p> <p>matematikában az a²+b²=c².</p> Sortörés, oldaltörés Kódolás során bizonyos esetekben indokolt lehet a sortörés <lb/> alkalmazása is. Ilyen eset, ha pl. egy képaláírást több sorba szeretnénk tördelni: <figdesc>tölcséres lemezjátszó (fotó: Gottl Egon)<lb/> Sternberg Ármin és testvére hangszergyár, Zenetörténeti Múzeum</figDesc> Nemcsak sor-, hanem oldaltörést <pb/> is használhatunk a TEI-ben. Ez az elem arra szolgál, hogy az eredeti dokumentum oldalainak végét jelölje, mivel a számítógépen rendszerint nem oldalanként jelenik meg a szöveg. A megjelenítésért felelős konverziós stíluslap figyelmen kívül hagyhatja, mivel leginkább csak a forrásfájlban való jelölésre szolgál Listák Szövegfeldolgozás során alapvetően négyféle lista-, illetve felsorolástípust különböztethetünk meg. Megjelenítéskor tehát a lista viselkedhet mondaton belüli felsorolásként, melynek elemei előtt nem szerepel semmiféle szimbólum, lehet körrel és egyéb grafikus jellel ellátott és végül betűvel vagy számmal strukturált. 18 Extensible Stylesheet Language (XSL) Version 1.0. [Elektronikus dokumentum.] URL: A letöltés időpontja

68 Szövegjelölés TEI DTD alapján Mivel a TEI P5 jelen pillanatban egyetlen típusértéket simple definiál, ezért kézenfekvőnek tűnik a <list> elem type attribútumának DTD szinten való kibővítése, jobban mondva pontosítása 19 a lépcsős stíluslapok ajánlásának listákhoz kapcsolódó értékkészletéből 20 : <!ENTITY % list 'INCLUDE' > <![ %list; [ <!ELEMENT %n.list; > <!ATTLIST %n.list; %tei.global.attributes; type CDATA "simple" TEIform CDATA 'list' > ]]> <!ENTITY % list 'INCLUDE' > <![ %list; [ <!ELEMENT %n.list; > <!ATTLIST %n.list; %tei.global.attributes; type (none disc simple decimal lower-alpha upper-roman) simple TEIform CDATA 'list' > ]]> A példában jól látszik, hogy a változtatás után ugyanúgy a felsorolás típusú lista simple maradt az alapértelmezett, ám konkretizálódtak a lehetséges típusértékek: Szimbólum nélküli lista: <list type= none > <item>elemérték</item> <item>elemérték</item> <item>elemérték</item> </list> elemérték elemérték elemérték Felsorolás típusú lista (diszk szimbólumot kap, értéke disc vagy alapértelmezetten simple ): <list type= disc > <!-- vagy --> <list> 19 Jelen esetben azért beszélhetünk pontosításról, mert az eredeti CDATA típus, mint lehetséges értékkészlet, meglehetősen nagy lazaságot eredményez, ráadásul ismételten jelentkezik a validitás XML szerkesztőkben való ellenőrizhetőségének a hiánya, mivel a kódoló bármilyen karakteres adatot bevihet értékként. 20 A CSS (lépcsős stíluslapok) ajánlás nagyon sokféle listatípus létrehozására kínál lehetőséget. Ezek mindegyikét a manapság leggyakrabban használt böngészők sem tudják kifogástalanul megjeleníteni, tehát óvatosan kell bánni a különleges számokat/szimbólumokat jelölőként használó felsorolásokkal. Legbiztosabb, ha folyamatosan teszteljük a megjelenítést! 58

69 Szövegjelölés TEI DTD alapján <item>elemérték</item> <item>elemérték</item> <item>elemérték</item> </list> elemérték elemérték elemérték Decimálisan számozott lista: <list type= decimal > <item>elemérték</item> <item>elemérték</item> <item>elemérték</item> </list> 1. elemérték 2. elemérték 3. elemérték Latin kis betűkkel jelölt lista: <list type= lower-alpha > <item>elemérték</item> <item>elemérték</item> <item>elemérték</item> </list> a. elemérték b. elemérték c. elemérték Fontos tudnunk, hogy az elemértékekbe újabb listák ágyazhatók, tehát egy <item>-en belül létrehozhatunk újabb beágyazott felsorolást vagy számozott listát. Abban az esetben, ha a lista egyes értékeit valamilyen címkével akarjuk ellátni, a <label> elemet hívhatjuk segítségül. Vegyük észre, ilyenkor nem az elemértékhez, hanem az elemcímkéhez érdemes tenni a felsorolást jelző szimbólumot: Nagy római számokkal ellátott lista: <list type="lower-alpha"> 59

70 Szövegjelölés TEI DTD alapján <label>elemcímke</label> <item>elemérték</item> <label>elemcímke</label> <item>elemérték</item> <label>elemcímke</label> <item>elemérték</item> </list> I. elemcímke elemérték II. elemcímke elemérték III. elemcímke elemérték A bemutatott példák jó ízelítőt nyújtanak a lehetőségekből, ugyanakkor speciálisabb esetekhez célszerű tanulmányozni a dokumentációt, mivel az egyes jelölőelemek és tulajdonságaik leírásán kívül összetettebb példák is találhatók benne! Hiperhivatkozások, lábjegyzetek Modern kötetek, dokumentációk stb. feldolgozásakor számos esetben előfordulhat, hogy a szerző valamilyen külső objektumra fájl, honlap stb. hivatkozik. Ha ilyennel találkozunk TEI alapú szövegjelölés során, akkor az <ref> jelölőelemet hívhatjuk segítségül TEI P4-ben <xref>. Az <xref> rendelkezik egy doc attribútummal, itt kell hivatkozni a külső dokumentum external entityjére! Ha ezt nem adjuk meg, akkor az aktuális dokumentumot jelenti, vagyis belső hivatkozást. A from attribútum a cél kezdő pontját, a to pedig a végpontját jelöli. TEI-ben tehát nemcsak egy pontra lehet hivatkozni, hanem akár egész szövegtartományra. Ha a to attribútumot nem adjuk meg, akkor csak egy pontra hivatkozunk. Ha a from -ot sem adjuk meg, akkor a gyökérelemre hivatkozunk: <!-- XML, de TEI P4 --> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE TEI.2 PUBLIC "-//NEUMANN//DTD TEIP4.DTD//HU" " [ <!NOTATION html PUBLIC '-//W3C//NOTATION HTML 4.0 Transitional//EN'> <!ENTITY BHIorokzene SYSTEM " /webkat?infile=virt_keret.html&oid=43118& dok= NDATA html> <!ENTITY Neumann-honlap SYSTEM " NDATA html> ]> <TEI.2> <p> <xref doc="bhiorokzene">a vers a BHI-ban</xref> <lb/> <xref doc="neumann-honlap">a Neumann-ház honlapja</xref> </p> </TEI.2> A következőkben tekintsük meg, miként festenek ugyanezek a hivatkozások TEI P5-ben, NOTATION és külső entitás-hivatkozások nélkül: 21 Elements Available in All TEI Documents: Lists. [Elektronikus dokumentum.] URL: A letöltés időpontja

71 Szövegjelölés TEI DTD alapján <!-- TEI P5 XML --> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE TEI PUBLIC "-//TEI P5//DTD Main Document Type//EN" " [ <!ENTITY % TEI.core 'INCLUDE' > <!ENTITY % TEI.header 'INCLUDE' > <!ENTITY % TEI.textstructure 'INCLUDE' > <!ENTITY % TEI.mixed 'INCLUDE' > <!ENTITY % TEI.figures 'INCLUDE' > <!ENTITY % TEI.linking 'INCLUDE' > ]> <TEI> <p> <ref target=" &oid=43118&dok= SGML/BHISGMLtr?juhaszgy/juhaszgy0429.sgml">A vers a BHI-ban</ref> <lb/> <ref target=" Neumann-ház honlapja</ref> </p> </TEI> Jól látszik, hogy a P5-ös verzió a <ref> elem target attribútumát használja a hivatkozott oldal URL-jének a tárolására. A megoldás tehát lényegesen egyszerűbb, mint a TEI korábbi verzióiban volt. Érdemes felfigyelni arra is, hogy az egyes elemkészleteket tartalmazó paraméter-entitások a belső DOCTYPE deklarációban ki/be kapcsolhatóak, ezáltal biztosítva egyes elemkészletek gyors kiiktathatóságát az ellenőrzésből, illetve bekapcsolhatóságát a feldolgozásba Táblázatok A TEI lehetőséget nyújt táblázatok készítésére is, méghozzá a <table> elem segítségével. A <table> jelölőelem cols attribútumával állíthatjuk be a táblázaton belüli oszlopok, a row tulajdonsággal pedig a sorok számát. Amennyiben cím vagy leírás is tartozik a táblázathoz, azt a <table> elemet követő <head>-ben helyezhetjük el. A táblázat sorait a <row>, az egyes sorokban elhelyezkedő cellákat pedig a <cell> jelölővel kell ellátni. Amennyiben indokolt, úgy a sorokban és az oszlopokban is szerepelhet cím, mégpedig a kapcsolódó jelölőelemek role attribútumának felhasználásával: <table rows="2" cols="2"> <head>ide kerül a tálázat címe</head> <row role="label"> <cell/> <cell>oszlopcím</cell> <cell>oszlopcím</cell> <cell>oszlopcím</cell> </row> <row> <cell role="label">sorcím</cell> <cell>cellaérték</cell> <cell>cellaérték</cell> <cell>cellaérték</cell> </row> </table> 22 Az adott állományon belül azért kell INCLUDE-ra állítani az egyes elemkészleteket definiáló paraméter-egyedeket, mert alapértelmezetten a tei.dtd állomány IGNORE-álja őket. 61

72 Szövegjelölés TEI DTD alapján Vízszintes és függőleges cellaösszevonásokkal természetesen az itt bemutatottnál lényegesen bonyolultabb táblázatok is készíthetők TEI-ben, ezek ismertetésétől azonban eltekintünk. Javasoljuk, hogy bővebb információkért látogasson el a szabvány honlapjának vonatkozó részére Képek Képek rögzítésére azt a <figure> jelölőelemet használhatjuk, melynek entity attribútumában kell megadni a megjelenítendő képfájl external entityjét. A kép nevét vagy címét (képaláírás) itt is a <head> elemmel lehet jelölni, a kép szöveges leírását pedig mely konverziót követően az output HTML állomány <img> elemének alt attribútumában kell, hogy helyet kapjon, a <figdesc>-be kell tenni: <!-- XML, de TEI P4 --> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE TEI.2 PUBLIC "-//NEUMANN//DTD TEIP4.DTD//HU" " [ <!NOTATION jpeg PUBLIC 'ISO DIS 10918//NOTATION JPEG Graphics Format//EN'> <!ENTITY nemzetimuz SYSTEM "nemzetimuz.jpg" NDATA jpeg> ]> <TEI.2> <figure entity="nemzetimuz"> <head>magyar Nemzeti Múzeum</head> <figdesc>rudolf von Alt: A Nemzeti Múzeum, mellette piaci forgatag. Austrian, and Hungarian Drawings from Budapest. Szerkesztette:Gerszi Teréz-Gonda Zsuzsa. Art Services International, Alexandra, Virginia, 1994,48. kép. Szépművészeti Múzeum, Budapest</figDesc> <figure> </TEI.2> A TEI P5-ös verziójában ezen a téren is történt némi változás. A szabvány már nem a <figure> elem entity tulajdonságában javasolja a forrásfájl megnevezését, hanem bevezetette a <graphic> jelölőt, melynek url attribútumában rögzíthetjük a megjelenítendő képfájl nevét. Ez lényeges egyszerűsítés, hiszen megspórolható a NOTATION és az entitás-deklaráció a belső DTD-ben. A <figure> ettől függetlenül ugyanúgy használható, de csak blokkszintű képkódolás esetén kell a <graphic>-ot beletenni. Ha soron belüli elhelyezést szeretnénk (inline), akkor önmagában kell használni a <graphic> jelölőelemet 24 : <!-- TEI P5 XML --> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE TEI PUBLIC "-//TEI P5//DTD Main Document Type//EN" " [ <!ENTITY % TEI.core 'INCLUDE' > <!ENTITY % TEI.header 'INCLUDE' > <!ENTITY % TEI.textstructure 'INCLUDE' > <!ENTITY % TEI.mixed 'INCLUDE' > <!ENTITY % TEI.figures 'INCLUDE' > <!ENTITY % TEI.linking 'INCLUDE' > ]> <TEI> 23 Tables, Formulae, and Graphics: Tables. [Elektronikus dokumentum.] URL: A letöltés időpontja Elements Available in All TEI Documents: Specific Elements for Graphic Images. [Elektronikus dokumentum.] URL: A letöltés időpontja

73 Szövegjelölés TEI DTD alapján <figure> <graphic url="nemzetimuz.jpg"/> <head>magyar Nemzeti Múzeum</head> <figdesc>rudolf von Alt: A Nemzeti Múzeum, mellette piaci forgatag. Austrian, and Hungarian Drawings from Budapest. Szerkesztette:Gerszi Teréz-Gonda Zsuzsa. Art Services International, Alexandra, Virginia, 1994,48. kép. Szépművészeti Múzeum, Budapest</figDesc> <figure> <p>ez pedig példa az inline megvalósításra. Itt egy háromszöget <graphic url="haromszog.jpg"/> szúrtunk be a sor adott pontján.</p> </TEI> Magyar Nemzeti Múzeum Ez pedig példa az inline megvalósításra. Itt egy háromszöget szúrtunk be a sor adott pontján Matematikai vagy más képletek TEI-ben is lehetőség van matematikai és más jellegű képletek jelölésére, mégpedig a <formula> elemben. A <formula> notation attribútumában lehet megadni, hogy milyen jelölésrendszer alapján kódoltuk a képletet. (A TEI globális attribútumai természetesen itt is használhatóak.) 25 [Megj.: A TEI kezdetben kizárólag a Donald E. KNUTH által létrehozott TeX szedési nyelvet használta, mivel egyrészt az 1990-es évek második feléig nem volt más, másrészt a matematikai jelölés volt a TeX erőssége.] <!-- TEI P5 XML --> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE TEI PUBLIC "-//TEI P5//DTD Main Document Type//EN" " [ <!NOTATION TeX PUBLIC '-//Donald E. Knuth 1983//NOTATION TeX Mathematical Markup//EN'> ]> <!ENTITY % TEI.core 'INCLUDE' > <!ENTITY % TEI.header 'INCLUDE' > <!ENTITY % TEI.textstructure 'INCLUDE' > <!ENTITY % TEI.mixed 'INCLUDE' > <!ENTITY % TEI.figures 'INCLUDE' > <!ENTITY % TEI.linking 'INCLUDE' > <!ENTITY % TEI.graphics "INCLUDE"> <TEI> <p>itt egy példát láthatunk TeX kódra: <formula notation="tex">$$ 25 A globális attribútumok megtalálhatók a tei.dtd állományban. 63

74 Szövegjelölés TEI DTD alapján {1 \over 10} + {1 \over 100} + {1 \over 1000} + {1 \over 10,\!000} + \dots $$</formula> </p> <p>inline megjelenítés esetén használható pl. a következő formula: <formula id="f12" n="12" rend="inline">v=43*r3</formula></p> </TEI> Természetesen manapság már egyáltalán nem indokolt a TeX használata, hiszen a W3C 1998-ban kiadta a MathML 1.0-ás változatát, ami egy kifejezetten XML szintaktikára épülő matematikai jelölőnyelv. A MathML 2.0-ás ajánlásának második kiadása októberében jelent meg. 26 A TEI szabvány más képletleíró nyelvek alkalmazását is javasolja a <formula> jelölőelemben ezekről mindenki bővebben tájékozódhat a P5-ös verzió honlapján Versek Az eddig olvasottakból világossá válhatott mindenki számára, hogy a TEI szabvány külön DTD-ket tart fent a fő szövegtípusok jelölésére. A versek kódolásakor használható elem- és attribútum-készletek a verse.dtd állományban találhatók meg. Az alábbiakban JUHÁSZ Gyula Örök zene c. versének TEI P5 XML részletét mutatjuk be a versjelölés megértéséhez: <!-- TEI P5 XML --> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE TEI PUBLIC "-//TEI P5//DTD Main Document Type//EN" " [ <!ENTITY % TEI.core 'INCLUDE' > <!ENTITY % TEI.header 'INCLUDE' > <!ENTITY % TEI.textstructure 'INCLUDE' > <!ENTITY % TEI.mixed 'INCLUDE' > <!ENTITY % TEI.figures 'INCLUDE' > <!ENTITY % TEI.linking 'INCLUDE' > <!ENTITY % TEI.verse 'INCLUDE' > ]> <TEI> <text> <body> <div type="vers"> <head> <title>juhász Gyula: Örök zene</title> </head> <lg> <l>gondolj el nem múló zenékre lelkem,</l> <l>száz csillagokon fönn az égi kertben.</l> </lg> <lg> <l>és éjszakára, melynek tükörében</l> <l>elsápad minden árnyék földön, égen.</l> </lg> <lg> <l>ember Fiára, ki lenn járt e tájon,</l> <l>hogy minden szív eztán remélve fájjon,</l> <l>...</l> 26 Mathematical Markup Language (MathML) Version 2.0 (Second Edition). [Elektronikus dokumentum.] URL: A letöltés időpontja Tables, Formulae, and Graphics: Formulae and Mathematical Expressions. [Elektronikus dokumentum.] URL: A letöltés időpontja

75 Szövegjelölés TEI DTD alapján </lg> </div> </body> </text> </TEI> A példa kiválóan rávilágít a versjelölés fő alkotóelemeinek használati módjára. Az egyes versszakokat <lg> elemek közé kell helyezni, melyek tulajdonképpen a verssorok csoportjaként foghatók fel. Ha az adott versszak jelölőelemét valamilyen tulajdonsággal akarjuk ellátni, azt a type tulajdonsággal tehetjük meg. A versszakokon belül minden egyes verssort <l> jelölőkkel határozhatunk meg. Előfordulhat olyan vers is, aminél nem használjuk a versszakképzést biztosító <lg> elemet, mivel a vers nem tagolódik versszakokra. 28 Az egyértelműség kedvéért az egész verset <div>, azaz rész elemek közé helyeztük, melynek type attribútumába megadtuk azt is, hogy egy vers következik A TEI jövője Mivel a TEI rendkívül nagyszámú elemkészlettel rendelkezik az egyes dokumentumtípusok tartalmainak jelöléséhez jóval több, mint 400 jelölőelemet tartalmaz, így ebből mi csak apró ízelítőt nyújthattunk, ezért meglehetősen részletes szövegjelölést tesz lehetővé számunkra. Figyelembe véve, hogy jelentős létszámú szerzői közösség használja 29 és számos kereskedelmi, illetve ingyenes szoftver támogatja, jövője egyértelműen biztosítottnak látszik. [Megj.: Az utóbbi 1-2 évben egyre élénkebbnek látszik a TEI DocBook fejlesztői közösségek közötti együttműködés és kommunikáció, sőt törekvések vannak a két nagy szabvány egymással való megfeleltetésének létrehozására is.] 30 Megítélésünk szerint a TEI már ma is egy olyan eszköz lehet a textológusok, irodalmárok, történészek és a szövegfeldolgozók kezében, aminek a segítségével számos, a szöveg ábrázolását érintő kérdést például a négyféle jegyzet problémáját 31 sikeresen meg lehet oldani. A legnagyobb probléma azonban az, hogy a TEI alkalmazásához még nélkülözhetetlen a mélyebb számítástechnikai ismeret, esetenként a programozói készség, hiszen az elméleti szépség mögött még meglehetősen gyerekcipőben járnak azok a kényelmi szolgáltatások, amik az állomány előállítását és elemzését olyan napi rutinná tudnák tenni, mint amilyenné a szövegszerkesztés és a táblázatkezelés vált az utóbbi tíz évben. 32 Azok a kényelmes használatot biztosító eszközök, melyek rendelkezésre állnak OpenOffice, XMLSpy, oxygen stb. már mutatják az utat, de ez még kevés. Ráadásul a fejlesztői közösségnek a jövőben jobban kell törekedni arra, hogy az egyéb formátumokba (X)HTML, PDF, RTF stb. való konverzióra alkalmas kiforrottabb csomagokat állítsanak össze a könnyebb és gyorsabb felhasználhatóság érdekében. Erre utaló törekvések már vannak 33, de még korántsem olyan rózsás a helyzet, mint a DocBook esetében. A következő fejezetben látni fogjuk, hogy a DocBook használatakor azért valamivel több kényelmi szolgáltatás áll 28 Base Tag Set for Verse. [Elektronikus dokumentum.] URL: A letöltés időpontja A TEI szabványt regisztráltan jelen pillanatban 123 projekt alkalmazza a világon, köztük olyan nagy szöveggyűjtemények, mint az Oxford University Computing Services (OTA), vagy az American Memory from the Library of Congress. Ez a szám persze nem mérvadó, hiszen Magyarországról pl. csak a Szeged Corpus projekt regisztráltatta magát, holott rajta kívül köztudottan több gyűjtemény is implementált TEI DTD-t. Projects using the TEI. [Elektronikus dokumentum.] URL: A letöltés időpontja RATHZ, Sebastian: A unified model for text markup: TEI, Docbook, and beyond. [Elektronikus dokumentum.] URL: WALSH, Norman: The DocBook Encoding Initiative or TextBook? [Elektronikus dokumentum.] URL: A letöltés időpontja Eredeti szerzői jegyzetek, közreadói kritikai apparátus, szómagyarázatok és tárgyi jegyzetek. 32 DocBook esetén is hasonló a helyzet, ám mivel annak fejlesztését egy alapvetően informatikai közösség indította el, így a publikáláshoz szükséges konverziós eszközök kiforrottabban rendelkezésre állnak. Alkalmazásuk azonban nem nélkülözheti a komolyabb informatikai ismereteket! 33 TEI Software page TEI-Specific tools. [Elektronikus dokumentum.] URL: A letöltés időpontja

76 Szövegjelölés TEI DTD alapján rendelkezésünkre feldolgozott anyagaink publikálásához, jóllehet ott sem nélkülözhetők a komolyabb informatikai ismeretek. Fegyvereink, vagy inkább TEI XML állományaink publikálásához tehát egyelőre fegyverhordozóra programozóra, fejlesztőre 34 is szükségünk van! Feltéve ha mi magunk nem vagyunk azok Netán a Neumann-ház többéves, a TEI alapú szövegfeldolgozás területén szerzett tapasztalatára. 35 KIRÁLY Péter: Kritikai kiadás és XML. [Elektronikus dokumentum.] URL: A letöltés időpontja

77 6. fejezet - Szövegjelölés DocBook DTD alapján A szövegfeldolgozás területének másik nagy, nemzetközileg elismert jelölésrendszere a DocBook 1 általános SGML/XML alapú dokumentumformátum, melyet az 1990-es évek elején fejlesztettek ki, és azóta használnak általános témájú dokumentumok és technikai leírások tárolására. Ebben a fejezetben a DocBook jelölésrendszer legalapvetőbb szerkezeti egységeit és elemeit mutatjuk be, valahogy úgy, mint ahogy azt az Szövegjelölés TEI DTD alapján c. fejezetben tettük. Ám mielőtt belevágnánk, ismételten köszönetet mondunk a MARKÓJA Szilárd könyvtárvezetőnek és BARTAL Tamás szoftverfejlesztőnek, akik a HIK Felsőoktatási Digitális Tankönyvtárában alkalmazott DocBook XML formátum magyar nyelvű leírását e kötethez rendelkezésünkre bocsátották. 1. DocBook A DocBook dokumentumtípust több mint tíz évvel ezelőtt a HaL Computer Systems és az O'Reilly & Associates hozta létre, később fejlesztésében részt vett a Novell, a Digital, a Hewlett Packard, a Sun, az SCO és mások. Nyílt szabvány, jelenleg egy nonprofit konzorcium, az OASIS 2 (Organization for the Advancement of Structured Information Standards) kezeli, melynek égisze alatt egy meglehetősen élénk fejlesztői közösség dolgozik rajta. Sokévi fejlesztés eredményeként jutottak el arra a pontra, ahol a legújabb V4.4-es verzió tart a V ös a könyv írásakor munkapéldány, és amely minden olyan szöveg leírására alkalmas, amely a technikai dokumentációkkal, szakkönyvekkel kapcsolatban egyáltalán felmerülhet. [Megj.: A DocBook egyre szélesebb felhasználói köröket vonz, hiszen kis jóindulattal mondhatjuk, hogy szépirodalmi szövegek jelölésére is alkalmas még akkor is, ha ez vitathatatlanul a TEI erőssége.] Mivel a DocBook dokumentumok felépítése is követi a könyvek szerkezetét, sőt a TEI-t megközelítő számú több, mint 300 elemmel rendelkezik 4 a tartalom elrendezéséhez, ezért jelentős létszámú szerzői közösség használja, továbbá támogatja számos kereskedelmi forgalomban lévő és szabad szoftver. A DocBook formátumot a fent említett számítástechnikai cégeken kívül széles körben használják a szabad szoftvereket fejlesztő közösségek, pl. a Linux Documentation Project, a FreeBSD Documentation Project, a GNOME Documentation Project, a KDE Documentation Project, a Caldera Systems, a Mandrakesoft, a Red Hat és a SuSE, több millió oldalnyi dokumentáció, elektronikus könyv és más kiadvány tárolására A DocBook előnyei A DocBook formátum minden olyan előnnyel rendelkezik, amivel az SGML/XML dokumentumok általában: Logikus szerkezeti felépítésű, gép által értelmezhető, feldolgozható, valamint platform- és nyelvfüggetlen, testre szabható és bővíthető. A DocBook formátumot létező eszközök, kereskedelmi és szabad szoftverek támogatják és ismerik még jobban, mint a TEI esetében, például az OpenOffice irodai szoftvercsomag, az Emacs, Quanta, Altova XMLSpy, oxygen és más XML szerkesztő programok. A formátum fejlesztése folyamatos, ráadásul mivel viszonylag hosszabb ideje szerepel a palettán, így kiforrott, kipróbált formátumnak tekinthető. A már meglévő és testre szabható szoftvereszközökkel a DocBook forrásfájlból konvertálhatunk: (X)HTML, HTMLhelp, MIF (Adobe FrameMaker), PDF, PostScript, RTF, TeX, TXT formátumokba, azaz így egy fájlból tudjuk kiszolgálni a különböző formátumú, de azonos tartalmú dokumentumok iránti igényeket. 1 DocBook. [Honlap.] URL: A letöltés időpontja OASIS. [Honlap.] URL: A letöltés időpontja The DocBook Document Type. [Elektronikus dokumentum.] URL: A letöltés időpontja Part II. Reference. [Elektronikus dokumentum.] URL: A letöltés időpontja

78 1.2. A DocBook felépítése Szövegjelölés DocBook DTD alapján Ahogy azt már korábban említettük, a DocBook DTD háromszáznál is több elemet tartalmaz. Ebben a fejezetben tehát nincs lehetőség arra, hogy a teljes elemkészlet fő szerkezeti egységein és leggyakrabban használt elemein kívül bármi mást bemutassunk. Akinek felkelti az érdeklődését a jelölésrendszer, annak a teljes dokumentáció további böngészését javasoljuk. 5 A DocBook segítségével alapvetően három különböző dokumentumfajta létrehozására nyílik lehetőségünk: Könyv (book): A legösszetettebb dokumentumszerkezet, ez tartalmazza a címlapot, hátlapot, az egyes fejezeteket, a bekezdéseket, a mutatókat stb. Cikk (article): A könyvnél kisebb dokumentumok számára javasolják, amelyek struktúrája nem olyan bonyolult, pl. cikkek, egyszerű fejezetek stb. 6 Referencia-oldal (reference page): Bármilyen referencia típusú információ esetén használható. Mivel a három dokumentumtípus közül a könyv tekinthető a legátfogóbbnak, ráadásul a hazai digitális könyvtárakban elsősorban könyvek feldolgozásával foglalkoznak, ezért azok szerkezeti jelölőelemeinek ismertetésével foglalkozunk részletesen DocBook fejléc metainformációk A TEI-hez hasonlóan a DocBook is rendelkezik saját beépített metaadat struktúrával, amely a dokumentum bibliográfiai és egyéb információit írja le. Minden DocBook alapú szöveg elé be kell illeszteni azt a fejlécet, melyben a könyvre vonatkozó metainformációkat a <bookinfo> 7 elem tárolja az alábbi egyszerű példa szerint hasonlóképpen a HTML oldalak <head> eleméhez, azonban itt jóval több információt, megfelelően tagolva adhatunk meg: <bookinfo> <title>xml elmélet és gyakorlat</title> <author> <surname>chris</surname> <firstname>bates</firstname> </author> <copyright> <year>2004</year> <holder>panem Könyvkiadó</holder> </copyright> </bookinfo> A példában kitűnően látszik, hogy a <bookinfo>-n belüli <title> elembe kerül a könyv címe. A szerzőségi közlést az <author> jelölőelembe kell tenni, ám ha a könyv csak szerkesztővel rendelkezik, úgy az <editor> jelölőt használhatjuk <author> helyett. A kereszt-, illetve vezetéknevek megkülönböztetésére mindkét elemben a <firstname> és a <surname> használható. A szerző munkahelyét, kiadóját, vagy más szervezeti kapcsolódását az <affiliation> tegben lehet megadni, a cím megadásához pedig az <address> jelölőelem hívható segítségül. Ha címet használunk, azt tagolni kell az <otheraddr>, a <street>, <city>, <country>, <postcode>, < > jelölőkkel. Amennyiben a könyv több szerző vagy szerkesztő munkájának eredménye, akkor az <authorgroup> segítségével csoportosítást is alkalmazhatunk: 5 Read The Book in English. [Elektronikus dokumentum.] URL: A letöltés időpontja Az OpenOffice programcsomag szövegszerkesztője például ilyen article típusú DocBook formátumba képes szöveges információkat menteni. 7 bookinfo. [Elektronikus dokumentum.] URL: A letöltés időpontja

79 Szövegjelölés DocBook DTD alapján <bookinfo> <authorgroup> <author> <honorific>dr.</honorific> <surname>kiszl</surname> <firstname>péter</firstname> <affiliation> <orgname>elte BTK</orgname> <address> <otheraddr>6-8.</otheraddr> <street>múzeum krt.</street> <city>budapest</city> <postcode>1088</postcode> <country>magyarország</country> </address> </affiliation> </author> <author> <surname>...</surname> <firstname>...</firstname> </author> </authorgroup> </bookinfo> A könyv kiadására vonatkozó adatokat az <edition> elembe tesszük, a kiadás évét pedig <pubdate>-tel jelöljük. Az elektronikus könyvre vonatkozó szerzői jogi információk: kiadás éve <year>, és a jogtulajdonos <holder> a <copyright> jelölőelemben kapnak helyet: <edition>2.</edition> <pubdate>2002</pubdate> <copyright> <year>2002</year> <holder>typotex Kft.</holder> </copyright> Abban az esetben, ha a szerzői jogokra vonatkozóan hosszabb magyarázó szöveg is tartozik a dokumentumhoz, akkor azt a <legalnotice> elembe kell tenni: <legalnotice><para>minden jog fenntartva. Jelen könyvet, illetve annak részeit tilos reprodukálni, adatrögzítő rendszerben tárolni, bármilyen formában vagy eszközzel elektronikus úton vagy más módon közölni a szerző és a kiadó engedélye nélkül.</para></legalnotice> A dokumentumot azonosító ISBN, ISSN vagy URL címet a <biblioid> elemmel jelöljük: 69

80 Szövegjelölés DocBook DTD alapján <biblioid>isbn </biblioid> [Megj.: A korábbi DocBook verziókban előforduló, de az új változatokban már elhagyandó <isbn> és <issn> tegeket NE használjuk!] Minden kulcsszónak a <keywordset> gyűjtőelemek között kell szerepelnie, az egyes kulcsszavakat pedig <keyword> jelölők közé kell tenni: <keywordset> <keyword>céginformáció</keyword> <keyword>üzeti információ</keyword> <keyword>információbrókerség</keyword> <keyword>könyvtár</keyword> </keywordset> A dokumentum rövid leírását, összefoglalóját az <abstract> jelöli, a kiadóját pedig a <publisher>. Amennyiben a kiadó címét is szerepeltetni akarjuk a fejlécben, úgy azt az <address>-ben tehetjük meg: <abstract>ez a könyv egy útikalauz, mely bevezeti olvasóit az XML alapú szövegfeldolgozás világába...</abstract> <publisher> <publishername>neumann Kht.</publishername> <address format="linespecific">budapest</address> </publisher> Abban az esetben, ha a kötetben változások történtek, akkor a <revhistory> elembe jegyezzük fel a módosításokat. Az eredeti könyv nyomtatásban való megjelenéseire vonatkozó információkat pedig a <printhistory> jelölőbe kell tenni. <revhistory>a lépcsős stíluslapokról szóló fejezet kibővül a 2.0-s ajánlás utasításkészletével...</revhistory> <printhistory>harmadik, változatlan utánnyomás.</printhistory> Az eddig bemutatott fejléc részletekből nagyon jól látszik, hogy a TEI-hez hasonlóan a DocBook esetén is kellően strukturált metaadat-szerkezet hozható létre. A következőkben összefoglalásként ennek a könyvnek az XML vezérlési utasítással és DOCTYPE deklarációval ellátott vázát mutatjuk be, amely a bookinfo-t is tartalmazza: 70

81 Szövegjelölés DocBook DTD alapján <!-- XML --> <?xml version="1.0" encoding="utf-8" standalone= no?> <!DOCTYPE book PUBLIC "-//EDUCATIO Kht.//DocBook V4.3-alapu DTD V1.1//HU" " <book xmlns:xsi=" lang="hu" xsi:nonamespaceschemalocation=" <bookinfo> <title>szövegfeldolgozás XML alapokon</title> <author> <honorific/> <surname>bíró</surname> <firstname>szabolcs</firstname> <affiliation> <orgname>neumann-ház</orgname> <address> <otheraddr>1-3.</otheraddr> <street>színház utca</street> <city>budapest</city> <postcode>1014</postcode> <country>magyarország</country> </address> </affiliation> </author> <edition>1.</edition> <pubdate>2005</pubdate> <copyright> <year>2005</year> <holder>bíró Szabolcs</holder> </copyright> <copyright> <year>2005</year> <holder>neumann Kht.</holder> </copyright> <legalnotice><para>minden jog fenntartva. Jelen könyvet, illetve annak részeit tilos reprodukálni, adatrögzítő rendszerben tárolni, bármilyen formában vagy eszközzel elektronikus úton vagy más módon közölni a szerző és a kiadó engedélye nélkül.</para></legalnotice> <biblioid>isbn </biblioid> <keywordset> <keyword>szövegfeldolgozás</keyword> <keyword>sgml</keyword> <keyword>xml</keyword> <keyword>xslt</keyword> <keyword>xpath</keyword> <keyword>css</keyword> <keyword>xhtml</keyword> </keywordset> <abstract>ez a könyv egy útikalauz, mely bevezeti olvasóit az XML alapú szövegfeldolgozás világába...</abstract> <publisher> <publishername>neumann Kht.</publishername> <address format="linespecific">budapest</address> </publisher> </bookinfo> <!-- Ide kerül a kötet jelölt szövege. --> <preface/> <chapter/> <bibliography/> <appendix/> <index/> </book> DocBook esetében ugyanúgy érvényes a TEI-nél tett megállapításunk, miszerint minél teljesebb egy fejléc, annál több metainformáció nyerhető ki belőle más formátumok számára DocBook szövegstruktúra 71

82 Szövegjelölés DocBook DTD alapján A DocBook dokumentum gyökere a <book> 8 elem, melynek lang attribútumában lehet meghatározni a feldolgozott szöveg nyelvét. Ezen belül elkülönül egymástól a már bemutatott könyvre vonatkozó metainformációk halmaza, valamint a könyv szerkezetének megfelelően tagolt tartalom. A fejlécet követően az ajánlás <dedication> 9, az előszó <preface> 10 kap helyet, majd ezt követik a könyv egyes fejezetei <chapter> 11. A bibliográfia a <bibliography> 12, a függelék az <appendix> 13, a tárgymutató pedig az <index> 14 elemben kell, hogy szerepeljen. Az egyes szerkezeti egységekhez tartozó címeket a <title> jelölővel kell ellátni: <book lang= hu > <bookinfo>... </bookinfo> <dedication>... </dedication> <preface> <title>előszó</title> <para>az egész a két- és hárombetűs rövidítésekkel kezdődött...</para> </preface> <chapter>... </chapter> <chapter>... </chapter> <chapter>... </chapter> <bibliography>... </bibliography> <appendix>... </appendix> <index>... </index> </book> A fő struktúrából látszik, hogy az elektronikus könyv szövege fejezetekre oszlik, amit <chapter> teggel jelölünk. Ezen belül öt szint mélységig tagolhatjuk az egyes alfejezeteket, <sect1>...<sect5>. A szakaszokon belüli, bekezdésszintű szövegegységet rendszerint a <para> jelöli: <chapter> <title>a Lundi alapelvek</title> <sect1> <title>a kezdetek</title> <para>az e-kultúra előretörésével világossá vált, hogy az európai kulturális műhelyek, a könyvtárak, egyetemek, más tartalomszolgáltatók esetleg nem fognak tudni megbirkózni a még zömmel papír alapú tudásbázisok átalakításával úgy, hogy azt kompatibilissé lehessen tenni az Unió felhasználói számára.</para> </sect1> </chapter> Az egyes fejezetekről és szakaszokról többféle metainformációt (kulcsszavak, nyelv, mottó) tárolhatunk ezek leírása az internetes dokumentációban megtalálható, azonban a legfontosabb a cím <title> megadása, mert a HTML formátumba való konvertáláskor ez jelenik meg <h1>...<h6> címsorként. Több nyelvű dokumentum esetén a magasabb szinten megadott lang="hu" vagy lang="en" stb. tulajdonságot felülbírálhatjuk. 8 book. [Elektronikus dokumentum.] URL: A letöltés időpontja dedication. [Elektronikus dokumentum.] URL: A letöltés időpontja preface. [Elektronikus dokumentum.] URL: A letöltés időpontja chapter. [Elektronikus dokumentum.] URL: A letöltés időpontja bibliography. [Elektronikus dokumentum.] URL: A letöltés időpontja appendix. [Elektronikus dokumentum.] URL: A letöltés időpontja index. [Elektronikus dokumentum.] URL: A letöltés időpontja

83 Szövegjelölés DocBook DTD alapján Fontos ügyelni a szakaszok megfelelő egymásba ágyazására, azaz egy <sect1>-en belül ne következzék rögtön <sect3>, hanem jelenjen meg a <sect2> elem is, még ha azon belül az alacsonyabb szintű szakaszon kívül más tartalmat nem helyezünk el. Ennek a hierarchiának a pontos betartása az XSLT-vel történő automatikus tartalomjegyzék-generálás miatt fontos DocBook esetén. Ha olyan hierarchiát szeretnénk kialakítani, ami az öt szintű, számozott szakaszokkal nem megoldható, ill. annál mélyebb szintig szükséges, a <section> 15 elemet használhatjuk, és tetszőleges számban önmagába ágyazhatjuk. Bekezdések esetében a <para> mellett két másik változat is alkalmazható: a <simpara> 16 azzal a megkötéssel használható, hogy nem tartalmazhat további bekezdésszintű blokként megjelenített elemeket, pl. listákat. A <formalpara> 17 olyan bekezdést jelöl, melynek kötelezően címet <title> is adunk. <simpara>ez a bekezdés nem tartalmazhat további bekezdéseket.</simpara> <formalpara> <title>ez a bekezdés címe.</title> <para>ide kerül a címmel ellátott bekezdés szövege.</para> </formalpara> A bekezdés szintjén érdemes megkülönböztetnünk a blokként és a szövegben folyamatosan (inline) megjelenített elemeket. A blokkelemek általánosságban a bekezdésszintű elemek, például: listák, táblázatok, a szövegből kiemelt képek, ábrák, képletek, idézetek stb. A legtöbb blokk elem tartalmazhat további blokkelemeket és folyamatos szöveget. Az inline elemek általában sortörés nélkül a szövegben jelennek meg, jelenlétüket betűstílus-váltás mutathatja, de legtöbbször ezeket nem is különböztetjük meg vizuálisan. Ezek az elemek tartalmazhatnak szöveget, illetve adatokat nevet, címet, kereszthivatkozásokat, formázott vagy alsó/felső indexben elhelyezett szöveget stb Szövegformázás Dőlt és félkövér betűstílust az <emphasis> 18 jelölőelem használatával állíthatunk be a szöveg egyes részeire. A paraméter nélkül megadott <emphasis> a legtöbb esetben dőlt betűs írásmódot jelent, míg a félkövér megjelenítést a role attribútum bevonásával érhetjük el: "..." <para>docbook-ban így lehet <emphasis role= strong >félkövér</emphasis> szöveget létrehozni.</para> "..." DocBook-ban így lehet félkövér szöveget létrehozni. Egyéb kiemelési lehetőségeket alaphelyzetben a Docbook DTD sem határoz meg, tehát a TEI esetében tett megállapításaink indokolt esetben itt ugyanúgy érvényesek lehetnek. A szövegen belül alsó és felső indexbe kerülő szakaszokat a <subscript> alsó index, illetve <superscript> felső index tegekkel jelölhetjük: <para>a víz képlete H<subscript>2</subscript>O.</para> <para>matematikában az a<superscript>2</superscript>+b<superscript>2</superscript>=c 15 section. [Elektronikus dokumentum.] URL: A letöltés időpontja simpara. [Elektronikus dokumentum.] URL: A letöltés időpontja formalpara. [Elektronikus dokumentum.] URL: A letöltés időpontja emphasis. [Elektronikus dokumentum.] URL: A letöltés időpontja

84 <superscript>2</superscript>.</para> Szövegjelölés DocBook DTD alapján A víz képlete H 2O. Matematikában az a 2 +b 2 =c 2. Általában érdemes törekedni arra, hogy a szöveg formázása önmagában ne hordozzon információt tekintettel a vakokra és gyengén látókra! Listák Felsorolások, listák készítésekor a DocBook megoldásai eltérnek a TEI-nél ismertetettektől. Ez elsősorban abban nyilvánul meg, hogy a DocBook dokumentumok külön jelölőelemet használnak a szimbólumok nélküli, a szimbólummal ellátott és a számozott listákhoz is - a TEI a type attribútumban tett különbséget. Ha például egy szimbólum nélküli, egyszerű felsorolásra nézünk mintát, akkor jól látszik, hogy az egész felsorolást a <simplelist> 19 jelölő fogja közre, az egyes listaelemek pedig <member> elemek közé kerülnek. Szimbólum nélküli lista: <simplelist> <member>listaelem</member> <member>listaelem</member> <member>listaelem</member> </simplelist> listaelem listaelem listaelem A megjelenítéskor ez az egyszerű lista viselkedhet pl. mondaton belüli felsorolásként, de ábrázolható sortöréssel is, minden tagja külön-külön. Amennyiben számozatlan, a sorok elején általában körrel vagy más grafikus szimbólummal jelölt listát szeretnénk készíteni, úgy az <itemizedlist> elemet kell segítségül hívni. A lista stílusa testre szabható az <itemizedlist> mark tulajdonságával. Az egyes listaelemeket <listitem> és <para> jelölőkkel kell ellátni. Szimbólummal rendelkező lista: <itemizedlist mark="disc"> <listitem><para>listaelem</para></listitem> <listitem><para>listaelem</para></listitem> <listitem><para>listaelem</para></listitem> </itemizedlist> listaelem 19 simplelist. [Elektronikus dokumentum.] URL: A letöltés időpontja

85 Szövegjelölés DocBook DTD alapján listaelem listaelem A felsorolás-objektumok egymásba ágyazhatóak, tehát egy <listitem>-en belül létrehozhatunk újabb, alacsonyabb szintű felsorolást vagy akár sorszámozott listát is, hiszen a megjelenítő programok és a konverterek képesek értelmezni, a megjelenés pedig úgyis a konverziós stíluslapon múlik. Sorszámozott felsorolás esetén az <orderedlist> elem numeration tulajdonságával megadhatjuk a sorszámozás stílusát arab számok, kis/nagybetűs római számok, kis/nagybetűs abc, illetve azt, hogy egy előző sorszámozott listát folytatunk-e. Egyéb számozási módok iránti igény esetén a DTD vonatkozó elemének attribútum-listáját módosítani kell a kívánt értékekkel, majd a konverziós stíluslapot szintúgy a megjelenés miatt. Számozott lista: <orderedlist numeration="arabic"> <listitem><para>sorszámozott listaelem</para></listitem> <listitem><para>sorszámozott listaelem</para></listitem> <listitem><para>sorszámozott listaelem</para></listitem> <listitem><para>sorszámozott listaelem</para></listitem> </orderedlist> 1. sorszámozott listaelem 2. sorszámozott listaelem 3. sorszámozott listaelem 4. sorszámozott listaelem Hiperhivatkozások, lábjegyzetek A Docbook hivatkozások létrehozásához kétféle jelölőelemet különböztet meg. Amennyiben a dokumentumban valamilyen URL-re akarunk hivatkozni, abban az esetben az <ulink> jelölővel helyezhetünk el hiperhivatkozásokat. Maga az URL az <ulink> elem url attribútumában kap helyet: <ulink url=" Kempelen Farkas Hallgatói Információs Központ és Könyvtár honlapja</ulink> A Kempelen Farkas Hallgató Információs Központ és Könyvtár honlapja A dokumentumon belüli hivatkozásokat a <link> elemmel hozhatjuk létre. Ezek a belső hivatkozások nemcsak a szöveg egy adott pontjára mutathatnak, hanem akár egész szakaszok is célját képezhetik a hivatkozásnak. Az ugrás kiindulópontját azonosító attribútum-értéket a linked jellemzőbe kell elhelyezni, majd a célhelyen az id tulajdonság értékeként szerepeltetjük. A működési elv teljesen azonos a HTML-ből jól ismert belső ugrópontok létrehozási mechanizmusával: 75

86 Szövegjelölés DocBook DTD alapján <sect1> <title>fejezetcím</title> <para>ebben a mondatban van egy <link linkend="nextsect">link</link>, ami a dokumentumon belül egy alfejezet meghatározott és elnevezett szakaszára mutat.</para> <sect2 id="nextsect"> <title>alfejezet</title> <para>ez az alfejezet az előző bekezdésben szereplő link célja.</para> </sect2> </sect1> Példánkban jól látszik, hogy a hivatkozás "nextsect" értéket kap, sugallva, hogy segítségével a következő fejezetre lehet majd ugrani. Az ugrópont célja ebben az esetben tehát maga az alfejezet lesz, mivel a <sect2> id -jében fordul elő ismét a "nextsect" attribútum-érték Táblázatok Táblázatok esetében szintén kétféle jelölőelemet használhatunk DocBook-ban. Cím és fejléc nélküli egyszerű táblázatot az <informaltable> 20 elemmel hozhatunk létre. Ennek gyermekeleme az a <tgroup>, ami egy táblázat valamely logikai egységét foglalja magába. A leggyakrabban használt egyszerű táblák általában egy <tgroup>-ból állnak. A <tgroup> elem cols tulajdonságával állíthatjuk be az oszlopok számát, a táblázat sorait a <row> elemmel jelöljük, ezen belül az egyes cellákat pedig az <entry>-vel. Az <entry>-k tartalmát bekezdésekbe szokás tenni nem kötelező. Az egyes oszlopok tulajdonságait (elnevezés, sorszámozás, szöveg igazítása stb.) a <colspec> elemmel állíthatjuk be. Ha nem szeretnénk, hogy a táblázatnak kerete legyen, akkor azt az <informaltable> frame attribútumában tilthatjuk le: <informaltable> <tgroup cols="2"> <tbody> <row> <entry>1</entry> <entry>1</entry> </row> <row> <entry>2</entry> <entry>4</entry> </row> <row> <entry>3</entry> <entry>9</entry> </row> </tbody> </tgroup> </informaltable> A bonyolultabb táblázatok, melyek összevont cellákat, táblafejet, címet tartalmaznak, a <table> 21 elemmel hozhatók létre: 20 informaltable. [Elektronikus dokumentum.] URL: A letöltés időpontja table. [Elektronikus dokumentum.] URL: A letöltés időpontja

87 Szövegjelölés DocBook DTD alapján <table frame="all"> <title>bonyolult táblázat</title> <tgroup cols="5" align="left" colsep="1" rowsep="1"> <colspec colname="c1"/> <colspec colname="c2"/> <colspec colname="c3"/> <colspec colnum="5" colname="c5"/> <thead> <row> <entry namest="c1" nameend="c2" align="center">vízszintes cellaösszevonás</entry> <entry>a3</entry> <entry>a4</entry> <entry>a5</entry> </row> </thead> <tfoot> <row> <entry>f1</entry> <entry>f2</entry> <entry>f3</entry> <entry>f4</entry> <entry>f5</entry> </row> </tfoot> <tbody> <row> <entry>b1</entry> <entry>b2</entry> <entry>b3</entry> <entry>b4</entry> <entry morerows="1" valign="middle"><para>függőleges cellaösszevonás</para></entry> </row> <row> <entry>c1</entry> <entry namest="c2" nameend="c3" align="center" morerows="1" valign="bottom">több sort és oszlopot átfogó cella</entry> <entry>c4</entry> </row> <row> <entry>d1</entry> <entry>d4</entry> <entry>d5</entry> </row> </tbody> </tgroup> </table> 6.1. táblázat - Bonyolult táblázat Vízszintes cellaösszevonás a3 a4 a5 b1 b2 b3 b4 c1 d1 Több sort és oszlopot átfogó cella d4 d5 f1 f2 f3 f4 f5 c4 Függőleges cellaösszevonás Példánk első ránézésre nagyon bonyolultnak tűnik, ám a megjelenítést követő végeredményt látva már könnyen értelmezhető. A <colspec> elemek colname attribútumában megadtuk az egyes oszlopok neveit. Erre azért 77

88 Szövegjelölés DocBook DTD alapján van szükség, mert a későbbi cellaösszevonásoknál ezek segítségével lehet megadni az összevonás kezdetét és végét. A <thead> tulajdonképpen a táblázat fejrészét takarja, ez megjelenítés során rendszerint élesen elkülönül az egyszerű cellatartalmaktól. A <tfoot>-ba az oszlopcímeket kell tenni és végül a <tbody> következik a tényleges táblázattartalommal. A cellatartalmak a HTML-ből jól ismert módon vízszintesen és függőlegesen is igazíthatóak! Médiaobjektumok: képek, ábrák, videók stb. Minden komplex szöveg kialakításánál szükség lehet képek, ábrák, egyéb illusztrációk beszúrására. A szövegbe beillesztett médiaobjektumokat videó, kép, hang az <inlinemediaobject> 22 elemmel jelöljük: <para>einstein leghíresebb egyenlete, <inlineequation> <inlinemediaobject> <imageobject> <imagedata fileref="figures/emc2.png"/> </imageobject> <textobject> <phrase>e=mc<superscript>2</superscript></phrase> </textobject> </inlinemediaobject> </inlineequation> kifejezi az anyag és energia közötti kapcso latot.</para> Einstein leghíresebb egyenlete, kifejezi az anyag és energia közötti kapcsolatot. Látható, hogy a médiaobjektum több, alternatív formában tartalmazhatja ugyanazt az információt. Erre szükség is van, pl. egy <imageobject> 23 grafikus objektumot a HTML formába való konvertáláskor így el tudunk látni megfelelő alt attribútummal. A médiaobjektumok használatakor fontos szem előtt tartani azt, hogy egy adott formátumot esetleg a célközönség/célmédia nem képes megjeleníteni. Éppen ezért mozgókép mellett használjunk egy elegendő információt tartalmazó állóképet, tekintettel a nyomtatható formátumokba való konvertálásra, illetve állókép mellett mindig adjunk meg elegendő szöveges információt, tekintettel a vakok és gyengén látók igényeire és az általuk használt felolvasó eszközökre. [Megj.: A DocBook V4.2-est követő verzióiból kimaradó <inlinegraphic> és <graphic> elemek helyett ezek például nem tárolnak alternatív szöveges információt a grafikus objektumról használjuk az <inlinemediaobject> vagy <mediaobject> elemeket.] Matematikai vagy más képletek A matematikai kifejezések, egyenletek használata a szakkönyvek készítésének egyik alapkövetelménye. Ha a szövegünkben matematikai kifejezéseket szeretnénk tárolni, erre két módszer közül választhatunk. DocBookban a képleteket tárolhatjuk képként és megadhatunk alternatív szöveget ahogy az előző Einstein-es példában láttuk, vagy MathML-t (is) használhatunk a képlet leírására. Ehhez a következő jelölőelemeket kell alkalmazni: <equation> 24 blokként formázott egyenlet; 22 inlinemediaobject. [Elektronikus dokumentum.] URL: A letöltés időpontja imageobject. [Elektronikus dokumentum.] URL: A letöltés időpontja imageobject. [Elektronikus dokumentum.] URL: A letöltés időpontja

89 Szövegjelölés DocBook DTD alapján <inlineequation> 25 szövegen belüli egyenlet; (ha grafikus objektumot tartalmaz, azt az <inlinemediaobject> használatával adjuk meg.) <informalequation> 26 kevésbé részletezett formában megadott (általában cím nélküli) egyenlet; <!-- XML --> <informalequation> <mml:math> <mml:mrow> <mml:mo> </mml:mn> <mml:mn>4</mml:mn> <mml:mo>+</mml:mo> <mml:mi>x</mml:mi> </mml:mrow> </mml:math> </informalequation> Példánkban a matematikai jelölőelemeket minden esetben megelőzi egy prefix, ami jelen esetben mml: formát ölt. Ennek használata nem kötelező, ám segítségével könnyebben megkülönböztethetők az egyes nyelvek jelölőkódjai XML-ben. 27 Sajnos a MathML még nem látszik minden browser-ben megfelelően pláne bonyolult képletek esetében. A használható megjelenítéshez még időnek kell eltelnie, ám ez nem meglepő ha tudjuk, hogy a piacon közel 90%- os részesedéssel rendelkező Internet Explorer is meglehetősen inaktív ebben a fejlesztési irányban. A W3C ajánlások implementálásának talán legnagyobb élharcosa a piacon 5-10% között mozgó, Mozilla ugyanakkor iránymutató fejlesztéseket végez. Ennek eredményeként a MathML nyelv megfelelő megjelenítése köszönhetően az egyre markánsabban megfogalmazódó igényeknek a közeli jövőben remélhetően megoldódik majd. Ám addig is szükség van alternatívákra. Ennek egyik jó példája a HIK módszere, hiszen ők az általunk elvárt elektronikus dokumentumban a képletek használatakor mindhárom formában kérik ugyanazt az információt: MathML-ben, képfájlban és szövegként is Sortöréssel formázott szövegek, versek Azokban az esetekben, amikor szükséges megtartanunk egy szöveg formázását - például egy vers sorait, az ilyen módon megjelenítendő szöveget a <literallayout> elemben tároljuk. <blockquote> <attribution>radnóti Miklós <citetitle>hetedik Ecloga</citetitle> </attribution> <literallayout> Látod-e, esteledik s a szögesdróttal beszegett, vad tölgykerités, barak oly lebegő, felszívja az este. Rabságunk keretét elereszti a lassu tekintet és csak az ész, csak az ész, az tudja, a drót feszülését. Látod-e drága, a képzelet itt, az is így szabadul csak, megtöretett testünket az álom, a szép szabadító oldja fel és a fogolytábor hazaindul ilyenkor. </literallayout> </blockquote> 25 equation. [Elektronikus dokumentum.] URL: A letöltés időpontja inlineequation. [Elektronikus dokumentum.] URL: A letöltés időpontja A prefixhasználat különösen konverziós stíluslapok írásakor jelentkezik halmozottan, hiszen ilyenkor rendszerint 2-3-féle nyelv utasításkészlete keveredik egymással. 79

90 Szövegjelölés DocBook DTD alapján Természetesen az egyes verssorokat külön <iterallayout>-ba is tehetjük, de jól látszik, hogy céljából adódóan pl. versek esetén nem igazán jó választás a DocBook ebben a TEI felé billen a mérleg nyelve Lábjegyzetek Szövegben lévő lábjegyzeteket DocBook-ban a <footnote> 28 jelölőelemmel, majd azon belül egy bekezdéssel kell ellátni. A lábjegyzetek készítésének módja rendkívül egyszerű, könnyen elsajátítható: <para>ha például egy ugrópontot szeretnénk lábjegyzetben a HIK tankönyvtárának honlapjára, könnyedén megtehetjük. <footnote><para> <ulink url=" lesz a lábjegyzet szövege, mögötte a hivatkozással az URL-ben szereplő honlapra.</ulink></para></footnote> Ugye, hogy nem bonyolult?</para> A lábjegyzetek számozására nem kell figyelmet fordítani, mert az a DocBook-hoz rendelkezésre álló konverziós stíluslapok segítségével a céldokumentumban HTML, PDF stb. automatikusan, a lábjegyzetek sorrendjének megfelelően jön létre Bibliográfia Az elektronikus dokumentumban bibliográfia is szerepelhet, melyet a <bibliography> elemmel jelölhetünk. Amennyiben több bibliográfiánk van, ezeket elláthatjuk megkülönböztető azonosítóval <bibliography id="bibl1">, illetve címmel <title>felhasznált irodalom</title>. Több szerző és a hozzájuk illeszthető paraméter esetén használandó a <bibliomixed>. A <bibliomset> foglalja magában a szerzőséget, a dokumentum címét, a kiadás évét és helyét, egy egyszerűsített jelölőelemben: <bibliography id="bibl1"> <title>felhasznált irodalom</title> <bibliomixed> <bibliomset>ábrahám István et al., <title><emphasis>kiadói ismeretek: útmutató tankönyvszerzők és -szerkesztők számára</emphasis></title>, Bp., 1993.</bibliomset> <bibliomset>énekes Ferenc, <title><emphasis>a kiadványszerkesztés: Alapok</emphasis></title>, Bp., 2000.</bibliomset> </bibliomixed> </bibliography> Többnyelvű szövegek, írásirány Az UTF-8 kódolás használatával nem csak latin karaktereket használhatunk, hanem a teljes közel-keleti és ázsiai írásjegy-készletet. Tehát abban az esetben, ha a szövegünk több nyelvű, mindig használjuk a korábban már ismertetett lang tulajdonságot az érintett szakaszban, pl. <sect2 lang="jp">: 28 footnote. [Elektronikus dokumentum.] URL: A letöltés időpontja

91 Szövegjelölés DocBook DTD alapján <sect1 lang="ru"> <title>возвращено в прокуратуру дело о нападении на Госнаркоконтроль<title> <para/> <sect1> A legtöbb országban az alapértelmezett írásirány a balról jobbra történő írásmód. Abban az esetben, ha vegyes írásirányú dokumentumokat hozunk létre, az alapértelmezett írásirányt felülbírálhatjuk az adott elem, pl. <setc1> <sect5>, <section>, <para> stb. dir="rtl" tulajdonságával. <sect1 lang="he" dir="rtl"> פרק במדבר< title > < title />א <para> ר ד א מד ר מ -א, ד א < para />:מ <sect1> A fejlett megjelenítő programok és elsősorban a webes megjelenítést végző böngészőprogramok megfelelően tudják kezelni a jobbról balra író nyelveket, így lehetséges kevert, a nyugati ábécét is használó, kétirányú szövegek megjelenítése. Ez a szolgáltatás kétirányú Unicode az Internet Explorer 5-ös verziójától érhető el, valamint a Gecko motort használó böngészőkben Mozilla, Firefox, Netscape, és az Opera 7.2 vagy újabb verzióinál A DocBook jövője Ebben a fejezetben értelemszerűen csak ízelítőt tudtunk adni a DocBook képességeiből, amely egy rendkívül nagy és összetett DTD. Figyelembe véve, hogy jelentős létszámú szerzői közösség használja és számos kereskedelmi, illetve ingyenes szoftver támogatja, jövője egyértelműen biztosított ennek a jelölésrendszernek is. A DocBook kiválóan alkalmas strukturált dokumentációk létrehozására, különösen a technológiai jellegű szakirodalom számítástechnika, informatika, műszaki tudományok stb. terén. Gyakorlatilag kijelenthetjük, hogy noha vannak átfedések, alapvetően más célokra érdemes használni TEI-t és másra DocBook-ot. Általános szerkezetű dokumentumok esetében kiválóan használható mindkét rendszer, de amint specialitásokról kritikai kiadások, versek, képletek stb. esik szó, dönteni kell. Lehet, hogy érdemes lenne komolyan foglalkozni a két DTD képességeinek egyesítésével TextBook? Nehéz ezt előre megjósolni, az mindenesetre bíztató, hogy folyamatos a kommunikáció a két fejlesztői közösség között. [Megj.: Magyarországon a DocBook-ot elsőként 2004-ben a Kempelen Farkas Hallgatói Információs Központ Kht. (HIK) 29 implementálta Felsőoktatási Digitális Tankönyvtárához (KFFDT) 30, tehát hazai viszonylatban ők rendelkeznek a legnagyobb tapasztalattal ennek alkalmazásában.] 29 Kempelen Farkas Hallgatói Információs Központ Kht. [Honlap.] URL: A letöltés időpontja Kempelen Farkas Felsőoktatási Digitális Tankönyvtár. [Honlap.] URL: A letöltés időpontja

92 7. fejezet - A megjelenítésről általában Ez a fejezet a megjelenítésre helyezi a hangsúlyt, és egyfajta áttekintésül szolgál a lehetséges output állományokról, illetve a létrehozásukhoz használható/szükséges technológiákból ad ízelítőt. Mivel a kötet terjedelme nem engedi meg, hogy konkrét példákon keresztül ismertessünk minden egyes módszert, ezért jelen esetben inkább azok alkalmazási lehetőségeire, és más formátumokkal való összefüggéseinek bemutatására fordítunk nagyobb figyelmet. Az SGML/XML-ből XHTML-lé történő megjelenítés részleteivel és lépéseivel a 8. Az XHTML, a 9. Lépcsős stíluslapok CSS és a XSLT és XPath c. fejezetek foglalkoznak részletesen. 1. Röviden a megjelenítésről Az eddig olvasottakból egyértelműen kiderülhetett mindenki számára, hogy az SGML/XML filozófia a formázás helyett a tartalomra helyezi a hangsúlyt. A formázási információk hiánya azonban fontos kérdés, főleg amikor a felhasználók számára szolgáltatható állományokról beszélünk. Ha megvizsgáljuk az alábbi SGML/XML részletet, akkor egyértelműen kijelenthetjük, hogy ebben a formában nem emészthető a hétköznapi emberek számára: <cim tipus="cim1">küldetésnyilatkozat</cim> <bekezd>a Neumann János Digitális Könyvtár és Multimédia Központ Kht. küldetése, hogy <kiemeles kover="1" dolt="1">részt vegyen a magyar kulturális örökség megőrzésének és közkinccsé tételének nagy feladatában</kiemeles>.</bekezd> A példa bemutatásához nyilvánvalóan nem elég egyszerűen egy megfelelő betűtípust kiválasztani és a jelöléseket eltávolítani, mert abból csak egy strukturálatlan folyószöveg lesz: Küldetésnyilatkozat A Neumann János Digitális Könyvtár és Multimédia Központ Kht. küldetése, hogy részt vegyen a magyar kulturális örökség megőrzésének és közkinccsé tételének nagy feladatában. Rendszerint sokféle technikát alkalmazhatunk a szövegek olvasmányosabbá tételére és a dokumentumok fontos összetevőinek kiemelésére. Néhányat említsünk meg ezek közül: betűtípus és szövegméret módosítása; színek és hatások használata; betűstílusok (félkövér, aláhúzott, dőlt) beállítása; margók, keretek, hivatkozások alkalmazása. Természetesen ezeket a technikákat eltérő mértékben használhatjuk a közzététel jellegétől és a feldolgozott könyv nyomtatott kiadásának megjelenésétől függően. Gondoljunk csak a sokszor unalmas egyetemi tankönyvek, a történelmi és irodalmi kiadványok, a szakkönyvek, netán a megragadó külsejű folyóiratok látványbeli különbségeire! 2. Stílusorientált szolgáltatási formátumok Az elmúlt évtizedekben, kimondottan dokumentum-formázási céllal, számos nyelvet fejlesztettek ki. Amellett, hogy az SGML/XML-lel ellentétben ezek a nyelvek teljes mértékben a szöveg tökéletes külalakjára 82

93 A megjelenítésről általában fókuszálnak, sokszor kompatibilitási problémákba is ütközünk használatukkor. Emlékezzünk csak, hányszor volt abból gond, ha egy újabb verziójú Word-ben megírt dokumentumot valahol máshol, egy régebbiben akartunk megnyitni! Rossz rágondolni, mi lesz a Word-del és más hasonló programokkal írt állományokkal tízhúsz év múlva! Ettől függetlenül, ugyanakkor ezek figyelembe vételével, a felhasználók számára ilyen megjelenés-orientált nyelvek (X)HTML, PDF, RTF stb. segítségével kell szolgáltatnunk SGML/XML-ben feldolgozott dokumentumainkat, hiszen ők ezeket használják, ezeket tudják megtekinteni, nekünk pedig első a felhasználóközpontúság! 2.1. (X)HTML A HTML (Hypertext Markup Language) hiperszöveg jelölő nyelv. Fő célja eredetileg az volt, hogy rendszert biztosítson a dokumentumok közti hypertext-kapcsolatok létrehozására, ám az e nyelv által definiált jelölés zömét mégis a dokumentumtartalom formázására használjuk. Valószínűleg elkerülhetetlen volt, hogy a HTML-t is utolérje az XML-esítés, így jött létre az immár XML alapokon nyugvó XHTML, amely elődjéhez hasonlóan formázásorientált jelölőelemeket használ (például <h1> cím1 szintű címsor, <p> bekezdés, <b> félkövér, <i> dőlt stb.). Persze nem az XHTML az egyetlen, amely ezt a megközelítést alkalmazza. Egyrészt az XHTML-nek több olyan változata is van, melyek adott kimeneti eszközre például mobiltelefonokra (WML) és elektronikus könyvekre (OEB) készültek. Az előbbiekben bemutatott küldetésnyilatkozat példát a következőképpen ábrázolhatjuk (X)HTML-ben: <!-- HTML/XHTML --> <h1>küldetésnyilatkozat</h1> <p>a Neumann János Digitális Könyvtár és Multimédia Központ Kht. küldetése, hogy <b><i>részt vegyen a magyar kulturális örökség megőrzésének és közkinccsé tételének nagy feladatában</i></b>.</p> Amennyiben valamilyen projekt keretében dokumentumokat dolgozunk fel SGML/XML-ben, lehetőség szerint mindenképpen biztosítani kell a felhasználók számára ezt a formátumot interneten keresztül. Az XHTML nyelvvel a Az XHTML c. fejezet foglalkozik részletesen! 2.2. PDF A PDF (Portable Document Format) hordozható dokumentum-formátumot jelent. Ahogy azt korábban már említettük, az Adobe azért hozta létre a nyelvet, hogy segítségével lehetővé váljon a mindenhol ugyanolyan méretarányokkal, betűformákkal és tördeléssel való megjelenés a legtöbb elterjedt formanyelv ugyanis ezt nem biztosítja. 1 Belenézve egy PDF forrásába, találhatunk értelmezhető, jelölt részeket: %PDF <</Pages 14 0 R/Type/Catalog/PageLabels 12 0 R/StructTreeRoot 17 0 R/Metadata 15 0 R/OCProperties<</D<</Order[]/RBGroups[]>>/OCGs[311 0 R]>>/PieceInfo<</MarkedPDF<</LastModified(D: )>>>> /LastModified(D: )/MarkInfo<</Marked true/letterspaceflags 0>>>> endobj obj<</type/ocg/name(headerfooter)/usage<</creatorinfo <</Creator(Acrobat PDFMaker 6.0 for Word)>>/PageElement<</SubType/HF>>>>>> 1 What is Adobe PDF? [Elektronikus dokumentum.] URL: A letöltés időpontja

94 A megjelenítésről általában A PDF a hordozhatóság megvalósításához az egyes elemeket betűkészleteket, képeket beágyazza magába a dokumentum fájlba. A vektorgrafikus képeket meghagyja vektorosnak 2, nem konvertálja őket pixelgrafikussá 3, ezáltal is elősegítve a minőség megőrzését. A nyelv hagyományos kiadványszerkesztői technológiákra épül, emiatt itt is a lap tekinthető a dokumentum alapegységének. A formátum egységességét az is biztosítja, hogy megjelenítéséhez/olvasásához speciális program, az ingyenes Adobe Reader 4 szükséges: Dokumentum az Adobe Reader ban A PDF használata napjainkra annyira bevált, hogy külön portáloldalak foglalkoznak az ilyen típusú dokumentumok készítésével és felhasználási lehetőségeivel. Alternatív megjelenítési lehetőségként tehát érdemes felkínálni a felhasználók számára PDF formátumban is feldolgozott dokumentumainkat RTF A Microsoft által kifejlesztett és a Word programból mindenki számára ismert, ám más szövegszerkesztő alkalmazásokban pl. OpenOffice is használt formátum az RTF (Rich Text Format). Az RTF formanyelvet különböző rendszerek között hordozható dokumentumok létrehozására fejlesztették ki. Az így megírt dokumentumok nem valók közvetlen kézi módosításra, ezeket vizuális szövegkezelő rendszerek használják belső formátumként, a formázási információt megfelelően értelmezve. Az RTF-et az különbözteti meg a szöveg- és kiadványszerkesztők által használt bináris belső formátumoktól, hogy a dokumentumok emberi szem számára olvashatók és szerkeszthetők is. A nyelv jól definiált leírással rendelkezik, így széles körben készíthetők olyan programok, amelyek közvetlenül feldolgozzák az RTF-ben kódolt szöveget és a benne tárolt formázási információt. Bizonyítandó, hogy az RTF is használ jelölőelemeket, tekintsünk bele egy olyan állomány forrásába, amely Times New Roman betűtípussal az alábbi szöveget tartalmazza: 2 A vektorgrafika objektumokkal manipulál, azaz a képek vektorokból egyenes és görbe vonalszakaszokból épülnek fel, ennek következtében a minőség romlása nélkül tetszőleges mértékben kicsinyíthetők és nagyíthatók. 3 A pixelgrafika pontokkal dolgozik (bittérképes), tehát a kép minden egyes képpontját eltárolja, aminek következtében nagy helyet foglal, sőt minőségromlás nélkül nem is méretezhető. 4 Adobe Reader. [Honlap.] URL: A letöltés időpontja

95 A megjelenítésről általában Formanyelvek {\rtf1\ansi\ansicpg1250\uc1\deff0\stshfdbch0\stshfloch0\ stshfhich0\stshfbi0\deflang1038\deflangfe1038{\fonttbl{\f0\ froman\fcharset238\fprq2{\*\panose }Times New Roman;}{\f38\froman\fcharset0\fprq2 Times New Roman;}... {\*\generator Microsoft Word ;}{\info{\title Formanyelvek}{\author Szabolcs B\'edr\'f3}{\operator Szabolcs B\'edr\'f3}{\creatim\yr2005\mo4\dy28\hr19\min50}{\revtim\yr2005 \mo4\dy28\hr19\min51}{\version1}{\edmins1}{\nofpages1}{\nofwords2} {\nofchars17}{\*\company Neumann Kht.} {\nofcharsws18}{\vern16437}}\paperw11906\paperh16838\margl1417\margr1... {\insrsid Formanyelvek}{\insrsid \par }} Amint ebből a kissé lecsupaszított, ám továbbra is elrettentő példából látszik, az RTF nyelv használ jelölőelemeket, ezek azonban nem alkalmasak általunk végzett közvetlen kézi beavatkozásra, kizárólag a szabványt ismerő programok/rendszerek képesek kezelni őket. A vastagon kiemelt részek hordozzák a lényegi információkat szerző, cím, intézménynév, betűtípus, szöveges tartalom, létrehozás és utolsó módosítás dátuma stb., a többi csupán a kompatibilitás miatt szükséges, ugyanis az RTF formátum lehetővé teszi a Word-ben szerkesztett dokumentumok megnyitását és szerkesztését, más cégek által fejlesztett szövegszerkesztőkben is például a már említett OpenOffice-ban. Erre nyilván csak akkor van lehetőség, ha az említett szoftver támogatja az RTF szabványt. Ezen kívül ez a formátum lehetőséget ad arra is, hogy egy korábbi Word verziót is használhassunk (pl. Word és ) legalábbis több-kevesebb sikerrel. Ha az előbb megtekintett dokumentumot pusztán kíváncsiságból ugyanazzal a címmel és tartalommal létrehozzuk egy, az RTF szabványt is támogató másik szoftverben OpenOffice, elvileg azt várnánk, hogy annak forráskódja ugyanolyan, vagy nagyon hasonló lesz. Íme az eredmény: {\rtf1\ansi\deff0\adeflang1025 {\fonttbl{\f0\froman\fprq2\fcharset238 Times New Roman;}... } {\info{\author Szabolcs B\'edr\'f3}{\creatim\yr2005\mo4\ dy28\hr16\min5}{\operator Szabolcs B\'edr\'f3}{\revtim\yr2005 \mo4\dy28\hr16\min6}{\printim\yr1601\mo1\dy1\hr0\min0}{\comment StarWriter}{\vern6450}}\deftab {\loch\f0\fs24\lang1033\i0\b0 Formanyelvek} \par } Noha látható, hogy a lényegi információk itt is megtalálhatók szabvány ide vagy oda, eltérő és rövidebb forráskódot kaptunk. Tulajdonképpen ilyen okokra vezethető vissza az is, hogy egy Word-ben elkészített és megformázott dokumentum nem mindig ugyanúgy néz ki egy másik szövegszerkesztőben, pedig mindkettő ugyanazt a szabványt támogatja. 85

96 A megjelenítésről általában Jelenleg az RTF 1.6-os specifikációja 5 a legújabb, ezt májusában bocsátotta ki a Microsoft Corporation. Alternatív megjelenítési formátumként érdemes szolgáltatni. 3. Stíluslapnyelvek Az alábbiakban leírt stíluslapnyelvek közül néhányat a tartalom közvetlen formázására használunk. Ugyanakkor egy másik részük valójában transzformációs nyelvként is funkciónál, hiszen csak így hozhatjuk létre azokat a bemutatott stílusorientált formátumokat, melyeket szolgáltatnunk kell a weben keresztül DSSSL A nagyon hatékony DSSSL (Document Style Semantics and Specification Language) nem más, mint egy dokumentum-stílus szemantikai és specifikációs nyelv. Több év fejlesztőmunkát követően 1996-ban lett ISO szabvány belőle. Eredetileg SGML dokumentumok formázására használták, de XML-hez is ugyanolyan jól alkalmazható. Mivel a nyelv meglehetősen összetett, ezért még mindig nagyon kevés szoftver támogatja 6, ráadásul sokszor a potenciális alkalmazói körök is kerülik, mivel szintaxisa szintén nem olyan egyszerű: <p>ebben a bekezdésben van egy <hi>dőlt</hi> betűs szó.</p> <!-- DSSSL --> (element p (make paragraph space-before: 10px font-size: 12px (process-children-trim) ) ) (element hi (make sequence font-posture: italic (process-children-trim) ) ) Ez a DSSSL stíluslap részlet tartalmazza az SGML/XML-ben jelölt szövegrészlethez tartozó formai beállításokat. Egyértelműen látszik, hogy a kimeneti szövegben minden bekezdés előtt egy 10 pixeles helyet kell kihagyni, a bekezdés szövegének 12 pixeles betűméretűnek kell lennie, valamint a szövegben található kiemelés dőlten jelenik meg. Szövegfeldolgozással foglalkozóknak érdemes tudni, hogy a nemzetközileg is elfogadott jelölésrendszerek közül elsősorban a DocBook formátumhoz érhetők el kész DSSSL stíluslapok, mivel nyomtatható anyagok az XSL későbbi kialakulása miatt csak ezzel voltak létrehozhatók. 7 Ha igényeinknek megfelelően szeretnénk átalakítani DSSSL-t tartalmazó állományt ezek kiterjesztése *.dsl, először meg kell találnunk benne a módosítani kívánt elemet, ki kell találnunk, hogy azt miként implementálták és végül át kell írnunk a kódot. Ez időigényes, különösen a kezdők számára, tehát a DSSSL lapok módosítását érdemes fejlesztőre bízni! A DSSSL-lel tehát SGML és XML állományokat egyaránt átalakíthatunk RTF, HTML stb. formátumokká a Jade, illetve OpenJade DSSSL processzorok segítségével. Ennek egy lehetséges módja a következő: openjade t rtf c dsssl/catalog d dsssl/docbook.dsl /usr/share/xml/openjade/xml.dcl szovegfeld.xml 5 Rich Text Format (RTF) Specification, version 1.6. [Elektronikus dokumentum.] URL: A letöltés időpontja A legszélesebb körben használt DSSSL feldolgozó a James CLARK fejlesztette Jade, illetve OpenJade. OpenJade Distrbution Page. [Honlap.] URL: A letöltés időpontja DocBook DSSSL Stylesheets. [Honlap.] URL: A letöltés időpontja

97 A megjelenítésről általában Az OpenJade indításakor a t kapcsolóval lehet megadni a kimeneti állomány típusát ez a mi esetünkben RTF. A c a DSSSL katalógusra 8 mutat, míg a d arra a stíluslapra, amit az átalakítás során használunk. Az indítási parancsban ezt követően az XML deklaráció, majd az átalakítandó állomány neve kell, hogy szerepeljen. Mindez ránézésre nagyon egyszerűnek tűnik, de összességében kijelenthetjük, hogy az OpenJade és a DSSSL lapok telepítése illetve konfigurálása első nekifutásra bonyolult, időigényes feladat CSS Noha a lépcsős stíluslapokkal a Lépcsős stíluslapok CSS c. fejezet részletesebben foglakozik, néhány gondolat ide kívánkozik a nyelvről. A CSS (Cascading Style Sheets), vagyis lépcsős stíluslapnyelvet 1996-ban fejlesztették ki, elsősorban HTML-lel való használatra. Célja eredetileg az volt, hogy segítségével szétválasztható legyen a tartalom és a forma HTML kódban. Az XML, majd az XHTML megjelenésével a CSS alkalmazási lehetősége kibővült, hiszen XML állományokat is formázhatunk vele: <!-- CSS --> p {display: block; margin-top: 10px; font-size: 12px;} hi {font-style: italic;} <!-- XML --> <p>ebben a bekezdésben van egy <hi>dőlt</hi> betűs szó.</p> Ebben a bekezdésben van egy dőlt betűs szó. Bekezdésünk tehát egy blokk szintű elem, mely előtt 10 pixeles felső margó lesz megjelenítéskor és 12 pixeles a benne elhelyezkedő szöveg mérete. A kiemelt szó a DSSSL-nél látottakhoz hasonlóan itt is dőlt lesz. A példából kitűnően látszik, hogy XML állományok formázásakor magukhoz a jelölőelemekhez kell hozzárendelni a kívánt stílusbeállításokat. Ha CSS-t XML-hez használunk, akkor az utasításokat mindig külön fájlban kell elhelyezni ennek kiterjesztése *.css, majd az XML deklaráció után a gyökérelemet közvetlenül megelőzve erre kell hivatkozni: <?xml-stylesheet type="text/css" href="*.css"?> Ha az XML-t értelmezni tudó böngészőprogramok ilyen utasítással találkoznak az XML parsing-olása közben, akkor a hivatkozott CSS állományban lévő stílusbeállításokat egyúttal alkalmazzák is arra. Mindez pedig azt eredményezi, hogy a browser ablakában már nem az XML fastruktúra válik láthatóvá, hanem annak formázott, felhasználók számára is értelmezhető kimenete. Miért találkozhatunk mégis ritkán ilyen megoldással? Nos, egyrészt azért mert a bemutatott folyamat során nem történik más formátumba (X)HTML, PDF, RTF stb. való transzformáció. Ez azt jelenti, hogy továbbra is az XML-t szolgáltatjuk a böngészőben, csak CSSsel sminkelve. Az időt és pénzt nem kímélve előállított forrásállományokat pedig nem szereti senki csak úgy elérhetővé/letölthetővé tenni mások számára. A CSS utasításkészlete nem vagy csak kis mértékben teszi lehetővé, hogy az XML tartalmakat ne a jelöléskor rögzített sorrendben jelenítsük meg. Az pedig egyáltalán nem lehetséges, hogy a kimenetben bizonyos szövegrészek ne szerepeljenek! Az SGML dokumentumok nem formázhatók közvetlenül CSS-sel, hiszen a böngészők nem képesek az SGML értelmezésére. A felsoroltak figyelembe vételével kijelenthetjük, hogy a CSS jó és mindamellett rendkívül könnyen elsajátítható stílus-beállítási nyelv, amely az utóbbi években rendkívül sokat fejlődött. Sajnos a legfrissebb verziók még mindig nem rendelkeznek kellő mértékű szoftvertámogatással, így implementációja a jelentősebb 8 Olyan fájl, amely a nyilvános azonosító és az annak megfelelő rendszerazonosító közti leképezéseket tartalmazza. Legtöbbször entitáskészletek alkalmazása esetén találkozhatunk vele. 87

98 A megjelenítésről általában böngészőkben sem mindig konzekvens bár ez egyértelműen a gyártók hibája. Ha alkalmazzuk, akkor elsősorban HTML és XHTML nyelveknél tegyük, irodalom, történelem és más tudományterületek feldolgozott állományait lehetőleg ne szolgáltassuk vele formázott XML-ben XSL Az XSL (extensible Stylesheet Language) 9 a legújabban megjelent szedési nyelv, szintaxisának alapjául az XML szolgál. A bővíthető stíluslapnyelvet eredetileg az egyszerű CSS és az összetett DSSSL szabványok közötti űr kitöltésére alakították ki, így a jellemzői is e két szabványból származnak. A nyelv alapszerkezete a DSSSL-ből ered, a stílus-beállítási tulajdonságait viszont a CSS-től örökölte: <!-- XSL --> <block>ebben a bekezdésben van egy <inline font-weight= bold >dőlt</inline> betűs szó.</block> Kezdetben az XSL-t egy olyan egyszerű nyelvnek szánták, amely az összes lehetséges transzformációt el tudja végezni a jelölt szövegeken. Ez az elképzelés azonban kivitelezhetetlen volt, hiszen a nyelv ilyen formában meglehetősen bonyolult lett volna. A problémát úgy sikerült megoldani, hogy a nyelvet két összetevőre bontották szét, vagyis létrehozták az XSLT (extensible Stylesheet Language Transformation) 10 ajánlást, amely SGML/XML struktúrák közti átalakításokra használható; és az XSL-FO-t (XSL Formatting Objects), ami pedig egy hagyományos stíluslap lehetőségeit kínálja megjelenésbeli stílusok, formák, helyzetek meghatározására. E két technológiát egészíti ki egy harmadik, az ún. XPath (XML Path Language), amely nem más, mint nyelvi kifejezéskészlet XML dokumentumokban való keresésre, kapcsolódások kialakítására és az egyes elemtípusokra alkalmazható környezetfüggő formázási lehetőségek megvalósítására. Az XPath a dokumentumot csomópontok (node-ok) halmazának tekinti. A node lehet bármilyen alkotórész: elem, attribútum, attribútumérték stb. E három nyelv együttesen alkotja tehát a bővíthető stíluslapnyelv családot. Gyakran előfordul, hogy az XSL és az XSLT kifejezéseket összekeverik és helytelenül használják még a fejlesztők is, de úgy gondoljuk, hogy a leírtakból már érthetők a különbségek és az összefüggések CSS vagy XSL Az XSL-t sokszor a CSS vetélytársának tekintik, annak ellenére, hogy az előbbi önmagában csak egy jelölőnyelv, az utóbbi pedig stíluslapnyelv. Alapesetben tehát egyik sem alkalmas transzformációra, hiszen mindkettőt más nyelvekkel rendszerint az XSLT-vel kell kombinálni más formátumokká való átalakításokhoz. Tulajdonképpen mind az XSL, mind pedig a CSS komoly jelöltek az XML dokumentumok stílusainak beállítására, így első ránézésre úgy tűnhet, hogy egymással versenyeznek a dominanciáért. Ennek ellenére semmi okunk nincs azt feltételezni, hogy a jövőben nem marad fenn mindkét ajánlás, hiszen nagyon eltérő erősségekkel rendelkeznek Stíluslap-kombinációk különböző kimenetekhez Az eddig leírtakból egyértelműen kiderül, hogy SGML-ben vagy XML-ben tárolt szövegeink leggyakrabban használt formátumokban való webes szolgáltatásához kénytelenek vagyunk konverziókat végrehajtani. Ehhez napjainkban az egyik legelterjedtebb és leghatékonyabb eszköz az XSLT. Az XSLT transzformációs nyelv elemeivel olyan szabályokat képezhetünk, amelyek segítségével egy XML dokumentumból egy másik általában XML formátumú dokumentumot hozhatunk létre. A transzformált XML dokumentum típusa lehet ugyanolyan, mint az eredeti dokumentumé, ugyanazokkal a jelölő elemekkel, de 9 The Extensible Stylesheet Language Family (XSL). [Elektronikus dokumentum.] URL: A letöltés időpontja Az XSLT valójában, noha transzformációs stíluslap, sokkal inkább tekinthető egyfajta sajátos programozási módszernek, nyelvnek, amely beépített vezérlési struktúrákat, nyelvi elemeket, paramétereket, változókat tartalmaz, csak éppen az XML szabályainak megfelelően, XML dokumentumként leírva. XSL Transformations (XSLT). [Elektronikus dokumentum.] URL: A letöltés időpontja

99 A megjelenítésről általában lehet teljesen különböző is. XSLT-vel például leírhatók az SGML/XML dokumentumok HTML, XHTML, WML stb. dokumentummá alakításának szabályai is az XSLT tehát kiváló módszer a konverzióhoz! HTML, XHTML kimenet Mivel az XSLT nyelvi elemkészlete alapvetően olyan sablonok írásához készült, melyek átalakításra képesek, ráadásul kombinálhatók más nyelvekkel, ezért azt mondhatjuk, hogy a CSS és az XSLT rendkívül jól kiegészítheti egymást. Különösen akkor igaz ez, ha a kívánt kimeneti formátum HTML vagy XHTML. Az XSLT az SGML/XML dokumentumokat egyaránt könnyedén HTML és XHTML állományokká alakíthatja, hogy javítsa a kapott dokumentum megjelenését és ugyanígy ért a kimeneti beillesztett CSS stílusokhoz, a beágyazott stíluslapokhoz, vagy létező külső CSS utasításokat tartalmazó állományokra való hivatkozáshoz. Az XSLT sablonok (template-ek) mindig az SGML/XML állománytól függetlenül, külön fájlban helyezkednek el ezek kiterjesztése *.xsl. Az ilyen állományok a CSS-nél bemutatotthoz hasonlóan szintén meghívhatók XML dokumentumok deklarációs részét követő, ám a gyökérelemét közvetlenül megelőző részében: <?xml-stylesheet type="text/xsl" href="*.xsl"?> Amikor a böngészőprogrammal megnyitunk egy XML állományt, akkor annak fordítója automatikusan elvégzi a sablonokban foglalt átalakítási és formázási utasításokat, majd megjeleníti a végeredményt. A módszer immár sokkal kevesebb hátránnyal rendelkezik, mint amit a CSS-sel formázott XML-nél láttunk, de így sem tökéletes. Problémák: Továbbra is az XML-t szolgáltatjuk, hiszen új kimeneti formátum, amit ráadásul el is tárolhatnánk, egyáltalán nem jön létre. Átmenetileg minden a böngésző memóriájában tárolódik, majd elvész. A módszer nem alkalmazható SGML esetén, mivel a böngészők nem képesek értelmezni az ilyen dokumentumok forrását. Hogy érthetőbb legyen a dolog, az alábbiakban tekintsünk meg egy egyszerű, CSS-sel kombinált XSLT sablont: <p>ebben a bekezdésben van egy <hi>dőlt</hi> betűs szó.</p> <!-- XSLT + XHTML + CSS --> <xsl:template match="p"> <p style="text-align: justify;"> <xsl:apply-templates/> </p> </xsl:template> <xsl:template match="hi"> <span style="font-style: italic;"> <xsl:apply-templates/> </span> </xsl:template> <!-- XHTML --> <p style= text-align: center; >Ebben a bekezdésben van egy <span style= font-style: italic >dőlt</span> betűs szó.</p> A példából kitűnően látszik, hogy kezdeti SGML/XML részletünkből a két sablon transzformáció után milyen HTML kimenetet produkál. A kicsit avatottabb szemnek az is kitűnik, hogy a template-ek háromféle nyelvből tartalmaznak utasításokat. Egyrészt szerepelnek benne XSLT parancsok, ezeket az xsl előtag jelöli kicsit megtévesztő, hiszen XSLT-ről van szó, de az ajánlás ezt határozta meg és noha a lehetőség megvan rá, nem szükséges tőle eltérni. Szerepelnek benne HTML jelölőelemek (<p> és <span>), melyek beágyazott CSS utasításokat tartalmaznak a style attribútumban (style="text-align: justify;" és style="fontstyle: italic;"). Sőt, hogy ne legyen olyan egyszerű a dolgunk, minden sablon esetén társul ezekhez XPath 89

100 A megjelenítésről általában is, a maga függvényeivel és logikai kifejezéseivel. Transzformációs stíluslapok készítésekor tehát meglehetősen otthonosan kell mozogni az egyes nyelvekben, W3C ajánlásokban. Az XSLT-ben leírt transzformációkat ideális esetben úgynevezett XSLT processzor programok hajtják végre. Ilyenekből nagyon sok létezik, ráadásul a legtöbb ingyenesen hozzáférhető. 11 Néhányat azért megemlítünk a leggyakrabban használtak közül: Omnimark, Xerces, XSLTproc, Saxon, Xalan stb. Ezek között vannak olyanok, amelyek SGML-ből is tudnak XML, XHTML és HTML konverziót végezni pl. Omnimark, XSLTproc, de a legtöbb XSLT processzor manapság már csak az XML-t tudja kezelni Saxon, Xalan és abból tud átalakítani XML, XHTML és HTML nyelvekbe. Bármelyiket is használjuk, lényege, hogy a konverziót követően létrejönnek a kimeneti állományok, melyeket eltárolhatunk és szolgáltathatunk. A nyelvvel és a konverziós módszerekkel a XSLT és XPath c. fejezet foglalkozik részletesen PDF-konverzió A PDF-fé alakítás már egy kicsit bonyolultabb, két lépésből álló folyamat. Az első lépésben a fentihez hasonló módon alakítjuk át a forrást, de a kimenet XSL-FO formátumú fájl lesz: <p>ebben a bekezdésben van egy <hi>dőlt</hi> betűs szó.</p> <!-- XSLT + XSL-FO --> <xsl:template match="p"> <fo:block font-size="12px" margin-top="10px"> <xsl:apply-templates/> </fo:block> </xsl:template> <xsl:template match="hi"> <fo:inline font-style="italic"> <xsl:apply-templates/> </fo:inline> </xsl:template> <!-- XML formázóobjektum --> <fo:block font-size="12px" margin-top="10px">ebben a bekezdésben van egy <fo:inline font-style="italic">dőlt</fo:inline> betűs szó. </fo:block> Jól látszik, hogy a formázóobjektumok is XML alapúak, tehát itt egyszerű XML2XML 12 átalakítással állunk szemben, amelyet bármelyik XSLT processzor képes kezelni. Xalan esetében a konverziós utasítás a következőképpen néz ki: java -cp.\bin\xalan.jar;.\bin\xml-apis.jar;.\bin\xercesimpl.jar org.apache.xalan.xslt.process -IN pelda.xml -XSL pelda.xsl -XML -OUT pelda.fo A Xalan számos kapcsolóval rendelkezik, az XML forrásállományt, a konverziós stíluslapot és a kimeneti fájl nevét azonban mindig meg kell adni. A tartalom mellett formázási parancsokat is tartalmazó fájlt formázóobjektumot végül egy XSL-FO processzor (formatting objects processor) segítségével alakíthatjuk át PDF-fé. Erre használható például a kereskedelmi forgalomban kapható XEP 13, mely a RenderX terméke, vagy a szabad forrású FOP 14, amely az Apache berkein belül született. Az ingyenes FOP esetén csak a formázóobjektumot tartalmazó fájl nevét és a kimeneti PDF állománynevet kell megadni: fop pelda.fo pelda.pdf 11 Free XML tools by category. [Elektronikus dokumentum.] URL: A letöltés időpontja XML2XML konverzió esetén az átalakítandó és a kimeneti állomány egyaránt XML formátumú. 13 RenderX Products. [Honlap.] URL: A letöltés időpontja FOP. [Honlap.] URL: A letöltés időpontja

101 A megjelenítésről általában A FOP amellett, hogy a formázóobjektumból létrehozza a PDF állományt, természetesen alkalmas XML és XSL fájlok feldolgozására is. Ennek ellenére javasoljuk, hogy főleg tesztelési időszakban az első fázist inkább XSLT processzorral végezzük, mert beszédesebb hibaüzeneteket ad, mint a FOP. Ha pedig már érvényes formázóobjektumokhoz jutottunk, akkor tudni fogjuk, hogy a FOP-tól kapott hiba az a formázóobjektumok transzformálásából, és nem maguknak az objektumoknak a létrehozásából származik. [Megj.: A fent nevezett XSL-FO processzorok legnagyobb hibája egyelőre az, hogy nem implementálják teljes mértékben az egyes W3C ajánlásokat. Emiatt előfordul, hogy a létrejövő XML kimenetben nem lesznek annyira szépek pl. a táblázatok, formázások stb. Ezek a problémák azonban időlegesnek tekinthetők és egyre kevésbé jelentkeznek, hiszen ahogy az XSL-FO felhasználói bázisa bővül, úgy a feldolgozók is tökéletesednek és előbbutóbb a kimeneti fájlok minősége megközelíti, illetve utoléri majd a speciális szedőrendszerekkel vagy szövegszerkesztőkkel létrehozott állományokét.] RTF-konverzió SGML vagy XML formátumból rendszerint DSSSL felhasználásával állíthatunk elő RTF formátumú fájlt, persze más lehetőségek is vannak. DocBook formátum esetén pl. viszonylag egyszerű a dolgunk, hiszen a konverzióhoz szükséges DSSSL stíluslapok letölthetőek a projekt honlapjáról. Ebben az esetben a konverziót az ingyenesen hozzáférhető Jade vagy OpenJade programokkal lehet elvégezni lásd.: DSSSL c. alfejezet. 91

102 8. fejezet - Az XHTML Azok a szakemberek, akik SGML/XML alapú szövegfeldolgozással foglalkoznak és a végeredményt a neten HTML/XHTML formátumban publikálják, tapasztalhatták, hogy a felhasználók rendkívül sokfélék lehetnek. Különböző operációs rendszereket használnak, eltérő böngésző programokat Internet Explorer, Mozilla, Mozilla Firefox, Netscape Navigator, Opera stb. futtatnak, így nagyon fontos lehet, hogy a tökéletes megjelenés érdekében az ajánlások szerint szolgáltassuk a feldolgozott dokumentumokat. Ebben a fejezetben természetesen nincs elég hely ahhoz, hogy az XHTML oldalak írásával kapcsolatos minden fontos tudnivalót összefoglaljunk példákon keresztül végigtekintsük a használható elemeket, ám ez nem is célunk, erre ott vannak a megfelelő szakkönyvek és azok a honlapok, amelyek kizárólag ezzel foglalkoznak. Ettől függetlenül fontosnak tartjuk, hogy megismertessük az olvasót azokkal a legalapvetőbb HTML-től való különbségekkel, amelyek az XHTML-t jellemzik. Bemutatjuk a nyelv szabályrendszerét, a karakterkódolási szabályokat, a DTD illetve névtérhasználat módját és az érvényesség ellenőrzési lehetőségeket, hiszen csak ezek segítségével garantálható felhasználóink számára hibátlan, ajánlásokat követő és nem utolsó sorban akadálymentes szolgáltatható formátum. 1. Mi is valójában az XHTML A HTML 1990 óta, azaz mintegy 15 éve szolgál a honlapok anyanyelvéül az interneten. Eddigi pályafutása alatt számos kiadása 1.0, 2.0, 3.0, 3.2, 4.0, 4.01 jelent meg és bátran kijelenthetjük, az adatok/információk többsége is e nyelv köré szerveződött. A webbel kapcsolatos formátumok többségének létrehozásáért és fejlesztéséért felelős koordináló szervezet W3C azonban december 24-én, a HTML 4.01 specifikációjának kiadásával a HTML mint leírónyelv fejlesztését befejezte. Ennek oka a HTML SGML alapú DTD-jének szabadossága, lazasága volt, ugyanis egyrészt mindannyiunk előtt jól ismert, hogy számos olyan jelölőelemmel rendelkezik, amelynek lezárása nem kötelező, másrészt azt is tudjuk, hogy ez néha milyen következményekkel jár a böngészőkben. Éppen emiatt a Konzorcium a továbbfejlesztés útját az 1999-ben kiadott XML ajánlás felé való közeledésben látta. Így született meg az XHTML nyelv, ami nem más, mint a HTML 4.01 megújítása, XML alapokon. A nyelv valójában nem más, mint a jelenlegi és jövőbeni dokumentumtípusok és modulok családja, amelyek reprodukálják, részét képezik, és kiterjesztik a HTML 4.01 ajánlást. Új elem nem került a létrejött specifikációba, azonban a meglevők használata jelentősen szigorodott. Az XHTML család dokumentumtípusai XML alapúak, és tulajdonképpen arra is lettek tervezve, hogy együttműködjenek az XML alapú felhasználói alkalmazásokkal. 1 A nyelvnek ez idáig két kiadása jelent meg a W3C égisze alatt ajánlás formájában: az XHTML 1.0 (2000. január 26.) és az XHTML 1.1 (2002. augusztus 1.). Az utóbbi kiadás nem egy újabb XHTML-változatot ír le, csupán az ajánlás szövegében történt változásokat és hibajavításokat közli. [Megj.: Érdemes tudni, hogy a W3C HTML Munkacsoport (HTML Working Group) május 27-én adta ki az XHTML 2.0 legújabb hetedik munkatervét. Az XHTML 2.0 a web ismert leírónyelveinek HTML 4.01, XHTML 1.0 és 1.1 rokona, de nem szándékozik felülről kompatibilis maradni azokkal. A munkaterv az XHTML 2.0 leírónyelvet és moduljait írja le, amelyek célja látványos, hordozható web-alapú alkalmazások létrehozása. 2 ] 1.1. Az XHTML létrejöttének okai Noha a HTML oldalaknak laza, de jól meghatározott és leírt SGML alapú típusdefiníciói, struktúrái vannak, a fejlesztők többsége mégsem használja ezeket a programozás során. Ennek több oka is van, jómagam is számos véleményt és megjegyzést hallottam a témáról. A legtöbb sajnos gyakran a hiányos ismeretekre és az XHTML érvényességének meg nem értésére vezethető vissza. Pedig a W3C ajánlásokkal nagyon izgalmas és 1 XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). What is XHTML? [Elektronikus dokumentum.] URL: A letöltés időpontja W3C hírek Archívum. [Elektronikus dokumentum.] URL: A letöltés időpontja

103 Az XHTML tetszetős weblapok készülhetnek, ráadásul egy szabványokat betartó honlap készítése nem több, mint az egyszerű szöveges weblapok generálása. Számos intézmény attól fél, hogy az ajánlások követése körülményes, sokba kerül. Nyugodtan kijelenthetjük: ez egyáltalán nincs így. A szabványokkal tervezve egy weblapot, annak kódja egyszerűbbé válik, mivel nincs több verzió a különböző böngészők számára. Oldalaink hosszabb életűek lesznek, könnyebb lesz a karbantartásuk és nem függnek többé a nem egyértelmű technológiáktól. Így a webes szabványokkal készített honlap tervezése valójában kevesebbe kerül. Sokan úgy vélekednek, hogy mivel a web egy szabad hely, senki nem kötelezheti a szabványok és ajánlások követését. Kétségkívül így igaz, ám ez a szabad hely olyan felhasználók millióival van megosztva, akiknek csak részben ismerjük az igényeit. A szabványokat pedig azért tervezték, hogy ne feledkezzünk el egyetlen potenciális érdeklődőről, felhasználóról sem. A netes közösségnek beleértve a könyvtárakat tehát igazi kihívás, hogy betartsák a webes szabványokat, mert csak és kizárólag ennek eredményeként nem fogunk egyetlen vállalathoz vagy saját technológiához sem tartozni gyakorlatilag platform-független megoldásokat alkalmazhatunk. Azok a fejlesztők, akik autodidakta módon kezdik el tanulni a HTML/XHTML oldalak szerkesztését, többnyire elrontják azokat tisztelet a kivételnek. Ha könyvekből szerezzük első ismereteinket, akkor azt tapasztalhatjuk, hogy sajnos sok könyv nem a helyes webprogramozásra tanít, mert a szerzők az ajánlásokat szinte teljes mértékben figyelmen kívül hagyják. Ráadásul ezt gyakorta megfejeli az a tény, hogy számos szerkesztőeszköz pl. FrontPage olyan kódot generál, ami nem érvényes. [Megj.: Egyes szerkesztőkbe szintaktika-ellenőrzőket ágyaztak, mások helyesen működnek és megint mások érvénytelen jelölést alkalmaznak.] Mindez azzal jár együtt, hogy kódunk helytelenül szervezett lesz és gyakran inkompatibilissé válik bizonyos böngészőkkel. A webböngészők pedig meglehetősen rugalmas programok, ugyanis átvesznek minden szeméttel teli kódot, és azokból megkísérelnek értelmes oldalakat generálni. 3 [Megj.: Egyetlen szerencsénk, hogy a browser-ek nem olyan szigorúak a HTML/XHTML oldalakkal, mint az XML állományokkal. Ellenkező esetben ugyanis virtuális univerzumunk jelentős része leállna, mivel bátran feltételezhetjük, hogy a weblapok több, mint 97 %-a érvénytelen persze nincsenek ezt alátámasztó statisztikák.] Napjainkban már egyértelműen látszik, hogy az internet a jövőben nem csak az asztali számítógépek alkalmazása lesz, hanem a kézi-számítógépek, mobiltelefonok és a jövő kommunikációs eszközeinek tekinthető, ún. okos telefonok egyik szolgáltatása. Ezekkel az eszközökkel szinte bárhonnan kapcsolódhatunk a világhálóra és böngészhetünk, azonban valószínűsíthető, hogy a szóban forgó gépek már nem tudják majd a hiányos, érvénytelen kódokat tökéletesen feldolgozni. Elsősorban tehát az említettek, és még számos más megfontolás vezetett arra, hogy a W3C átalakította az addig töretlenül sikeres HTML nyelvet XML-alkalmazássá. Mindez persze semmi újat nem jelent számunkra, ugyanis maga a nyelv nem változott ahogy már említettük, nem kerültek bele új elemek sem. Csupán arról van szó, hogy érvényes XHTML dokumentumok szerkesztésekor az XML alapoknak köszönhetően jóval szigorúbb követelményeknek kell megfelelni, az elemeket a megfelelő sorrendben kell kódolni, az attribútumértékek és a lépcsős stíluslapok használatával pedig biztosíthatjuk a platformfüggetlen megjelenést Az XHTML haszna Azzal, hogy sok fejlesztő már az XML-t használja adatstrukturálásra, nyereségre tesz szert, hiszen a jelölt elemek valós értelmet kapnak. Gondoljunk csak bele, hogy HTML-nél ez mennyire nem így volt. A h1... h6 elemek esetében például. noha az aktuális dokumentum címsoraira utalnak, valójában semmi nem kötötte a programozókat, hogy csak címeknél használják azokat. Sokkal inkább előfordult, hogy pusztán a megjelenés formája miatt jelöltek bizonyos szövegrészeket ezekkel az elemekkel. Ezzel persze elvesztettük dokumentumunk ama tulajdonságát, minek következtében valami módon pl. segédprogramokkal megtalálhattuk volna állományunk címsorait, hiszen vagy helyes válaszokat kapunk, vagy nem. Mindez persze 3 RAGETT, Dave: My web site is standard! And yours? / ford.: SIKOS László: Az én weblapom szabványos! És az Öné? [Elektronikus dokumentum.] URL: A letöltés időpontja

104 Az XHTML egy SGML/XML alapú TEI vagy DocBook segítségével strukturált szöveg esetében gyerekjáték, hiszen folyamatosan szemantikai információk rögzítése történik, a szintaktikáért már más felel. Ne gondolja a kedves olvasó, hogy a fentebb említett, HTML-nél tapasztalható probléma az XHTML-lel egy csapásra megoldódott. Az XHTML annak ellenére, hogy XML alapú, továbbra sem ad értelmet az egyes elemeknek, mégpedig azért, mert visszafele is kompatibilisnek kell lennie a HTML nyelvvel. Ha nem így lenne, akkor a nyelv oly mértékű átalakításon esik át, hogy a fejlesztőknek bizonyos szempontból újra kellett volna tanulniuk, ráadásul a böngészők megtanítása is szükséges lenne az új ajánlás értelmezéséhez, fordításához. Ehelyett a HTML-t az XHTML úgy változtatta meg, hogy az XML-nek megfelelő eszközökkel feldolgozhatóvá váljon és ne kapjunk hibaüzeneteket végeredményül. Így a webfejlesztők is létrehozhatnak az XML-nek megfelelő, az alkalmazások által automatikusan feldolgozható dokumentumokat, így nem kell ismételten megtanulnunk a már ismert képességeket. 4 Ha tehát megpróbáljuk összefoglalni az XHTML új hozadékait, egyértelműen kijelenthetjük, hogy azok az intézmények könyvtárak, levéltárak, oktatási intézmények stb., amelyek dokumentumaikat ezentúl XHTML formátumban teszik közzé, a következő előnyöket élvezhetik: Az XHTML dokumentumok megfelelnek az XML előírásainak, tehát könnyedén megtekinthetők, szerkeszthetők és érvényesíthetők a standard XML eszközökkel. Az XML-ben kódolt szövegekből lépcsős és bővíthető stíluslapok segítségével könnyedén előállítható szabványos XHTML formátum ugyanez a folyamat természetesen SGML esetében is működik. Az XHTML dokumentumok ugyanolyan jól szerkeszthetőek korábbi, HTML 4.01-et támogató felhasználói alkalmazásokkal, mint az új, XHTML 1.0-t és 1.1-et támogató felhasználói programokkal. Az XHTML dokumentumok hasznosíthatják az alkalmazásokat (scripteket és appleteket), amelyek futtatásához szükséges vagy a HTML Dokumentum Objektum Modell (DOM), vagy az XML Dokumentum Objektum Modell. 5 Ahogy az XHTML család fejlődik, az XHTML 1.0 és 1.1 kritériumainak megfelelő dokumentumok egyre jobban együtt tudnak működni különböző XHTML környezetekben. Végül majd lehetséges XHTMLkonform tartalmat fejleszteni, amely használható lesz bármely XHTML-konform böngészővel. A dokumentumfejlesztők és böngészőtervezők folyamatosan kutatják az új kifejezési lehetőségeket. Az XML-ben viszonylag könnyű új elemet vagy attribútumot bevezetni. Az XHTML családot úgy tervezték, hogy ezeket a kiterjesztéseket hozzáillessze az XHTML modulokon és technikákon keresztül az újonnan kifejlesztendő XHTML-konform modulokhoz. Mindezek az XHTML Modularizáció specifikációban 6 vannak részletezve. Ezek a modulok lehetővé teszik a létező és új tulajdonság-készletek kombinációját a tartalomfejlesztés és böngészőtervezés során. 2. XHTML típusdefiníciók Jól tudjuk, míg az SGML dokumentumokhoz mindig tartoznia kell DTD-nek, addig az XML állományokhoz csak az esetek egy részében kapcsolódik dokumentumtípus-definíció vagy XML Schema. Ezeket a DTD-ket általában az ellenőrző és a feldolgozó programok veszik igénybe annak megállapítására, hogy a jelöléseket megfelelően használtuk-e. Mivel a HTML nyelv SGML alapú DTD-kkel rendelkezik, ezért szerkesztéskor ezek valamelyikét definiálnunk kell a forráskódban, hogy később ellenőrizhessük fájlunk érvényességét. Az esetek többségében a legutóbbi verziók jelentik a legjobb választást, hacsak nem egy különleges közönséget, esetleg régebbi böngészőket célzunk meg. Az általunk kiválasztott verzió minden esetben meghatározza a használható elemeket és attribútumokat. Természetesen nem kivétel ez alól az XML alapú DTD-vel rendelkező XHTML sem. Minden XHTML dokumentum típusdefiníciója azonos formátumú. A deklarációk az alábbi formákat ölthetik: XHTML 1.0 esetén 4 BATES, Chris: XML: elmélet és gyakorlat. Bp.: Panem Kiadó, p DOM Document Object Modell (Dokumentum Objektum Modell) Programkezelő felület, amelyen keresztül a dokumentum szerkezete olyan módszerek segítségével érhető el, amelyek lehetővé teszik a dokumentumban az elemek kezelését vagy tartalmuk kiolvasását. 6 Modularization of XHTML. [Elektronikus dokumentum.] URL: A letöltés időpontja

105 Az XHTML <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" " XHTML 1.1 esetén <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " A deklarációkban jól látható, hogy a gyökér, vagyis a html elem kisbetűvel íródott. Aki kicsit is jártas a HTML programozásban, az tudja, hogy az említett nyelvben megengedett a kis- és nagybetűk használata, hiszen a működés szempontjából gyakorlatilag nincs különbség. Mindez abból fakad, hogy a HTML DOM eleve meghatározza az elem és attribútumnevek nagybetűs visszaadását. Az XML Dokumentum Objektum Modell viszont azt írja elő, hogy az elem- és attribútumneveket olyan betűvel kell visszaadni, amilyennel azokat megadtuk, vagyis az XHTML-ben az elemek és attribútumok neve kisbetűvel írandó a szövegben. XHTML 1.0 esetén három különböző DTD-ből válogathatunk, mégpedig strict, transitional és frameset: A strict kifejezés mindig szigorú megfeleltetésre utal. Az ilyen dokumentumok mindazon tulajdonságok meglétét megkövetelik, amelyeket az adott specifikáció kötelezőként jelöl meg pl.: DOCTYPE, gyökérelem <html> és xmlns attribútum használata. Mindemellett a szigorú megfeleltetés azt is magában hordozza, hogy egy ilyen dokumentumban minden megjelenéssel kapcsolatos utasítást lépcsős stíluslapoknak kell vezérelni. A transitional egyfajta átmeneti megfeleltetést jelent. A kifejezés elsősorban olyan oldalak esetében használatos, ahol a megjelenésért a CSS utasítások csak részben felelősek, ezáltal biztosítva a stíluslapokat nem, vagy csak bizonyos mér-tékben támogató böngészők számára is a hozzáférést. A frameset DTD használatával lehetővé válik a képernyő több önálló keretre való érvényes bontása. [Megj.: XHTML állományok forráskódjában a DOCTYPE utasítássort megelőzheti az XML deklaráció lásd.: XML-deklaráció c. alfejezet, ám alkalmazása nem kötelező, ellenben nagyon is javasolt. A használatot az teszi szükségessé, hogy a dokumentumok karakterkódolása az esetek többségében eltér az alapértelmezett UTF-8 - tól. Ha pedig magasabb szintű protokoll sem határoz meg más kódolási módot, akkor mindenképpen a fejlesztőnek kell megadnia azt!] 3. XHTML dokumentum-sablon A HTML dokumentumokhoz hasonlóan az XHTML is ugyanazt a szerkezetet követi, tehát rendelkezik vezérlőinformációkat tartalmazó fejléccel, illetve törzzsel. Értelemszerűen az utóbbiban található a képernyőn megjelenő tartalom, mindazon címkékkel, amelyek hatására a böngésző megformázza a dokumentumot. A következőkben bemutatunk egy olyan XHTML 1.0 Strict ajánlásnak megfelelő dokumentum-sablont, melynek példájában az XML deklaráció is szerepel, mégpedig latin-2-es kódkészlettel: <!-- XHTML --> <?xml version="1.0" encoding="iso "?> 95

106 Az XHTML <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " <html xmlns=" xml:lang="hu" lang="hu"> <head> <title>8. Az XHTML</title> <meta http-equiv="content-type" content="text/html; charset=iso " /> <meta http-equiv="content-style-type" content="text/css" /> <style type="text/css"></style> </head> <body> <h1>8. Az XHTML</h1> <hr /> <p>a HTML 1990 óta,...</p> </body> </html> Feltételezve, hogy a HTML-t már jól ismeri a kedves olvasó, nem térünk ki a kód minden részletére. Ennek ellenére láthatjuk az említett nyelvből már jól ismert módon, az XHTML-ben is a <html>... </html> elemek veszik közre a dokumentumot, jelezve a böngésző számára a feldolgozandó állomány típusát. Szembetűnő azonban, hogy az említett címkék tartalma jelentősen kibővült, mégpedig az oldallal kapcsolatos vezérlőinformációkkal: <html xmlns=" xml:lang="hu" lang="hu"> A dokumentum gyökérelemének az xmlns attribútum használatával jelölnie kell az XHTML névteret ez az értékként megadott címen 7 található meg. Jelen példa esetében a nyelv 1.0-ás névterét alkalmaztuk. Dokumentumunk nyelvhasználatát szintén a <html> címkében kell definiálni. Egy elem nyelvének megadásakor mind a lang, mind az xml:lang attribútumok használandók, ám nem hagyható figyelmen kívül, hogy az utóbbi értéke bármely más nyelvi deklarációval szemben elsőbbséget élvez. Amennyiben a dokumentum-sablon kódját fájlba mentjük és az állományt megnyitjuk valamelyik általunk használt böngészőben mi Firefox-ot használtunk, az alábbi eredményt kapjuk: XHTML dokumentum-sablon Firefox ban 3.1. Dublin Core kódolás XHTML-be Mindannyian tudjuk, hogy a feldolgozott dokumentumok számbavétele, szolgáltatása és archiválása szempontjából kiemelkedően fontosak a formai, illetve tartalmi jellemzőket leíró metaadatok. A legtöbbször említett probléma sokáig az volt, hogy a formai feltárás hagyományos eszközeivel nem lehet minden további nélkül megoldani a digitális dokumentumok feldolgozását. 8 Elsősorban ez vezetett azokhoz a struktúrájukban 7 XHTML namespace. [Elektronikus dokumentum.] URL: A letöltés időpontja SÜTHEŐ Péter: Elektronikus, digitális, virtuális könyvtárak. In.: Könyvtárosok kézikönyve 3. / szerk.: HORVÁTH Tibor, PAPP István. Budapest : Osiris, p

107 Az XHTML jóval egyszerűbb és kevesebb elemet tartalmazó metaadatrendszerek kialakulásához, melyek közül a legismertebb és mára kvázi szabványként alkalmazott a Dublin Core. Az egyszerű DC mindössze 15 elemből áll, így feltárásra csak bizonyos korlátok között alkalmas, sőt probléma az is, hogy az alkalmazásfejlesztők gyakran válogatnak, új értelmezést adnak az elemeknek. Ez vezetett tulajdonképpen a precízebb és kidolgozottabb Qualified Dublin Core, vagyis a Minősített Dublin Core létrejöttéhez. [Megj.: A Dublin Core-nak 2004-ben került a köztudatba ez a minősített változata, amely már sokkal fejlettebb a feltárás terén, ugyanis az elemek jelentését finomítani lehet (pl. dátum esetén készítés, nyilvánosságra hozatal, módosítás stb.), illetve az elem értékét megadott formátum szerint vagy listákból kiválasztva lehet megadni (pl. dátum formátum, típus elem értékére DCMI Types). A QDC rekordok tehát strukturáltabbak és kevesebb bennük a szabad szöveges információ. A DCMI (Dublin Core Metadata Initiative) igyekezett összegyűjteni a hasznos értékmegadási sémákat (pl. DDC, LCSH, TGN, W3C-DTF), és ahol szükséges volt, maga készített ilyeneket (pl. DCMI Box, DCMI Period).] 9 A Dublin Core 10 éves pályafutása alatt olyannyira elterjedt, hogy a dokumentum feldolgozással és metaadatokkal foglalkozók számára kikerülhetetlen a vele való találkozás. Miért? Gondoljunk csak bele, hogy pl. a könyvtári integrált rendszerek által használt MARC formátumból, a TEI vagy DocBook fejlécből stb. megfeleltetéssel előállítható az a Dublin Core nézet, melyet később esetleg harvestelni (aratni) tud egy nyílt forráskódú begyűjtő protokoll OAI, Zing stb., valamely metaadat szolgáltató számára. A szolgáltatási ponton keresztül pedig a metaadatok segítségével dokumentumaink ugyanúgy kereshetővé válnak, mint saját könyvtári katalógusunkból, és mindez a DC formátumnak köszönhető. Ez persze egy a lehetséges felhasználási területek közül. Számunkra azonban most inkább a DC rendszer ama előnye érdekes, miszerint számos nyelvbe XHTML, XML, RDF stb. kiválóan beépíthető és a böngészőprogramok is kezelik. Ha pedig így van, akkor ezt a tulajdonságot felhasználhatjuk annak érdekében, hogy pl. feldolgozott szövegeink XHTML verzióját a keresőrobotok könnyebben indexeljék, azokról több információhoz jussanak. Célunk eléréséhez nincs más teendőnk, minthogy weboldalaink <head>... </head> részében a <meta> és <link> elemek felhasználásával leírjuk állományunk tartalmi és formai jellemzőit. Az alábbi példa az egyszerű DC kódolását mutatja be XHTML állományok forrásába: <!-- XHTML --> <head> <link rel="schema.dc" href=" /> <meta name="dc.title" content="expressing Qualified Dublin Core in HTML/XHTML meta elements" /> <meta name="dc.creator" content="andy Powell, UKOLN, University of Bath" /> <meta name="dc.contributor" content="simon Cox" /> <meta name="dc.contributor" content="eric Miller" /> <meta name="dc.date" content=" " /> <meta name="dc.identifier" content=" /> <link rel="dc.relation" href=" /> <meta name="dc.description" content="this document describes how qualified Dublin Core metadata can be encoded in HTML/XHTML <meta> elements" /> <meta name="dc.format" content="text/html" /> <meta name="dc.type" content="text" /> </head> Ugyanennek a Dublin Core Metadata Initiative (Dublin Core Metaadat Kezdeményezés) oldalán található szöveges dokumentumnak 10 minősített változata is létezik, amelyet a következő példa szemléltet: 9 KISS Gergő, KOVÁCS László, MICSIK András: HEKTÁR: Hazai elektronikus könyvtári rendszerek összekapcsolása. [Elektronikus dokumentum.] URL: A letöltés időpontja POWELL, Andy: Expressing Dublin Core in HTML/XHTML meta and link elements. [Elektronikus dokumentum.] URL: A letöltés időpontja

108 Az XHTML <!-- XHTML --> <head> <link rel="schema.dc" href=" /> <link rel="schema.dcterms" href=" /> <meta name="dc.title" lang="en" content="expressing Dublin Core in HTML/XHTML meta and link elements" /> <meta name="dc.creator" content="andy Powell, UKOLN, University of Bath" /> <meta name="dc.contributor" content="simon Cox" /> <meta name="dc.contributor" content="eric Miller" /> <meta name="dcterms.issued" scheme="dcterms.w3cdtf" content=" " /> <meta name="dc.identifier" scheme="dcterms.uri" content=" /> <link rel="dcterms.replaces" hreflang="en" href=" /> <meta name="dcterms.abstract" content="this document describes how qualified Dublin Core metadata can be encoded in HTML/XHTML <meta> elements" /> <meta name="dc.format" scheme="dcterms.imt" content="text/html" /> <meta name="dc.type" scheme="dcterms.dcmitype" content="text" /> </head> A forráskódok anélkül is kitűnően bemutatják a DC használatát, hogy annak részleteibe komolyabban belemerülnénk. Annyit azonban mindenképp meg kell említeni, hogy mindkét esetben a szükséges névterek <link> elembe való definiálásával kezdődik a kódolás. Egyszerű DC esetében: <link rel="schema.dc" href=" /> Minősített DC használatánál: <link rel="schema.dcterms" href=" /> A meghatározott névterek tulajdonképpen XML alapú RDF 11 állományokat takarnak, melyek leírják és meghatározzák az egyes Dublin Core elemeket és azok minősítőit. A <meta> elemben a name és a content attribútumokat használjuk a 15 DC adatelem megadásához és leírásához: <meta name="dc.elemnév" content="érték" /> Minősítők használata esetén ugyanez az elv érvényesül: 11 RDF Resource Description Framework (erőforrásleíró keretrendszer) Olyan szöveges formátum, amely az erőforrások és metaadatok leírását támogató alkalmazások számára készült. Ilyenek lehetnek a zenei műsorrendek, fotókollekciók, bibliográfiák stb. Az RDF a szemantikus web kutatási terület egyik alapvető eszköze. Resource Description Framework (RDF). [Elektronikus dokumentum.] URL: A letöltés időpontja

109 Az XHTML <meta name="dcterms.elemnév" content="érték" /> <meta name="dcterms.elemnévminősítő" content="érték" /> A példákban bemutatott elemeket nem szükséges az XHTML konverzió után manuálisan elhelyezni az állományok <head> részében, ugyanis ha az SGML/XML forrásunk jól strukturált és bibliográfiai információkat magában foglaló fejlécet is tartalmaz, akkor a metaadatok jelentős része ahogy azt már többször is említettük a kódok felhasználásával automatikusan kiolvasható például XSLT használatával, tehát csak kritikus esetekben kell manuális-intellektuális munkát végezni. Jó hír a weboldalak szerkesztőinek, hogy számukra is létezik olyan megoldás, melynek segítségével bizonyos fokig automatizálhatják oldalaik metaadatosítását. Az angliai Bath Egyetemen az UKOLN, Andy POWELL vezetésével, készített egy DC-dot 12 nevű Dublin Core metaadat szerkesztő eszközt, mely bárki számára elérhető az interneten. Weboldalunkhoz tartozó DC adatok kinyeréséhez mindössze meg kell adni az URL címet és a Perl-ben írt program már el is készíti azt a kimásolható adatlistát, melyet beilleszthetünk forrásállományunkba. Nagyon fontos, hogy görög, cirill, ékezetes stb. karaktereket tartalmazó szövegekben csak azok Unicode-ban tárolt megfelelőjét tudja értelmezni a szoftver. 4. XHTML szabályok Noha az XHTML 1.0 ugyanazt az elemkészletet tartalmazza, mint a HTML 4.01-es verziója, az elemek használatának módja jelentős mértékben megszigorodott. Az ok egyszerű. Míg a HTML 4.01 valójában SGMLalkalmazás hiszen a mögöttes DTD-jét, annak teljes elem-, attribútum- és entitáskészleteivel együtt az SGML nyelv szabályai szerint definiálták, addig az XHTML egy XML-alkalmazás. Mivel az XML az SGML egyszerűsítéséből és szigorításából jött létre, így triviálisan következik, hogy az XHTML-nek is szigorúbbnak kell lennie a HTML-nél, vagyis bizonyos eljárásokat, amelyek tökéletesen működnek az SGML alapú HTML 4.01-ben, meg kell változtatni az XHTML-ben való működéshez Különbségek a HTML 4.01-től 1. Az XHTML nyelvű dokumentumokban minden HTML elemet és attribútum nevet kisbetűvel kell írni. Ez lényeges, hiszen az XML kis- és nagybetű érzékeny, tehát pl. a <p> és <P> két különböző elemet jelöl. 2. A HTML 4.01 bizonyos elemeknél megengedte a záró címkék elhagyását ilyen esetben a következő elem kezdete zárta az előzőt. Az XML ugyanezt tiltja, illetve minden elemnek, amely a DTD-ben nem empty-ként (üres) van deklarálva, rendelkezni kell záró címkével is. A DTD-ben üresként deklarált elemeknek pedig vagy záró címkével kell rendelkezniük, vagy jelölni kell az üres elemet. Helytelen: <p>bekezdés Helyes: <p>bekezdés</p> Üres elem kezelése: 12 DC-dot Dublin Core Metadata editor. [Honlap.] URL: A letöltés időpontja

110 Az XHTML <hr></hr> vagy <hr /> 3. Numerikus vagy szöveges attribútum-értékektől függetlenül minden attribútumot idézőjelek között kell szerepeltetni. Helytelen: <div align=left>tartalom</div> <hr width=75%></hr> Helyes: <div align="left">tartalom</div> <hr width="75%"></hr> vagy <hr width="75%" /> 4. Bár szövegfeldolgozás során nem valószínű, hogy találkozunk vele, de nem árt tudni, miként az XML, úgy az XHTML sem támogatja az attribútumok minimalizációját. Az attribútumérték-párokat teljességükben ki kell írni, tehát nem szerepelhetnek az elemekben értékük meghatározása nélkül. Helytelen: <input id="valami" type="radio" value="radio" checked /> Helyes: <input id="valami" type="radio" value="radio" checked="checked" /> 5. Az XHTML 1.0-ban a name attribútumot lecserélték és id lett a neve. Az ajánlás említett verziója még megengedi a name használatát a visszamenőleges kompatibilitás miatt, ám az újabb kiadások már teljes mértékben kizárják azt. 6.XHTML-ben a script és style elemek deklarációjuk szerint #PCDATA tartalmúak. Ennek eredményeképpen a < és & karakterek jelölő kezdeteként vannak értelmezve, egyedeiket (<, &) az XML értelmezők egyedhivatkozásként ismerik fel. Egy szkript vagy stíluselem tartalmának CDATA jelölésű részbe csomagolásával elkerülhető ezen egyedek kibontása, mivel a CDATA szekciókat az XML értelmező felismeri, és a Dokumentum Objektum Modell szerinti csomópontokként kezeli. <script type="text/javascript"> <![CDATA[ // A script helye. ]]> </script> 100

111 Az XHTML 7. A jól formáltság kritériumának teljesüléséhez XHTML-ben az egymásba ágyazott címkéket a deklarálás sorrendjével ellentétesen kell lezárni, tehát az átlapolás nem megengedett. Helytelen: <p>ez itt egy <b>félkövér szövegrész</p></b> Helyes: <p>ez itt egy <b>félkövér</b> szövegrész</p> 8. Hexadecimális karakterértékekkel való hivatkozás esetén XHTML-ben a kisbetűs verziót kell használni. Helytelen: Pl. É betű esetén É Helyes: Pl. É betű esetén É 4.2. Elemhasználati tilalmak XHTML-ben a következő elemekre vonatkoznak egymásba ágyazási tiltások. Ezek a tiltások a beágyazás minden szintjére érvényesek, vagyis a leszármazott elemekre is. A szövegfeldolgozás kapcsán csak néhánnyal kell dolgoznunk, ám itt sem árt, ha tisztában vagyunk a lehetőségekkel: a - Nem tartalmazhat más a elemeket. pre - Nem tartalmazhatja az img, object, big, small, sub, vagy sup elemeket. button - Nem tartalmazhatja az input, select, textarea, label, button, form, fieldset, iframe vagy isindex elemeket. label - Nem tartalmazhat más label elemet. form - Nem tartalmazhat más form elemet Karakterkódolási szabályok Az interneten található információk a világ számos országában hozzáférhetőek, azonban különböző helyeken különböző operációs rendszereket, nyelveket, karakterkészleteket és karkaterkódolást használnak az olvasók. Az egyszerű szövegfájlokban semmilyen plusz adat nem áll rendelkezésünkre az adott fájl karakterkódolására vonatkozóan, az XML, XHTML dokumentumoknál viszont nagyon fontos, hogy megadjuk ezek kódolását. Erre háromféle lehetőségünk van: 1. A webszerver HTTP Content-Type fejlécében, például: 101

112 Az XHTML Content-Type: text/html; charset=iso Az XHTML dokumentumok elején a vezérlési utasításban, vagy egy dokumentumegység kezdetekor, például: <?xml version="1.0" encoding="utf-8"?> 3. XHTML fájlokban a <meta> tag használatával, például: <meta http-equiv="content-type" content="text/html; charset=iso " /> Annak érdekében, hogy a dokumentumok hordozhatóak legyenek az adott karakterkódolással, a legjobb megoldás azt biztosítani, hogy a webszerver megfelelő fejlécet szolgáltasson, azonban jó gyakorlat mind az XML deklarációban, mind a meta elemben beállítani a karakterkészletet. Sajnos beállítástól függően a szerver felülírhatja a fájlban lévő kódolási utasítasokat, vagyis még ha az állományunk UTF-8-ban is van, ám a HTTP Content-Type headerje az ISO utasítást tartalmazza, akkor azt fogja továbbítani a böngészőnek, és a böngészők egy része például a Mozilla ezt bizony komolyan veszi mint legmagasabb prioritást. Ebben az esetben pedig a megjelenítés rossz lesz. Alapvetően fontos tehát, hogy a szerver beállítása megegyezzen a karakterkódolással! Tudjuk, hogy a W3C XHTML szabványa nem írja elő, hogy melyik karakterkészletet és milyen kódolást kell használni a weben, de annyi megszorítást tesz, hogy annak leképezhetőnek kell lennie a Unicode karakterkészletére. A konzorcium ajánlja a Unicode használatát, mint a legáltalánosabb karakterkészletet. Azon belül a magyar nyelv számára az UTF-8 kódolás, míg például az ázsiai nyelveknek az UTF-16 az előnyösebb. Digitális gyűjtemények XHTML formátumú szolgáltatásakor erre különösen nagy hangsúlyt fektessünk, ugyanis mindennek megfelelően kell megjelennie a böngészőkben is! [Megj.: Fontos meggyőződni arról is, hogy ha egy dokumentumnak tartalmaznia kell a karakterkódolás deklarációt egy meta http-equiv utasításban, akkor a dokumentum mindig értelmezhető a HTTP szerverek és/vagy felhasználói alkalmazások által, az utasításban definiált internet médiatípusként. Ha egy dokumentum több médiatípusként is használatos, a HTTP szervernek kell beállítania a dokumentum kódolását.] 5. Vegyes DTD-k használata XHTML-ben A XHTML dokumentum-sablon c. alfejezetben is deklarált XHTML DTD használható más típusdefiníciókkal is, bár az ilyen dokumentumok nem szigorú megfelelésű XHTML 1.0 állományok lesznek. Azokat a W3C által létrehozott címzési módokat, melyek több DTD-t, illetve névteret használó állományok esetén meghatározzák a dokumentumok megfelelőségét, a következőkben mutatjuk be MathML DTD és névtér A TEI és a DocBook ismertetésekor már szó esett róla, hogy szövegfeldolgozás során elsősorban szakirodalmi szövegek esetében számos esetben előfordulhat, hogy matematikai képleteket találunk a dokumentumokban. Arról is említést tettünk, hogy az egyes böngészők eltérő módon és szinten jelenítik meg ezeket a képleteket, tehát a megjelenítés mind a mai napig sarkalatos pont. De hogyan is épül fel egy MathML állomány? A következőkben a mindenki számára jól ismert Pitagorasz-tételen mutatjuk be a leglényegesebb összetevőket: <!-- MathML --> <?xml version="1.0" encoding="iso "?> 102

113 Az XHTML <!DOCTYPE math PUBLIC "-//W3C//DTD MathML 2.0//EN" " <math xmlns=" <mrow> <msup> <mi>a</mi> <mn>2</mn> </msup> <mo>+</mo> <msup> <mi>b</mi> <mn>2</mn> </msup> <mo>=</mo> <msup> <mi>c</mi> <mn>2</mn> </msup> </mrow> </math> a 2 +b 2 =c 2 Jól látszik, hogy a matematikai jelölőnyelv is XML alapú, tehát vezérlési utasítással kezdődik, amit a DOCTYPE deklaráció követ. MathML-nél kétféle típusdefiníciót különböztethetünk meg: MathML 1.01 esetén: <!DOCTYPE math SYSTEM " MathML 2.0 esetén: <!DOCTYPE math PUBLIC "-//W3C//DTD MathML 2.0//EN" " Tételünk forrása a 2.0-s jelölésrendszer szabályainak felel meg, melyet akár logóval is jelezhetünk: A W3C MathML 2.0 érvényességet jelző logó A deklarációt követően a <math> gyökérelemet találjuk, ami esetünkben olyan szerepet tölt be, mint XHTMLnél a <html> jelölőelem, vagyis minden képlethez tartozó információ itt található. A dokumentum gyökérelemének xmlns attribútumában ebben az esetben is jelölni kell a névteret ez az értékként megadott címen 13 található meg: <math xmlns=" 13 MathML Namespace. [Elektronikus dokumentum.] URL: A letöltés időpontja

114 Az XHTML Végezetül, ha fájlba akarjuk menteni a forráskódot, akkor ügyeljünk arra, hogy annak kiterjesztése *.mml legyen, hiszen egyes böngészők Mozilla, Mozilla Firefox, Amaya 14 képesek megjeleníteni XHTML-be ágyazás nélkül is a MathML forrást: A mathml.mml állomány Pithagorasz-tételének megjelenítése Firefox ban Számunkra azonban nem a képletek külön állományokban való tárolása érdekes, mivel szövegfeldolgozás során a művet tartalmazó XML fájlnak kell hordoznia a matematikai jelölést, hogy aztán az XHTML-be való konverziót követően annak forrásában is szerepelhessen. Következésképp nézzük meg, miként lehet XHTML-be ágyazni a MathML forrást: <!-- XHTML + MathML --> <?xml version="1.0" encoding="iso "?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" " <html xmlns=" <head> <title>mathml kód XHTML-ben</title> <meta http-equiv="content-type" content="text/html; charset=iso " /> <meta http-equiv="content-style-type" content="text/css" /> <style type="text/css"></style> </head> <body> <math xmlns=" <mrow> <msup> <mi>a</mi> <mn>2</mn> </msup> <mo>+</mo> <msup> <mi>b</mi> <mn>2</mn> </msup> <mo>=</mo> <msup> <mi>c</mi> <mn>2</mn> </msup> </mrow> </math> </body> </html> Példánk egy számunkra eddig ismeretlen típusdefiníciót használ, melyben egyszerre hívjuk meg az XHTML 1.1-es és a MathML 2.0-s DTD-jét: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" " 14 Az Amaya a W3C tesztböngészője, amely szerkesztésre és böngészésre egyaránt használható. Amaya Home Page. [Honlap.] URL: A letöltés időpontja

115 Az XHTML Ezt követően pedig már egy hagyományos XHTML oldalszerkezettel találjuk szembe magunkat, melynek <body> törzsében a bemutatott módon bárhol elhelyezhetők a matematikai képletek. Forráskódunkat fájlba mentve mathml.xhtml és néhány összetettebb jelöléssel kiegészítve a következő végeredményt kapjuk: [Megj.: Fontosnak tartjuk megemlíteni, hogy az alábbi ábrán láthatóhoz hasonló bonyolult szerkezetű és speciális karaktereket tartalmazó képletek megjelenítéséhez szükség lehet matematikai True Type fontok 15 letöltésére, illetve telepítésére is.] A mathml.xhtml állomány képletei Firefox ban A képernyőképen rendkívül jól látszik a MathML ama tulajdonsága, miszerint a benne kódolt karakterek teljes mértékben szövegesen jelennek meg. Ezt támasztja alá, hogy az összeadásjelre keresve annak minden előfordulását megkapjuk kiemelve. Egy másik hasznos dolog az egyes képletek bármely részének, vagy egészének forrás-megjelenítési lehetősége lásd a szumma jelet és a hozzá tartozó jelölőelemeket. Felhívjuk a figyelmet, hogy amennyiben nem *.xhtml, hanem a hagyományos *.html kierjesztést kap a MathML forrást tartalmazó XHTML állomány, akkor sem a Firefox, sem pedig az Internet Explorer nem képes megjeleníteni rendesen a benne lévő képleteket. Ráadásul az IE *.xhtml kiterjesztés esetén sem boldogul a megjelenítéssel, így tehát hiába az ajánlások ahogy azt már a Matematikai vagy más képletek c. alfejezetben is említettük, a böngészőgyártók és termékeik korlátaiba ütközünk. Az alábbiakban a mathml.xhtml állományt átneveztük mathml.html-re és a következő végeredményt kaptuk: A mathml.html állomány képletei Firefox ban A látottak után nem marad más választás, mint kis méretű GIF, JPEG vagy PNG állományok formájában rögzíteni az említett képleteket, majd azokat ebben az esetben már képként meghivatkozni az SGML/XML állományokban. Ismételten hangsúlyozzuk, hogy a képként megjelenített képletekhez szöveges leírásnak is tartoznia kell, illetve a jövőre gondolva nem árt a MathML verziót is rögzíteni mégha ezt jelenleg ki is kell kommenteznünk a könyvet tartalmazó tárolási formátumban. 15 Fonts for MathML-enabled Mozilla. [Honlap.] URL: A letöltés időpontja

116 Az XHTML 5.2. MathML és SVG DTD, illetve névtér Szép- és szakirodalmi szövegekben egyaránt előfordulhatnak olyan vonalas ábrák, alakzatok, grafikonok, képek, szövegek stb., melyeket nemcsak a hagyományos pixelgrafikus, hanem vektorgarafikus formában is tárolhatunk, illetve megjeleníthetünk erre szolgál a W3C SVG 16 formátuma. A MathML-hez hasonlóan az SVG is XML alapú, tehát vezérlési utasítással kezdődik, majd DOCTYPE deklarációval folytatódik. Skálázható vektorgrafikánál négyféle típusdefiníciót különböztethetünk meg: SVG 1.0 esetén: <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" " SVG 1.1 esetén: <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" " SVG 1.1 Basic esetén: <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1 Basic//EN" " SVG 1.1 Tiny esetén: <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1 Tiny//EN" " A DTD meghatározását követően az összes többi XML alapú nyelvhez hasonlóan itt is a gyökérelemmel folytatódik a forrás. Az <svg> gyökér width és height attribútumában adhatjuk meg a vektorgrafikus kép szélességét és magasságát, a viewbox tulajdonság pedig a doboz koordinátáit tartalmazza. Végezetül ugyanitt kap helyet a nyelv névterének rögzítésére szolgáló xmlns jellemző is: <svg width="12cm" height="4cm" viewbox=" " xmlns=" 16 SVG Scalable Vector Graphics (Skálázható Vektorgrafika) W3C ajánlás, melynek segítségével vektorgrafikus képek készíthetők. Az SVG a vonalak, görbék kirajzolásához, valamint a szöveg elhelyezéséhez az XML szintaktikáját használja fel. Scalable Vector Graphics (SVG) 1.1 Specification. [Elektronikus dokumentum.] URL: A letöltés időpontja

117 Az XHTML A MathML nyelvhez hasonlóan skálázható vektorgrafikát is tárolhatunk külön állományokan ezek kiterjesztése mindig *.svg formát kell, hogy öltsön. A *.svg kiterjesztésű fájlokat a böngészőprogramok kizárólag valamilyen SVG viewer plugin telepítését követően képesek XHTML-be ágyazással, vagy anélkül megjeleníteni IE esetében leggyakrabban az Adobe SVG Viewer-t 17 szokás installálni. A következőkben tekintsük meg egy olyan önálló SVG állomány forrását, amely az 1.1-es ajánlás szerint íródott: <!-- SVG --> <?xml version="1.0" encoding="utf-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" " <svg version="1.1" xmlns= width="12cm" height="4cm" viewbox=" "> <desc>téglalap éles sarkokkal</desc> <rect x="1" y="1" width="1198" height="398" fill="none" stroke="blue" stroke-width="2"/> <rect x="400" y="100" width="400" height="200" fill="yellow" stroke="navy" stroke-width="10"/> <text x="505" y="210" font-family="helvetica" font-size="30" fill="blue">cziráki Virág</text> </svg> A forrás láttán egyetlen fontos dolgot emelnénk ki, ami nem más, minthogy a magyar ékezetes karaktereket decimális vagy hexadecimális megfelelőjükkel kell kódolni a tökéletes megjelenés érdekében. Példánk jelölését svg.svg néven fájlba mentve, majd ezúttal Explorerben megjelenítve az alábbi végeredményt kapjuk: Az svg.svg állomány Internet Explorer 6.0-ban A képen jól látszik, hogy a szöveges tartalom a hagyományos képekkel ellentétben itt kijelölhető, ennél fogva kereshető, sőt mindenfajta minőségromlás nélkül többszörösére nagyítható ad abszurdum kicsinyíthető. 18 Ezek az érvek tehát mindenképp az SVG mellett szólnak. Amennyiben az XML alapú vektorgafikus SVG forrást külön állományban tároljuk, az XHTML forráskódban az <object> segítségével hivatkozhatunk rá: <!-- XHTML --> <object type="image/svg+xml" name="svgimage" height="4cm" width="12cm" data="svg.svg"> </object> 17 Web Center Features SVG Manual Download. [Honlap.] URL: A letöltés időpontja Az SVG kép zoom funkciójának elérésére akkor nyílik lehetőség, ha a telepített plugin támogatja az említett funkciót. Ilyen lehetőséget például a legnépszerűbb Adobe SVG Viewer plugin biztosít számunkra. 107

118 Az XHTML A HTML-t ismerőkben felvetődhet a kérdés, hogy képhivatkozáshoz miért nem a jó öreg <img> elemet használjuk? Nos azért, mert az <object> felváltja és kiterjeszti az <img> jelölőt. Ahogy a neve is sugallja, bármilyen objektumot hang, videoklip stb. jelölhet, melyek közül a kép csak egyetlen kategória. Az elem type attribútumában a hivatkozott egyed MIME 19 adattípusa, a data jellemzőben pedig a betöltendő adat URL-hivatkozása szerepel. Ahogy a képeknek, úgy az objektumoknak is megadhatjuk az elfoglalható területét, mégpedig a height és a width tulajdonságokkal. Az <object> még számos hasznos jellemzővel rendelkezik, ám ezek ismertetésétől eltekintünk, mert példánkhoz sem volt rájuk szükség. [Megj.: Említést érdemel, hogy az <object> elem közrezárhat egyéb elemeket, így az azt meg nem értő böngészők a beágyazott elemet ami lehet akár <img> is dolgozzák föl. Ha tehát kétségünk van, hogy a browser meg tud-e bírkózni egy bizonyos objektumtípussal (pl. SVG), megtehetjük, hogy egy általánosabb objektumot (pl. PNG) egy speciálisabb objektumba ágyazunk. Ilyenkor az első feldolgozható objektumot veszi figyelembe a szoftver, a többit pedig figyelmen kívül hagyja.] Abban az esetben, ha az SVG forrást közvetlenül az XHTML-be akarjuk ágyazni valahogy úgy, ahogy azt a MathML esetében is tettük, akkor az érvényesség érdekében egy új típusdefinícióval kell megismerkednünk. Ez az utasítás nem más, mint az XHTML 1.1, a MathML 2.0 és az SVG 1.1 közös DTD-jére való hivatkozás: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN" " Az alábbiakban bemutatunk egy olyan érvényes XHTML 1.1 állományt, amely az előbbi típusdefiníciót használja, ráadásul megjelenik benne mindhárom nyelv névtere és jelölésrendszere: <!-- XHTML + MathML + SVG --> <?xml version="1.0" encoding="iso "?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN" " <html xmlns=" <head> <title>mathml és SVG kód XHTML-ben</title> <meta http-equiv="content-type" content="text/html; charset=iso " /> <meta http-equiv="content-style-type" content="text/css" /> <style type="text/css"></style> </head> <body> <math xmlns=" <mrow> <msup> <mi>a</mi> <mn>2</mn> </msup> <mo>+</mo> <msup> <mi>b</mi> <mn>2</mn> </msup> <mo>=</mo> <msup> <mi>c</mi> <mn>2</mn> </msup> </mrow> </math> 19 MIME Multi-purpose Independent Mail Extensions (többcélú független levelezési kiegészítések) Kevert médiatartalmú elektronikus levelek és HTTP üzenetek formáját leíró szabvány. Az XHTML is követi a MIME formátumot, amelyet a fejléc sora httpequiv="content-type" content="text/html; jelez. A MIME a weben gyakorlatilag arra használható, hogy a fájl tartalmának típusáról lehessen információkat küldeni. 108

119 Az XHTML <svg:svg version="1.1" xmlns:svg=" width="12cm" height="4cm" viewbox=" "> <svg:desc>téglalap éles sarkokkal</svg:desc> <svg:rect x="1" y="1" width="1198" height="395" fill="none" stroke="blue" stroke-width="2"/> <svg:rect x="400" y="100" width="400" height="200" fill="yellow" stroke="navy" stroke-width="10"/> <svg:text x="505" y="210" font-family="helvetica" font-size="30" fill="blue">cziráki Virág</svg:text> </svg:svg> </body> </html> Vélhetően mindenki észrevette, hogy az SVG jelölőelemek előtt mindenhol megjelenik az svg: prefix. Erre azért van szükség, mert az XHTML a host, vagyis a fő nyelv és csak így érhető el a dokumentum érvényessége. Abban az esetben, ha pl. az SVG-t szerepeltetjük hostként, akkor a validitás elérése érdekében ugyanígy használnunk kell az xhtml: és a math: előtagot is. Példánk forrását mathmlsvg.html elnevezéssel fájlba mentve, majd IE-ben megnyitva sajnálatos módon azt tapasztaljuk, hogy nem jelenik meg az SVG kép, maximum annak szöveges tartalma: XHTML-be ágyazott MathML és SVG forrás hibás megjelenése IE 6.0-ban A látottak után következtetésként levonhatjuk, hogy napjaink leggyakrabban használt böngészőprogramja adott esetben az Explorer nem képes megjeleníteni a beágyazott skálázható vektorgrafikát. Ahhoz tehát, hogy egy SVG forrású kép helyesen jelenjen meg Explorer alatt XHTML-ben, külön *.svg állományban kell tárolnunk annak forrását, majd ezt követően <object> elemben meghívva elérhetjük a kívánt eredményt. Ez persze nem jelenti azt, hogy nincs olyan böngésző, amely ne bírkózna meg a beágyazott matematikai képletekkel illetve skálázható vektorgrafikával. Ha az előbbi forráskódot elmentjük ezúttal mathmlsvg.xhtml néven, majd megnyitjuk Mozilla, Mozilla Firefox, vagy netán az új 1.8-as Gecko motor jelenlegi béta 3-as verzióját használó Deer Park Alpha ben, szembetűnő a különbség. Mi ezúttal a Deer Park-ot hívtuk segítségül, de hangsúlyozzuk, hogy Mozilla és Firefox esetén is ugyanezt a végeredményt kapjuk, miután az SVG megjelenítéshez szükséges gdiplus.dll 21 álományt letöltöttük és bemásoltuk a telepített program gyökér könyvtárába a többi *.dll állományhoz. Íme a végeredmény: 20 A Deer Park Alpha 2 az új generációs Firefox fejlesztési verziója, amely támogatja a natív SVG-t is. Ez a böngésző, a várhatóan szeptemberében megjelenő Firefox 1.5 alapja. Deer Park Alpha 2 Start Page. [Honlap.] URL: A letöltés időpontja Building Mozilla with SVG Support. [Honlap.] URL: A letöltés időpontja

120 Az XHTML XHTML-be ágyazott MathML és SVG forrás helyes megjelenése a Deer Park Alpha ban Jól látszik tehát, hogy XML alapú szövegfeldolgozás során óvatosan, körültekintően kell bánnunk a matematikai képletekkel és a skálázható vektorgrafikával, ellenkező esetben ugyanis sok kellemetlenséget okozhatunk önnön magunknak, intézményünknek és nem utolsó sorban azoknak az olvasóknak, akik használni szeretnék elektronikus állományunkat. 6. Validitás-vizsgálat A digitális gyűjtemények kialakítása alapos tervezést igényel, s ez alól nem képez kivételt a megjelenítés sem. Ha XHTML formátumban szeretnénk szolgáltatni feldolgozott szövegeinket, akkor elsősorban annak a célnak kell szemünk előtt lebegni, hogy a kész oldalak minden vagy a webstatisztikák alapján leggyakrabban használtnak minősített böngészőben ugyanúgy működjenek. Ahhoz, hogy az említett kívánalom teljesülhessen, már a transzformációt végző XSLT stíluslap készítésekor tanulmányozni kell a W3C vonatkozó XHTML és CSS ajánlásait. Erre azért van szükség, mert nagy a valószínűsége, hogy intelligens stíluslapunk programozása során elkövetünk olyan hibákat pl. elemek, attribútumok hibás egymásba ágyazása, amelyek ütköznek a nyelv DTD-jében definiált szabályokkal. Mindez, pedig azt eredményezi, hogy az XSLT-vel, SGML/XML formátumokból való XHTML konverzió outputja, vagyis a szöveget tartalmazó állomány kódja érvénytelen lesz. Megoldásért ilyenkor kell ismét ellátogatni a W3C weboldalára XHTML ellenőrzők Az XSLT sablonokban elkövetett XHTML kódok hibáinak felderítése nehézkes és időigényes munka, hiszen az ilyen fájlok vegyesen tartalmaznak XSLT, XHTML és CSS forrást. Ezért a hibakeresést érdemesebb a kimeneti állományok érvényességének automatikus vizsgálatával elkezdeni, majd az ott kapott információk alapján visszamenőleg már könnyedén elvégezhetjük az XSLT szükséges módosításait is W3C HTML Validator A legismertebb olyan program, amely elvégzi helyettünk a forráskód ellenőrzést, a W3C HTML kiértékelője. 22 A vizsgálat többféle módon elvégezhető a program segítségével: Az ellenőrizendő dokumentum URL-címének megadásával. Az ellenőrizendő dokumentum gépünkről való feltöltésével. A forráskód közvetlen bemásolásával. (Csak az új v0.7.0-ás verzióban érhető el.) Bármelyik megoldást választjuk, a kiértékelő a választott dokumentum típusának megfelelően a hibák egy listájával tér vissza. Ha a dokumentum hibamentes, a This page is Valid! (Ez az oldal érvényes!) üzenetet 22 The W3C Markup Validation Service. [Honlap.] URL: A letöltés időpontja

121 Az XHTML kapjuk és egy kódrészletet, melyet elhelyezhetünk állományunkban, feltüntetve ezzel a W3C adott ajánlásának való megfelelés logóját: 23 Az érvényes oldalakra helyezhető HTML és XHTML logók A kiértékelő működéséről elegendő annyit tudni, hogy egy olyan formot tartalmaz, melybe beírhatjuk oldalunk URL-jét, vagy amelyen keresztül feltölthetjük állományunkat, netán forráskódunkat. A program mindkét lehetőség esetében az általunk fájlban megadott DTD szabályrendszerét veszi az ellenőrzés alapjául. Amennyiben a DOCTYPE részben nem adtuk meg a nyelv verzióját, úgy ezt a form által felkínált lehetőségek használatával lehet pótolni. Checkbox-ok segítségével itt állíthatjuk be azt is, hogy milyen részletes legyen az érvénytelen oldal esetén generált hibalista. A programot elegendő úgy beállítani, hogy megadja a sor számát, ahol a hiba feltűnt, így segítve a dokumentum hibáinak felderítésében. A kiértékelő az állományt sorról sorra ellenőrzi, az első sortól kezdve. Ez azt jelenti, hogy a dokumentum elején levő hiba az oldalon több hibát is eredményezhet, tehát kifejezetten jó módszer a hibák javítására, ha először az első kijelzett hibát korrigáljuk, majd újra kiértékeltetjük a dokumentumot. Gyakran előfordul, hogy egy probléma javítása a dokumentum elején néhány más hibát is megszüntet. Ezt addig kell folytatni, amíg az összes hibát ki nem javítottuk és az eredményül kapott dokumentum érvényes nem lesz. A W3C ellenőrző programja napról napra fejlődik a legutóbbi stabil verzió (v0.7.0) augusztus 8-án vált elérhetővé, bárki részt vehet fejlesztésében és letöltheti forráskódját. 24 Komplexitását mutatja, hogy az eszköz nemcsak HTML és XHTML, hanem pl. MathML, SVG stb. forrás ellenőrzésére is alkalmas. Az alábbi ábra a program legújabb verziójának weben elérhető kezelőfelületét szemlélteti: A W3C HTML kiértékelő v0.7.0-es változat felületének részlete A Konzorcium oldalán elérhető programon kívül még néhány ismert kiértékelő létezik, melyek meglehetősen összetett elemzésre alkalmasak: WDG HTML Validator ( Doctor HTML ( CSE HTML Validator Online Check ( W3C Link Checker 23 W3C Logo and Icon Usage. [Elektronikus dokumentum.] URL: A letöltés időpontja Source Code Availability for The W3C Markup Validation Service. [Elektronikus dokumentum.] URL: A letöltés időpontja

122 Az XHTML A honlapokon szereplő linkek és ugrópontok ellenőrzésére hasznos és egyszerű eszköz a W3C Link Checker 25, melynek csak meg kell adni az ellenőrizni kívánt honlap vagy weboldal URL címét, el kell végezni néhány egyszerű beállítást és nincs más hátra, mint megvárni a vizsgálat eredményét HTML Tidy XHTML állományaink ellenőrzéséhez meg kell említenünk egy olyan eszközt, mely mellett nem mehetünk el szó nélkül. Ha az elkészült kódunk rendetlen, vagy sok hibát tartalmaz, akkor jelenthet megoldást a HTML Tidy, vagy ha úgy jobban tetszik: a HTML Pucoló. 26 Ez nem más, mint egy letölthető alkalmazás, melyet eredetileg Dave RAGETT fejlesztett ki. A Tidy nem egy szerkesztőeszköz pusztán dolgunk megkönnyítésére használható, magyarul segít érvényessé tenni oldalainkat. Annyival praktikusabb, mint a W3C HTML kiértékelője, hogy míg ez utóbbi kizárólag a hibák pontos helyét mutatja meg, illetve bizonyos esetekben magyarázó szöveggel segíti a javítást, addig a Tidy bizonyos szintű automatikus javításra képes. 27 Amennyiben az alkalmazás hibátlannak minősíti az oldalt, úgy ezt egy kis logóval is jelezhetjük. A fejlesztés ennél a szoftvernél is önkéntes alapon együttműködve zajlik, így mára számos programozási nyelven és platformra elkészült a program. Sőt a dokumentáció, a forráskód, a licensz, a támogatás stb. is elérhetők a Sourceforge oldalán. Ha kódunk zavarosnak tűnik, érdemes kipróbálni, hiszen a Tidy sokkal türelmesebb és pontosabb, mint egy ember, s így csodákra képes. [Megj.: A HTML Tidy-t elsősorban honlapok készítésekor érdemes alkalmazni. Szép- és szakirodalmi művek XHTML verziójának vizsgálatára leginkább a transzformációs stíluslap sablonjainak programozása során használjuk, mivel a tesztelési időszakban hasznos lehet meggyőződni arról, hogy az XSLT által előállított XHTML kimenet mennyire tiszta és hibátlan.] 6.2. WAI tippek akadálymentesítés A W3C munkáját egyszerre több fejlesztési területen végzi. Szükséges tehát, hogy digitális gyűjteményünk szolgáltatandó XHTML kimenetének tervezésekor ne csak a szóban forgó nyelv ajánlását és az ellenőrző programokat használjuk, hanem vegyük figyelembe a WAI (Web Accessibility Initiative) 28 irányelveit is. Ez a terület felel azokért a szabványokért, amelyek segítenek pl. a hátrányos helyzetűeknek, testi-szellemi fogyatékosoknak a web használatában. [Megj.: A mobil technológia előretörésével új szemlélet alakult ki a WAI csoportban: a bárhol, bármikor szemlélete, ugyanis cél a bármely böngészőben való megtekinthetőség viewable with any browser elérése.] Az elérhetőség elvének az a lényege, hogy a website-hoz hozzárendel egy bizonyos megfelelési szintet, annak mértékében, hogy az elősegíti-e a kiegészítő elérhetőségi technológiák használatát. 29 Az egyes szinteknek való megfelelőséget ebben az esetben a W3C WAI WCAG logókkal lehet jelezni: A megfelelőségi szintet jelző WAI logók A megfelelőségi szint alatt azt a fokot értjük, amely megmutatja az egyes képi felhasználói felületekhez pl. képek, grafikonok, hivatkozások, táblázatok, oldalszerkezet stb. rendelt szöveges megfeleltetések arányát. A WAI-A szintű oldalak elkészítése egy, az előbbi szövegegységeket is magába foglaló kb pontból álló ellenőrzőlistának való megfeleltetést jelent, tehát viszonylag egyszerűen kivitelezhető akadálymentesítés esetén ez a kötelező szint. WAI-AA oldalak már jóval nehezebben hozhatók létre, a tripla A-nak való megfelelés pedig rendkívül bonyolult, nem is mindig kivitelezhető. Értelemszerűen a WAI tippjei elsősorban weboldalak tervezésekor használatosak, ám bizonyos irányelvek alkalmazásától a publikus XHTML gyűjteményformátum kialakításakor sem tekinthetünk el. Már csak azért 25 W3C Link Checker. [Honlap.] URL: A letöltés időpontja HTML Tidy Project Page. [Honlap.] URL: A letöltés időpontja Clean up your Web pages with HTML TIDY. [Elektronikus dokumentum.] URL: A letöltés időpontja Web Accessibility Initiative (WAI). [Honlap.] URL: A letöltés időpontja Kézikönyv a minőségi elvekről (ford.: BÁRÁNY Barbara). Bp.: OSZK MEK, [Elektronikus dokumentum.] URL: A letöltés időpontja:

123 Az XHTML sem, mert szövegeink tartalmazhatnak képeket, oldalszerkezetre vonatkozó formázási utasításokat, táblázatokat, hivatkozásokat számos olyan dolgot, amelyek használatát az ajánlás szabályozza. Szerencsére léteznek olyan eszközök, amelyek automatikusan elvégzik a megfelelőségi vizsgálatot, így nem kell tételesen végignéznünk az ellenőrző listákat. 30 Ezeket a szoftvereket, melyek felsorolása megtalálható a W3C honlapján 31, minden kulturális intézménynek célszerű használnia. A példák között említhető a Watchfire Corporation, Bobby 32 nevet viselő teszt eszköze, mely a WAI irányelvek szerint ellenőrzi a weboldalakat. A program az 5.0-s verziótól sajnos már nem ingyenes, helyette viszont egyszerű oldalakhoz alkalmazható a Watchfire WebXACT 33 is. [Megj.: Az automatizált eszközök önmagukban nem elegendőek arra, hogy kimutassák egy lap elérhetőségét. Az akadálymentesség vizsgálatához szükség lehet a kézi módszerek alkalmazásával történő rendszeres tesztelési folyamatra is. Ha mód van rá, lehetőleg fogyatékos emberekkel teszteljünk, hiszen a website-nak minden szempontból statikus elemek, kapcsolódó szabványok, formák, képletek, esetleges interaktív elemek stb. biztosítania kell a teljes hozzáférhetőséget.] Összességében tehát kijelenthetjük, hogy amennyiben munkánk során betartjuk a fejezetben leírtakat, már nagy lépést tettünk leendő vagy épülő digitális gyűjteményünk XHTML formátumú megjelenésének szabványossága érdekében. Ez pedig rendkívül fontos, hiszen egyre erőteljesebb a törekvés az elérhetőség kötelezővé tételére, ami leginkább a W3C WAI irányelvekkel való megfelelésben ölt testet mint nemzeti vagy állami támogatással működő website-ok specifikációjának része. Így tehát az elérhetőség elve a belátható jövőben bizonyára kötelező lesz a legtöbb EU-tagállamban. 30 Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0. [Elektronikus dokumentum.] URL: WEBCONTENT/full-checklist.html. A letöltés időpontja Evaluation, Repair, and Transformation Tools for Web Content Accessibility. [Elektronikus dokumentum.] URL: A letöltés időpontja Bobby Web Accessibility Testing. [Elektronikus dokumentum.] URL: A letöltés időpontja Watchfire WebXACT. [Honlap.] URL: A letöltés időpontja:

124 9. fejezet - Lépcsős stíluslapok CSS Az egyre szélesebb körben elterjedő CSS stíluslapnyelv népszerű XHTML, illetve XML formázási lehetőség. Ez a fejezet elsősorban a CSS 1.0-s ajánlásával foglalkozik 1, hiszen szövegfeldolgozás során a megjelenítéshez leginkább ennek az utasítasításkészletét kell igénybe venni, ráadásul a böngészők is mind a mai napig ezt támogatják kifogástalanul. Ugyanakkor tisztában kell lennünk azzal, hogy a lépcsős stíluslapokról nem lehet kimondottan a hagyományos módon, egymásra épülő fejezetek alapján komoly ismereteket szerezni. Ismeretszerzésre sokkal inkább használhatók az olyan források, amelyek példákon keresztül magyarázzák a beállítási lehetőségeket vagyis érdemes rögtön fejest ugrani a téma közepébe, így tehát mi is ezt tesszük. 1. A CSS rövid története Bár a CSS c. alfejezetben érintőlegesen már szó esett róla, fontosnak tartjuk, hogy más aspektusból is röviden szóljunk a nyelvről. Az első böngészők még maguk döntöttek arról, hogyan jelenítsék meg az oldalakat. Kezdetben az egyes szoftverek egyéni stílusnyelvet használtak, de a böngészők következő generációi egyre kevesebb lehetőséget biztosítottak az oldalak külalakjának befolyásolására. Az első grafikus böngésző, az 1993-ban megjelent NCSA Mosaic amely széles körben elterjedt, és a web népszerűségéért is sokat tett a megjelenítés területén elődeihez képest visszalépésnek bizonyult, ugyanis csak bizonyos szín- és betűtulajdonságok megváltoztatását tette lehetővé. Ez a tendencia természetesen egyaránt zavarta a lapok szerzőit és felhasználóit is, akik gyakran elégedetlenségüknek adtak hangot. Ez volt az a pillanat, amikor Håkon Wium LIE elhatározta, hogy készít egy stíluslapnyelvet a web számára, amely a CSS nevet fogja viselni, és amelynek első vázlatát akkor még csak a HTML nyelvhez kidolgozva 1994-ben mutatta be. Ezt követően csatlakozott hozzá Bert BOS, aki akkoriban egy stíluslapokkal is rendelkező böngésző kifejlesztésén dolgozott. Egyesítették erőiket, és nekiláttak egy olyan stílusnyelv kidolgozásának, amely a HTML mellett más leíró nyelvekhez is használható. Sikerüket attól remélték az egyes böngészők saját stílusnyelveivel, illetve az SGML-hez kidolgozott DSSSL nyelvvel szemben, hogy a CSS képes volt a szerzők és a felhasználók igényeit egyaránt figyelembe venni, és szükség esetén azokat kombinálni, egymásba ágyazni. A CSS megjelenését a HTML fejlesztői örömmel fogadták, mert meglátták benne a HTML-ből hiányzó speciális lehetőségeket. A szakmát azonban megosztotta a bejelentés, sokan kételkedtek a nyelv hatékonyságában ben azonban létrejött a W3C, és a CSS fejlesztése ennek keretei között, külön munkacsoport megalapításával folytatódott. Ebben az évben a Microsoft is jelezte, hogy következő böngészője, az Internet Explorer 3.0 támogatni fogja a CSS használatát. Mivel a nagy ellenfél, a Netscape sem akart lemaradni, így a Navigator 4.0 verziójába szintén bekerült a CSS támogatása. Ez a Netscape filozófiájában is változást jelentett, hiszen ők eredetileg nem értettek egyet a stíluslapok használatával. 2 Így született tehát a CSS, az a lépcsős stíluslap-megvalósítás, amely lehetővé teszi, hogy a HTML, XHTML és XML állományok szerzői oldalaihoz egyedi stílust rendelhessünk hozzá. A lépcsős stíluslapoknak jelenleg két érvényben lévő kiadása létezik. Az első kiadás CSS december 17-én, annak felülvizsgált verziója pedig január 11-én jelent meg. A CSS május 12-én vált ajánlássá, jelenleg ennek felülvizsgált, 2.1-es 5 verziója munkapéldány, sőt már a 3.0-s kiadáson is elkezdtek dolgozni a szakemberek. A lépcsős stíluslapok használata egyre népszerűbb a webfejlesztők körében, a technológiát TV- és mobileszközök használatához is folyamatosan fejlesztik. 6 Sokakban felvetődhet a kérdés, hogy miért jobb a CSS, mint a formázáshoz használatos HTML/XHTML elemek és azok attribútumai? Hiszen ha azokat is ajánlások szerint használjuk, elvileg nem lehet gond az egyes 1 Mindez persze nem jelenti azt, hogy a CSS 2-es ajánlásából ne említenénk meg néhány hasznos utasítást. 2 RIMÁR Miklós: Honlapok formázási lehetőségeinek bővítése a CSS nyelv segítségével. Konzulens: SÁNDOR Ákos. [Szakdolgozat.] Szeged: Szegedi Tudományegyetem p URL: A letöltés időpontja Cascading Style Sheets referencia. [Elektronikus dokumentum.] URL: A letöltés időpontja Cascading Style Sheets 2 specifikáció. [Elektronikus dokumentum.] URL: A letöltés időpontja Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification. [Elektronikus dokumentum.] URL: A letöltés időpontja Cascading Style Sheets. [Honlap.] URL: A letöltés időpontja

125 Lépcsős stíluslapok CSS böngészőkben való megjelenéssel Ez igaz, ám a CSS-t éppen a HTML formázási elemkészletének gyengesége és hordozhatatlansága miatt fejlesztették ki. [Megj.: Gyengeség alatt azt értjük, hogy a HTML kevés formázási utasítással rendelkezett, ráadásul, mivel ezek magában a HTML állományban fordultak elő más oldalaknál nem lehetett felhasználni őket, tehát nem voltak hordozhatók.] Használatával elérhetővé válik számunkra a folyamatos stíluslap HTML/XHTML lap kapcsolat. Az állományok szerzői az általuk kedvelt stílust egyszer rögzítik, és hozzákapcsolhatják minden általuk készített HTML/XHTML laphoz, ezáltal megvalósítva a hordozhatóságot. A stíluslapok alkalmazásának még egy nagy előnye van. Használatukkal hatékonyabbá, gyorsabbá és rugalmasabbá tehetjük a webszerkesztést, elfelejthetjük a frame-eket, a lassan töltődő táblázatokat, a korlátozott formázási lehetőségeket stb., segítségükkel átláthatóbbá tehetjük forráskódjainkat. 2. CSS szintaktika A W3C HTML 4.0 specifikációja határozza meg a stíluslap és a dokumentum kapcsolódási lehetőségeit, ugyanis történeti okokból ettől kezdve használható CSS a HTML nyelvhez. A következő forráskód a kapcsolódás négy lehetséges módját mutatja be XHTML esetében: <!-- XHTML + CSS --> <?xml version="1.0" encoding="iso "?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " <html xmlns=" xml:lang="hu" lang="hu"> <head> <title>9. Lépcsős stíluslapok CSS </title> <meta http-equiv="content-type" content="text/html; charset=iso " /> <meta http-equiv="content-style-type" content="text/css" /> <link rel="stylesheet" title="neumann design" type="text/css" href="neuweb.css" media="screen" /> <style url( <!-- h1 {color: black;} --> </style> </head> <body> <h1>9. Lépcsős stíluslapok CSS</h1> <hr /> <p style="font-size: 12pt">Az egyre szélesebb körben elterjedő CSS...</p> </body> </html> A sablonban látható első csatolási lehetőség a <link> elem használata, méghozzá külső stíluslap pl. neuweb.css behívására. Második lehetőségként a dokumentum <head> szekciójában elhelyezett <style> jelölő alkalmazható itt közvetlenül definiálhatók a használni kívánt stílusok, illetve kulcsszóval külső stíluslap is importálható. Az utolsóként bemutatott lehetőség pedig valamely HTML/XHTML elem style 7 attribútumának használata, a dokumentum <body> szekciójában. [Megj.: A böngészők általában figyelmen kívül hagyják az általuk ismeretlen elemeket. A régebbi browser-ek például jó esetben egyszerűen elmennek a <style> elem mellett. Kellemetlenebb eredménnyel jár, ha belezavarodnak a tartalmába. Ez megelőzhető, ha a stílusbeállításokat egy standard SGML utasítással a fenti módon <! > elrejtjük előlük.] 7 A style attribútum, mivel helyi adott elemre vonatkozó beállításokat tartalmaz, mindig felülbírálja a <head>-ben elhelyezett belső vagy külső stíluslap utasításait. 115

126 Lépcsős stíluslapok CSS A HTML 4.0-s verziójától felfele lehetőség van arra, hogy egy dokumentumhoz többféle stílusinformációt rendelhessünk attól függően, hogy milyen típusú eszközön fog megjelenni. Ez elsősorban azért hasznos, mert bizonyos tulajdonságok csak meghatározott médiatípus esetén alkalmazhatóak képernyő, nyomtató, televízió stb. Az említett alternatív stíluslapok a <link> elemben adhatók meg, annak többszörözésével. A rel attribútum "stylesheet" vagy "alternate stylesheet" értéket vehet fel, a media tulajdonságban pedig azt lehet megadni, hogy az adott stíluslap milyen eszközre készült: <link rel="stylesheet" title="gold (right, fixed) + navbar" href="../threepart-f.css" media="screen, print, projection, tv" /> <link rel="alternate stylesheet" title="plain (by David Baron)" href=" /> <link rel="stylesheet" title="handheld" href="../handheld.css" media="handheld" /> <link rel="stylesheet" title="handheld" href="../handheld-bw.css" media="only handheld and (monochrome)" /> Mivel egyes böngészők lehetőséget biztosítanak arra, hogy tetszőlegesen kiválaszthassuk a használni kívánt stíluslapot Mozilla alapúak például a View -> Page Style menüpontban, így érdemes kitöltenünk a title jellemzőt is, hiszen az abban megadott érték szövegesen is megjelenik a böngésző megnevezett menüpontjában. Természetesen a browser saját maga is képes eldönteni, hogy számára melyik felkínált stíluslap a megfelelő példaként érdemes megtekinteni a címet IE, majd Firefox alatt és mindenki számára rögtön világossá válik, miről is van szó. [Megj.: A szolgáltatandó XHTML dokumentum fejében is elhelyezhetünk médiafüggő stílusinformációkat, ekkor a <style> elemet kell többször felhasználni!] Ha a CSS-t HTML-lel használjuk, az elemnév nem érzékeny a kis- és nagybetűkre, ezért a body, BODY és Body ugyanazt a HTML <body> elemet azonosítja. Azonban az XHTML-ben és az XML-ben a jelölők nevei érzékenyek a kis- és nagybetűre, tehát a stíluslapneveknek is érzékenyeknek kell lenniük, következésképp a CSS szelektoroknak mindig meg kell egyeznie a jelölésrendszer által felkínált elemnevekkel CSS utasítások felépítése Stíluslappal tervezni nem nehéz, de ahogy ez az eddigi ismertetésből is kiderülhetett, szükséges hozzá a(z) HTML/XHTML alapvető ismerete. Ezt szemlélteti az alábbi utasítássor: h1 {color: gray;} A példa tulajdonképpen a CSS használatának alapszabályait mutatja be. Jól látszik, hogy egy utasítás alapvetően két részből áll: a szelektor tartalmazza a formázandó HTML elem megnevezését ez a mi esetünkben <h1>; a deklaráció végzi el a szelektorban meghatározott elem formázását; Maga a deklaráció is két részre bontható: egy color tulajdonságra és a hozzá tartozó black értékre, melyeket mindig kettőspont ( : ) választ el egymástól ha a szelektort egy tulajdonság és érték követi, akkor nem kötelező a pontosvessző ( ; ) kitétele, minden más esetben igen. A következetesség kedvéért és a hibalehetőségek csökkentése érdekében azonban javasolt mindig kitenni. A szelektor a tulajdonképpeni kapocs a HTML/XHTML mint leírónyelv és a stíluslap között. Így azt mondhatjuk, hogy szinte minden XHTML-elem betöltheti a szelektor szerepét. A szelektor természetesen nemcsak XHTML-elem lehet, hanem bármilyen általunk kitalált beszédes név is. Összefoglalva, egy CSS utasítás szintaxisa a következőképpen néz ki: 116

127 Lépcsős stíluslapok CSS selector {tulajdonság: érték;} 2.2. Csoportképzés A stíluslapok méretének csökkentése érdekében a szelektorok csoportosíthatók, ám kizárólag abban az esetben, ha ugyanazok a tulajdonságok vonatkoznak az egyes szelektorokra. Nézzünk egy példát: h1 {font-family: Verdana;} h2 {font-family: Verdana;} h3 {font-family: Verdana;} A vesszővel (, ) való csoportosítás után a következőt írhatjuk: h1, h2, h3 {font-family: Verdana;} Hasonló módon a tulajdonságok is csoportosíthatók ilyenkor értelemszerűen ugyanahhoz a szelektorhoz különböző tulajdonságok tartoznak: h1 {font-family : Helvetica;} h1 {font-size : 12pt;} h1 {font-style : italic;} A pontosvesszővel ( ; ) elválasztott, egy kapcsos zárójelen ( {} ) belüli csoportosítást követően az alábbi formát kapjuk: h1 {font-family : Helvetica; font-size : 12pt; font-style : italic;} [Megj.: A szelektort követő kapcsos zárójelben ( {} ) lévő tulajdonságok tetszőleges formában elrendezhetők, mindenkinek saját ízlésén és következetességén múlik, hogy a jövőben mennyire lesznek átláthatóak saját stíluslapjai.] Az egy kalap alá tartozó tulajdonságokat eltérő csoportosítási szintaktikával is megadhatjuk. A fontstyle, font-size és font-family tulajdonságok esetében ez a következőképpen néz ki: h1 {font: italic 12pt Helvetica;} Nagyon fontos, hogy ha egy gyermek elemhez nincs külön tulajdonság rendelve, akkor mindig örökli a tartalmazó (container) elem tulajdonságait. Alapértelmezett stílustulajdonság beállításához az alkalmazni kívánt stílust olyan elemhez kell kötni, amely tartalmazza mindazokat az elemeket, amelyekre a stílust vonatkoztatni akarjuk. A HTML dokumentumokban például erre a célra megfelelhet a <body> elem. Ha egy stílusdefiníciót az 117

128 Lépcsős stíluslapok CSS oldal minden elemére alkalmazni akarunk, akkor használhatjuk a csillag ( * ) univerzális szelektort. A * {color: red;} utasítás hatására minden elem color tulajdonsága a red értéket veszi fel, vagyis piros színű lesz CLASS szelektor osztályképzés A HTML elemek stílusbeállítási rugalmasságának növelése érdekében a W3C új attribútumot vett fel a HTMLbe, a class-t (osztály). Ezzel lehetővé tették, hogy ne csak konkrét elemekhez, hanem általunk adott beszédes nevekhez is stílusokat rendeljünk. Pl. a <body> minden eleme osztályba sorolható, az egyes osztályok pedig stíluslapból megcímezhetőek. Az osztályhoz tartozó stílus definiálása mindig ponttal (. ) kezdődik, és ezt követi az általunk adott név. A kívánt formázási stílusbeállítások a HTML/XHTML kód bármelyik elemében a class= tulajdonságnév utasítással hívhatók meg a class szelektor segítségével. Az alábbi forráskód egyszerű példát tartalmaz a class szelektor használatára: <-- XHTML + CSS --> <html> <head> <title>css példa class-ra</title> <style type="text/css"> <!-- body {font-family : Garamond; font-size : 12pt;}.nagybetu {font-size : 20pt;} --> </style> </head> <body> <p class="nagybetu">ez egy 20 pontos bekezdés.</p> <p>ez egy 12 pontos bekezdés a szülő elem miatt.</p> </body> </html> 2.4. ID szelektor A HTML-be bevezették az id attribútumot is, amely lehetővé teszi egyedi azonosítók felvételét a dokumentumba. Ennek a lehetőségnek különleges jelentőséget ad, hogy felhasználható stíluslap szelektorként, és megcímezhető a kettőskereszt ( # ) előtaggal. A következő példa az ID használatát mutatja be: <-- XHTML + CSS --> <html> <head> <title>css példa ID-re.</title> <style type="text/css"> <!-- #ritka {letter-spacing : 4,5px;} h1#ritka {letter-spacing : 5,5px;} --> </style> </head> <body> <p id="ritka">ritka szöveg</p> <h1 id="ritka">ritka címsor</h1> <h1>normál címsor</h1> </body> </html> 118

129 Lépcsős stíluslapok CSS A fenti példa első esetében #ritka a kiválasztott formázást a <p> elemhez feleltettük meg, az id attribútum segítségével. (A letter-spacing a betűk közti távolságot határozza meg). A második esetben kettős feltételt támasztottunk: a formázás akkor lép érvénybe, ha a <h1> elemet a "#ritka" azonosítóval látjuk el, ezért ez már nem vonatkozik a <p> elemre. Sőt, a második <h1> jelölőre sem vonatkozik a ritkított betűköz, hiszen az azonosítók egyediek és csak azon az elemen belül működnek, ahol meghívtuk őket. Összegezve tehát: az osztályokat és azonosítókat az oldal bármely részére alkalmazhatjuk. Az osztály nevét pont (. ) vezeti be, hivatkozni pedig a class attribútummal tudunk rá. Az azonosító kettőskereszt ( # ) jellel kezdődik, meghívni az id attribútummal lehet. Egy osztályt az oldal több elemében is felhasználhatunk, az azonosítók viszont egyediek Összekapcsolt szelektorok Az öröklődés szabályai mentesítik a stíluslap tervezőjét egy csomó fölösleges gépelés alól. A tulajdonságok beállítása során elég egyszer elkészíteni az alapértelmezettet, utána felsorolni a kivételeket. Tegyük fel, hogy a <p> elem színét kékre szeretnénk változtatni. h1 {color: gray;} p {color: blue;} Amikor a stíluslap aktív, minden kiemelt <p> szövegrész, akár a <h1> elemen belül, akár azon kívül található, kékre változik. Abban az esetben, ha csak a <h1>-en belüli <p> elemeket akarjuk kékre színezni, össze kell kapcsolni a szelektorokat, tehát a CSS kódot az alábbiak szerint kell megváltoztatni: h1 p {color: blue;} Összekapcsolt szelektorok használata esetén azok az elemek lesznek megcímezve, amelyek a felsorolásban utoljára állnak. Tehát akár kettőnél több elem is egymásba ágyazható ilyen módon, például az első szintű címsorok bekezdései és félkövér kielemései, illetve a második szintű címsorok félkövérrel és dőlttel jelölt szövegrészei is kékek lesznek: h1 p, h1 b, h2 b, h2 em {color: blue;} 2.6. Pszeudo-osztályok HTML és XHTML nyelvekben a hipertext-hivatkozások stílusa különböző lehet. A linkek esetében a CSS két pszeudo-osztályt vezetett be, ezek a :link és a :visited, melyek azt mutatják számunkra, hogy a hivatkozást nemrég bejártuk vagy sem. Mivel HTML/XHTML-ben a linkek egyaránt href attribútummal rendelkeznek, ebből kifolyólag az alábbi utasítások egyenértékűek: A:link {color : green;} :link {color : green;} A felhasználói tevékenység dinamikus kezelésére, attól függően, hogy a hivatkozás pillanatnyilag kiválasztott vagy sem, felette van-e a kurzor vagy sem és nem utolsó sorban megkapta-e a fókuszt vagy sem, további három látszólagos pszeudo-osztályt különböztethetünk meg. Ezek a :visited, az :active és a :focus. A :visited kulcsszó olyan hipertext-hivatkozást azonosít, amelyet már bejártunk feltételezve, hogy a 119

130 Lépcsős stíluslapok CSS böngésző emlékezik is erre. Az :active kulcsszó a pillanatnyilag kiválasztott hivatkozást azonosítja, a :focus pedig akkor lesz érvényes, amikor az oldal fókusza az elemen van: A:visited {color : blue;} A:active {color : red;} A:focus {background : yellow;} A dinamikus pszeudo-osztályokat előszeretettel szokták alkalmazni a linkek esetében, az azokra vonatkozó látszólagos osztályokkal együtt. A CSS 2.0-s ajánlás és az újabb verziók még számos pszeudo lehetőséget tartalmaznak, de a többi elem esetében biztonsággal nem lehet használni őket, ugyanis elemenként és böngészőnként más-más eredményt kaphatunk Megjegyzések CSS-ben A többi nyelvhez hasonlóan a lépcsős stíluslapok is lehetőséget nyújtanak arra, hogy megjegyzéseket helyezzünk el bennük. A CSS megjegyzések hasonlítanak a C++ és Java programozási nyelvek megjegyzéseihez, tehát a kommentezett részt per csillag ( /* ) és csillag per ( */ ) karakterek közé kell zárni ékezeteket nem használunk. A megjegyzéseket elsősorban olyan összetett stílusbeállítások esetén javasolt alkalmazni, ahol a későbbi könnyebb és gyorsabb eligazodást segítik számunkra. Ilyen például a Neumann-ház honlapján található TEI szövegek számozott listájához tartozó CSS beállítás is: /* Az aloldalak TEI szerinti "szamozott" tipusu listaja. */ ol.yellow li { color : #ffcd58; font : normal normal 11px "Trebuchet MS", Verdana, Geneva, Arial, Helvetica, sansserif; line-height : 14px; list-style-position : outside; list-style-type : decimal; margin-left : 0px; margin-bottom : 5px; margin-top : 0px; } Nagyon fontos, hogy a megjegyzések nem ágyazhatók egymásba, illetve más CSS utasításba! 3. Betűstílus tulajdonságok Amikor XML-ben feldolgozott köteteink megjelenítéséről beszélünk, akkor az egyik legfontosabb dolog a megfelelő betűstílusok alkalmazása. A karaktereknek meghatározott betűkészlettel, adott méretben kell megjelenniük, lehetőség szerint olyan stílustulajdonságokat hordozva, mint a dőlt, a félkövér, az alsóindex, a felsőindex vagy a nagybetű. A következőkben azokat a tulajdonságokat vesszük számba, amelyek alapvetően befolyásolják a szöveg megjelenését, s amelyek használata szinte elkerülhetetlen az XML alapú szövegfeldolgozás során Betűcsaládok és általános családok font-family: a betűtípuscsalád neve, általános betűtípuscsalád; A betűk és szövegek formázásának területén a lépcsős stíluslapok óriási előrelépést biztosítanak a HTML lehetőségeihez képest. Nem véletlen, hogy az XHTML szigorú megfelelésű dokumentumaihoz már kizárólag a CSS-sel való formázást javasolják, hiszen így igényesebb, látványosabb, de egyúttal egyszerűbb, tisztább felépítésű oldalakat tudunk létrehozni. A betűtípusok megadására a font-family tulajdonságban a fontok neve szolgál. A Microsoft és az Apple oprendszerek hasonló TrueType betűtípust használnak, a UNIX alapú rendszerek Type1 és PostScript fontokkal dolgoznak. Ha mindenkinek kedvére akarunk tenni, akkor a webre kerülő output állományainkban TrueType 120

131 Lépcsős stíluslapok CSS betűtípusokat kell szerepeltetni, ugyanakkor biztosítani kell a lehetőséget azoknak is, akik nem ilyen fontokat használnak. Ezt úgy tehetjük meg, hogy sokféle betűtípust felsorolunk a stílusban, bízva abban, hogy valamelyiket csak megjeleníti majd a felhasználó böngészője Egy másik lehetséges módszer, hogy olyan általánosan használt betűtípust állítunk be, melyet az összes rendszeren futó böngésző tud kezelni. 5 ilyen betűtípus létezik: a betűtalpas karaktereket használó serif (Times New Roman); a betűalap nélküli sans-serif (Arial); a dőlt betűs cursive (Zapf-Chancery); a fantáziadús fantasy (Western); a kiegyenlített betűszélességű monospaced (Courier New); Amikor felsoroljuk a használatos betűtípusneveket, akkor a szóközt is tartalmazókat idézőjelek között kell szerepeltetni, pl.: p {font-family : "Trebuchet MS", Verdana, Geneva, Arial, Helvetica, sans-serif;} 3.2. Betűtípus-vastagság font-weight: normal bold bolder lighter ; A stílus a betűtípusok vastagságát és színük intenzitását szabályozza. A "bold" félkövér ("700"), a "normal" normál ("400" ez az alapértelmezés). A "bolder" és "lighter" értékek 100-asával lefelé vagy felfelé igazítják az örökölt értéket. A "100", "200", "300", "400", "500", "600", "700", "800" és "900" abszolút értékek egy arányos skálát határoznak meg, ahol minden érték legalább annyira sötét, mint az előző: p {...; font-weight: bold;} 3.3. Betűstílus font-style: normal italic oblique; Ha szövegünk egy adott részét dőltté szeretnénk tenni, akkor azt a fontstyle tulajdonsággal tehetjük meg. Két értéket vehet fel: ( normal ) normál; ( italic, oblique ) dőlt, döntött; Vegyük észre, hogy a döntött stílus "oblique" nem ugyanaz, mint a dőlt "italic". Míg az előbbi a böngészők által létrehozott mesterséges alak, addig az utóbbi az adott betűkészlethez tartozó karakter dőlt változatának megjelenítéséhez szükséges. span {...; font-style: italic;} 121

132 Lépcsős stíluslapok CSS [Megj.: Amennyiben a megjeleníteni kívánt karakternek nincs dőlt fontja, akkor a böngészők betűtípusonként eltérő módon reagálnak: vagy mindkét értékre az "oblique" változatot hozzák létre, vagy egyszerűen más fonttal jelenítik meg a szöveget.] 3.4. Betűváltozatok font-variant: normal small-caps; A kiskapitális forma egyik jelentős eleme a tipográfiának, és azzal a font-variant tulajdonsággal hozható létre, amely két értéket vehet fel: ( normal ) normál ez az alapértelmezés; ( small-caps ) kiskapitális; Az utóbbi betűváltozatot rendszerint vezeték-, vagy teljes nevek kiemelésére használják, mert esztétikus és méretéből adódóan egyáltalán nem bontja meg a sor képét. A kiskapitális forma tulajdonképpen nem más, mint kisbetűs karakterek méreteivel megegyező nagybetű. span {font-variant: small-caps;} [Megj.: Ha az éppen használatos fontkészletben nem áll rendelkezésre kiskapitális betűváltozat az esetek döntő többségében nem szokott, akkor a böngésző saját maga hozza létre a kívánt formát. A nagybetűket a browser nem alakítja kiskapitálissá.] 3.5. Betűméret font-size: xx-small x-small small medium large x-large xx-large smaller larger hosszérték százalékos érték; A betűk méretét a font-size tulajdonság segítségével állíthatjuk be. A szintaktikát bemutató fenti felsorolásban az első 7 érték abszolút. A szomszédos indexek közötti különbség javasolt értéke 1,5-szörös megjelenítéskor, tehát ha a "medium" 10 pontos méretet jelent, akkor "large" 15 pontos lesz. A különböző médiatípusokhoz különböző méretezési faktorok szükségesek, a fontméret-táblázat az egyes fontcsaládok esetén különbözhet egymástól. 8 A "smaller" és a "larger" relatív értékek, hiszen az öröklődés szabályai alapján a szülő elemhez viszonyított értékre utalnak. A relatív méret a fontméret-táblázat és a szülőelem valós fontmérete közötti arányt veszi figyelembe. Ha a szülőelem fontmérete "medium" volt, a "larger" érték az aktuális elem fontméretének értékét "large"-ra állítja. Ha a szülőelem fontméretét a böngésző fontméret-táblázata nem tartalmazza, a böngésző helyettesítheti a kívánt méretet a sorban következővel. A font-size tulajdonságnál természetesen megadhatunk százalékos értéket, hossz esetében pedig használható abszolút érték (mondjuk pontok számában), vagy relatív érték (például pixelszámban) stb. Abszolút értékadáskor mindig valamilyen mértékegységben határozzuk meg a szükséges méretet, ezekkel tehát érdemes megismerkedni. A lehetséges abszolút mértékegységek a következők: in: hüvelyk vagy inch = 2,54 cm; cm: centiméter; mm: milliméter; pt: pontok száma, ahol 1 pont 1/72 hüvelyknek ( cm) felel meg; pc: pica, (1 pc = 12 pt); Mindez azt jelenti, hogy például a kötet szövegét tartalmazó XHTML állomány <body> részére beállított alábbi értékek azonos betűméretet eredményeznek: 8 Cascading Style Sheets referencia: 'font-size' [Elektronikus dokumentum.] URL: A letöltés időpontja

133 Lépcsős stíluslapok CSS body {font-size : 0.42cm;} body {font-size : 4.2mm;} body {font-size : 12pt;} body {font-size : 1pc;} Relatív értékadáskor mindig egy másik hosszúságegységhez viszonyítva határozzuk meg a kívánt méretet: em: az aktuális font betűmagassága; ex: az aktuális font x karakterének a magassága; px: pixel, a megjelenítő eszköz képpontja; Hogy érthetőbb legyen, nézzünk egy példát. Tegyük fel, hogy van egy bekezdésünk, amelynek beállítunk egy 15 pontos betűméretet. Majd azt mondjuk, hogy a bekezdésnek legyen behúzása, mégpedig a beállított font aktuális betűmagasságának háromszorosa: p {font-size : 15pt; text-indent : 3em; /* 45pt */ } Ha böngészőben leellenőrizzük a beállítást, akkor valóban azt tapasztaljuk, hogy a beállított érték lesz a behúzás mértéke. [Megj.: Az em és ex értékek az elem fontméretéhez igazodnak. E szabály alól az egyetlen kivétel a fontsize tulajdonság, ahol az em és ex értékek a szülő elem fontméretéhez viszonyítandók. A pixel egységek a vászon leggyakrabban számítógép képernyője felbontásához illeszkednek, ha tehát a kimeneti eszköz pixelsűrűsége nagyban különbözik a számítógép képernyőjétől, a megjelenítő eszköz átszámolja a pixelértékeket.] 3.6. Összetett betűtulajdonságok font: font-style font-variant font-weight font-size/line-height font-family; Az összes olyan betűkkel kapcsolatos beállítást, amit eddig ismertettünk, a font tulajdonság kényelmesen egyetlen utasításba sűríti olyan paraméterekkel, amelyek meghatározzák: a betűkészlet stílusát, a betűváltozatot, a betűvastagságot, a méretet, a sorközt az egyes értékeket ( / ) karakter választja el és végül a betűcsaládot. Az alábbiakban a <p> elemen alkalmazzuk az előbb említett tulajdonságokat, méghozzá egyetlen utasításba sűrítve: p {font: italic small-caps bold 110%/110% Garamond;} A példában kitűnően látszik, hogy nagyon sokat spórolhatunk, ha a fontbeállításokat egyetlen tulajdonságba sűrítjük. Ez persze nem jelenti azt, hogy mindig minden belső tulajdonságot szerepeltetnünk kell a beállításoknál, elég kizárólag azokat, amiket használni szeretnénk: p {font: italic large "Palatino Linotype";} 4. Szövegstílus-tulajdonságok Miután a betűk formázásának legalapvetőbb lehetőségeivel megismerkedtünk, tovább kell lépni egy nagyobb egységre, ami nem más, mint a szöveg. A szöveg formai beállításai alapvetően meghatározzák a feldolgozott 123

134 Lépcsős stíluslapok CSS kötetek webes megjelenését, tehát szövegformázás során olyan tulajdonságokkal kell megismerkednünk, mint az első sor behúzása, a szavak és betűk közötti távolságok beállítása, a nagybetűk és kisbetűk automatikus átalakítása, az aláhúzások és áthúzások, a sorok és szavak vízszintes és függőleges elrendezése stb Betűközök letter-spacing: normal hosszérték; Kiemelések esetében előfordul, hogy ritkított, vagy sűrű betűközökre van szükség. Ennek szabályozására használható az a letter-spacing tulajdonság, amely értékül egy akár negatív értékű hosszparamétert, vagy alapértelmezett "normal" értéket kaphat: span {letter-spacing: 3pt;} Mivel a betűritkítás általában megbontja a szöveg egységes hatását, ezért leginkább akkor alkalmazzuk, ha az eredeti nyomtatott szöveg formázásaihoz ragaszkodunk a webes megjelenítés során is Szóközök word-spacing: normal hosszérték; Kiemeléseknél a word-spacing segítségével lehet a szóközök méretét szabályozni. A tulajdonság egy hosszparamétert, vagy "normal" (alapértelmezés) értéket kaphat: p {word-spacing: 2pt;} Mivel a szóközök növelésére vagy csökkentésére normál szöveg esetében általában nincs szükség, így ritkán használjuk. Egyedül a csupa nagybetűvel írt szövegeknél lehet indokolt egy kicsit megnövelni a szóközöket a jobb olvashatóság érdekében Szövegdekoráció text-decoration: none underline overline line-trough; A text-decoration -nel a szövegek egyes megjelenésbeli tulajdonságait tudjuk szabályozni, mégpedig vonalakkal. A tulajdonsághoz a következő értékeket rendelhetjük: "none" nincs dekoráció (alapértelmezés), "overline" föléhúzott, "underline" aláhúzott, "line-through" áthúzott (pl. lecserélt szöveg esetén) és "blink" villogó (ezt nem minden böngésző támogatja). A text-decoration tulajdonságot leggyakrabban hivatkozásoknál használjuk. Egy vakok és gyengénlátók számára készített oldal esetében például a következő szövegdekorációkat célszerű beállítani: body a {background : black;} {color : yellow; text-decoration : underline;} a:hover {color : black; text-decoration : underline overline; background : white;} Példánkban beállítottuk, hogy a hivatkozások fekete oldalháttéren sárga színnel és aláhúzottan jelenjenek meg. Abban az esetben viszont, ha föléjük kerül a kurzor, a hivatkozások szövegének háttérszíne feketéről fehérre vált, maga a szöveg pedig fekete színű, illetve alá- és föléhúzott lesz Kis- és nagybetűk text-transform: none capitalize uppercase lowercase; A text-transform tulajdonság kis- és nagybetűs alakok létrehozását teszi lehetővé, függetlenül attól, hogy eredetileg hogyan kódoltuk a karaktereket a 124

135 Lépcsős stíluslapok CSS tárolási formátumba. Egy elvi megállapodás alapján például lehet, hogy az XHTML outputban minden könyvcímet csupa nagybetűvel kell írni még akkor is, ha netán az eredeti kötetben csak a kezdőbetű nagy. A tulajdonság a "capitalize" (minden szó első karaktere nagybetű), a "lowercase" (kisbetűs), az "uppercase" (nagybetűs) vagy a "none" (semmilyen változás nem történik, ezzel az értékkel felülbírálhatjuk az örökölt értéket, s egyben ez az alapértelmezés} értékeket kaphatja: h1 {text-transform: uppercase;} 4.5. Szövegigazítás text-align: left right center justify; Bekezdések, mottó, ajánlás, dátumozások stb. esetében szükség lehet a szöveg különböző irányú igazításaira. A text-align tulajdonság segítségével szövegünk sorkizárt "justify" (mint ennek a könyvnek a szövege), bal margóhoz igazított "left", jobb margóhoz igazított "right" vagy középre igazított "center" formát ölthet: p {text-align: center;} [Megj.: A CSS text-align tulajdonsága valójában a HTML nyelv align attribútumát hivatott helyettesíteni, mivel az utóbbi használata már a HTML 4.0-ban is kifogásolt volt, az XHTML-ben pedig szabálytalan.] 4.6. Szövegbehúzás text-indent: hossz százalék; A bekezdések első sora általában behúzást tartalmaz, amit a text-indent tulajdonsággal állíthatunk be. A behúzás a bekezdés bal oldalától kezdve üres helyként jelenik meg jobbról balra írt szövegeknél értelemszerűen fordítva. A text-indent hossz- vagy százalékos értéket kaphat, ahol a százalékos érték a szülőelem szélességének tört részét jelenti. p {text-indent: 5%;} A tulajdonság kaphat negatív értéket is. Ebben az esetben azonban nem a szövegszerkesztőkből már jól ismert függő behúzás érvényesül sajnos. Ugyanúgy az első sor pozíciója változik meg a szövegblokk oldalához képest, mint amikor pozitív értéket kap a tulajdonság. Tehát ebben az esetben az első sor kijjebb, néha a képernyőn kívül kezdődik, a többi sor helyzete természetesen nem változik. A függő behúzás formájának eléréséhez a szöveg bal margóját rendszerint akkorára kell növelnünk, amekkora negatív értéket adunk a textindent tulajdonságnak. [Megj.: A stíluslapok kifejlesztése előtt nem lehetett megadni a szövegblokkok bal oldali behúzásának értékét maximum szóközkkel, ám ez nem elegáns. Másik lehetőség volt a kis méretű áttetsző GIF képek alkalmazása, de az is eléggé rugalmatlan megoldás. Sokkal jobb, ha egy számértéket adunk meg, vagy ha százalékos formát alkalmazunk, hiszen ez utóbbi esetben az ablak átméretezését is követi a behúzás.] 4.7. Szöveg előformázása white-space: normal pre nowrap; A white-space tulajdonság azt határozza meg, miként legyenek kezelve az adott elemen belüli szóköz, tabulátor, soremelés, kocsi vissza és a lapdobás karakterek. A CSS 1.0- ban három értéket vehet fel: ( normal ) normál: összevonja a whitespace-ek sorozatát ez az alapértelmezett; ( pre ) előformázott: sortörés csak ott jön létre, ahol a forrásban is új sor kezdődik; ( nowrap ) törésmentes: szintén összevonja a közöket, de megtiltja a szövegen belüli sortörést; 125

136 Lépcsős stíluslapok CSS Mindhárom érték a szövegben jelenlévő whitespace-ekre vonatkozik, de a forráskód szinten létrehozottakra pl. a <br/> elem az XHTML-ben nem. 9 [Megj.: A "pre" használata alkalmas speciálisan formázott szövegek, képversek webes megjelenítésére, de sajnos a tulajdonságnak ezt az értékét nem minden böngésző támogatja teljes mértékben, ezért alkalmazását kellő körültekintéssel javasoljuk. A "nowrap" használatával is vigyáznunk kell, mert már egy, a forráskódban néhány soros bekezdés is egyetlen hosszú sorként jelenik meg a képernyőn, és a kinyomtatása is lehetetlenné válik. Csak olyankor használjuk, amikor egy-egy konkrét szövegrészt, például forráskódot vagy URL-t szeretnénk sortörés nélkül megjeleníteni.] 4.8. Szövegsorok közti távolság line-height: normal számérték hosszérték százalékos érték; A line-height tulajdonsággal két szomszédos sor aljának, vagyis alapvonalának a távolságát állíthatjuk be. Ha numerikus értéket határozunk meg a definícióban, akkor a fontméret és a számérték szorzata adja meg a sormagasságot. A line-height felvehet "normal" (a betűkészlet alapértelmezett sormagassága), szám- (a sortáv aránya a betűmérethez viszonyítva), hossz- (a sormagasság konkrét értékének megadása) és százalékos értéket (a sortáv aránya a betűméret százalékában): div {line-height : 120%; font-size : 10pt;} [Megj.: Sortávolság beállításakor általában az aktuális betűméret %-át célszerű beállítani. A böngészők automatikusan ezt az értéket használják, így ettől csak akkor térjünk el, ha valamilyen célunk van vele. Nagyobb glyph-ekből 10 álló fontoknál, vagy hosszú soroknál esetleg szükség lehet a sortávolság megnövelésére fordított esetben csökkentésére, de ezeket a módosításokat megfontoltan kell kezelni.] 4.9. Függőleges szövegelrendezés vertical-align: baseline sub super top text-top middle bottom text-bottom százalékos érték; Valamely elem függőleges, szülőeleméhez viszonyított pozícióját a vertical-align tulajdonsággal adhatjuk meg. A tulajdonság lehetséges értékei közül egy csoport ténylegesen a szülőelemhez viszonyítja a kérdéses elem függőleges pozícióját: ( baseline ): az elem alapvonalára igazít; ( middle ): a szülőelem függőleges középvonalához igazít általában képeknél; ( sub ): alsó index lesz az aktuális elem; ( super ): a szülő elem felső indexe az aktuális elem; ( text-top ): a szülő betűinek tetejéhez igazít; ( text-bottom ): a szülő elem betűinek az aljához igazít; Az értékkészlet második csoportja viszont már a formázott sorhoz igazítja az elem elhelyezkedését: ( top ): a sor legmagasabb eleméhez igazít; ( bottom ): a sor legmélyebben fekvő eleméhez igazít; 9 A CSS 2.1-ben a white-space két új értéket kapott: "pre-wrap" és "pre-line". Az előbbi nem vonja össze a közöket, tehát sortörés ott jön létre, ahol a forrásban új sor kezdődik, vagy ott, ahol a sordoboz kitöltése érdekében szükséges. Az utóbbi összevonja a közöket, így a sorok ott törnek, ahol a forrásban új sor kezdődik, vagy ott, ahol a sordoboz kitöltése érdekében szükséges. 10 A glyph-ek betűk és más jelek grafikus képei. 126

137 Lépcsős stíluslapok CSS Amennyiben százalékos érték használata mellett döntünk, úgy tudnunk kell, hogy annak viszonyítási alapja az elem line-height tulajdonsága. Ez a tulajdonság felel az elem alapvonalának "baseline" hollétéért, vagy az elem aljának elhelyezkedéséért, ha az elemnek nincs alapvonala. Negatív értékek megengedettek, a -100% például annyira lesüllyeszti az elemet, hogy annak alapvonala a következő sor alapvonalához ér. Ez olyan elemek függőleges igazításának is különösen pontos beállítását teszi lehetővé, amelyeknek nincs alapvonaluk pl. képek: img {vertical-align: middle;} 5. Egyéb, megjelenést szabályozó tulajdonságok 5.1. Színek color: színérték; A color tulajdonság segítségével bármelyik elem színét megváltoztathatjuk. A színek megadásának több módja is létezik: a színek megadhatók saját nevükkel: pl. red, green, blue; definiálhatók a hozzájuk rendelt RGB-formátumú számértékekkel rgb(234, 45, 01), rgb(45%, 0%, 55%); az RGB értékeket hexadecimális számformátumával #fffeee; b {color: #ff0000;} [Megj.: A hexaértékek megtudhatók képszerkesztő programokból, vagy olyan egyszerű kis programokkal, mint a Colorpicker. A Paint programból a decimális RGB értékek nyerhetők ki.] background-color: színérték transparent; A bacground-color tulajdonsággal a teljes oldal, vagy annak bizonyos részei akár elemei saját háttérszíneket kaphatnak a stíluslaptól, de az elemekhez áttetsző "transparent" hátteret is rendelhetünk. h2 {background-color: #fafafa;} 5.2. Margók margin: hosszérték százalékos érték; A margin tulajdonság és annak kibontása: margin-left, margin-right, margin-top és margin-bottom határozza meg az egyes elemek és bármely szomszédos elem közti távolság méretét. A margin különböző értékei eltérő felső, jobb oldali, alsó és bal oldali margót határozhatnak meg akár az egész oldalra vonatkozóan. Ha értékként négy számértéket adunk meg, annak értelmezési sorrendje mindig a felső => jobb => alsó => bal sorrendet követi. Ha csak egy érték van megadva, az mind a négy oldalra vonatkozik, ha kettő, vagy három, akkor a szemben lévő értékek meg fognak egyezni. A következő példák ugyanazt eredményezik: body {margin-top : 3pt; margin-right : 3pt; margin-bottom : 4pt; margin-left : 2pt;} 127

138 Lépcsős stíluslapok CSS body {margin: 3pt 3pt 4pt 2pt;} [Megj.: Bár alapesetben nem látszik, de tudnunk kell, hogy a szöveg egyes elemei ún. konténereken (doboz) belül formázhatók. Ezek a dobozok ritkán érintkeznek, hiszen margók választhatják el őket egymástól. A margókon belül keretvonalakat is használhatunk, sőt definiálhatjuk a keretvonal és a tartalomdoboz közötti kitöltés nagyságát. Mindegyik területre rendelkezésünkre állnak tulajdonságok, amelyek révén a felső rész, a jobb oldal, az alsó rész vagy a bal oldal egyedi stílust kaphat. A dobozmodell tehát a következőképpen épül fel befelé haladva: margó => keret => kitöltés a keret és a szöveg között => szöveg.] 5.3. Keretek border: border-width border-style színérték; A keretekről először valószínűleg mindenkinek a táblázatok és a képek jutnak eszébe, hiszen HTML-ben a border tulajdonsággal lehetett szabályozni meglétüket. Ehelyett az attribútum helyett azonban a CSS bevezette a border tulajdonságot, amely egy ún. gyorstulajdonság. Segítségével egy deklaráción belül állítható be a border-top, border-right, borderbottom és a border-left tulajdonságok értéke. table {border-top : dotted gray; border-right : dotted gray; border-bottom : dotted gray; border-left : dotted gray;} table {border : dotted gray;} Eltérően a margin és padding tulajdonságoktól, a border nem tud különböző értékeket beállítani az egyes oldalakhoz. Ehhez a többi szegélytulajdonságot kell használni: table {border-top : 1pt solid black; border-right : 2pt dashed gray; border-bottom : 1pt solid gray; border-left : 2pt dashed black;} Az eddigi példákból már lehet következtetni arra, hogy a keretvonal meghatározott vastagsággal, színnel és stílussal is rendelkezhet. A border-with a keretvastagság, a border-color a keretszín, a borderstyle pedig a keretstílus. border-width: thin medium thick hosszérték; A border-width szintén egy gyorstulajdonság, amelynek segítségével egy deklaráción belül állítható be a border-width-top, border-width-right, border-width-bottom és a border-width-left tulajdonságok értéke. Abban az esetben, ha mind a négy értéket megadjuk, értelemszerűen minden szegély a neki megadott értéket kapja. Három érték esetén első érték a felső, a második a jobb és bal, a harmadik az alsó szegélyre vonatkozik. Két értéknél az első a felső és alsó szegélyekre, a második a bal és jobb szegélyre vonatkozik. Amennyiben egyetlen értéket definiálunk, úgy minden szegély azt fogja kapni. Szegélyszélesség negatív értéket nem vehet fel! A következő példában a megjegyzésben írt értékek jelzik a szegélyek vastagságát: table {border-width: thin;} /* mindegyik vekony */ table {border-width: thin thick;} /* vekony vastag vekony vastag */ table {border-width: thin thick medium;} /* vekony vastag kozepes vekony */ table {border-width: thin thick medium thin;} /* vekony vastag kozepes vekony */ 128

139 Lépcsős stíluslapok CSS border-color: színérték; A border-color tulajdonság a szegélyek színét állítja be. Négy értéke lehet, az értékek a különböző oldalakhoz tartoznak, ahogyan azt a border-width tulajdonságnál már ismertettük: img {border-color: blue;} border-style: none dotted dashed solid double groove ridge inset outset; A különféle keretek eltérő stílusúak is lehetnek, melyet a border-style tulajdonsággal szabályozhatunk. Négy értéke lehet, az értékek a különböző oldalak színeit állítják be, ahogyan azt a border-width tulajdonságnál leírtuk. Mivel a szegélystílusok alapértelmezés szerinti beállítása "none", külön beállított értékek nélkül az elemeknek nem lesz látható szegélye. Gyakori azonban, hogy a keretstílusok definiálására inkább az egyes értékeket összefogni képes border-top, border-right, border-bottom és border-left tulajdonságokat használjuk. A szegélystílusok lehetséges értékei a következő megjelenést redményezik: ( none ): nincs szegélystílus; ( dotted ): pontozott; ( dashed ): szaggatott; ( solid ): folytonos vonalú; ( double ): dupla vonalú szélessége ugyanaz, mint a border-width -é; ( groove ): 3D süllyesztett hatású; ( ridge ): 3D domború hatású; ( inset ): 3D beékelt stílusú; ( outset ): 3D kiemelt hatású; #oszlop {border-style: dashed;} 5.4. Kitöltés padding: hosszérték százalékos érték; A keret és a tényleges szöveges tartalom közti űr kitöltésére használható tulajdonság a padding. A margin -hoz és a border -hez hasonlóan, ugyancsak gyorstulajdonságról van szó, amelynek segítségével egy deklaráción belül állítható be a padding-top, padding-right, padding-bottom és a padding-left, vagyis az egyes oldalakhoz definiálható kitöltés mértéke. Ez a tulajdonság is négy értéket vehet fel, a kitöltési értékek azonban nem lehetnek negatívak: h3 {padding-top : 1em; padding-right : 2em; padding-bottom : 1em; padding-left : 2em;} h3 {padding : 1em 2em 1em 2em;} Példánk "1em" értékű kitöltést állít be fent és lent, illetve "2em" értékű kitöltést jobb- és baloldalt. Mivel az em viszonyítási alapja az elem fontmérete, ezért az "1em" egyszeres megegyezik a használt font magaságával. 129

140 Lépcsős stíluslapok CSS 6. CSS és XHTML Az alapvető betű- és szövegstílus beállítási lehetőségek ismertetését követően, hogy mindenki számára világosabbá váljon a lépcsős stíluslapok gyakorlati alkalmazása és haszna, egy konkrét megvalósítást mutatunk be. A példa JÓZSEF Attila Ringató 11 c. versének érvényes XHTML 1.1 verziója, ugyancsak érvényes belső CSS-sel formázva, amely egyúttal jól illusztrálja számunkra az SGML/XML-ben feldolgozott versek webre helyezendő XHTML outputjával kapcsolatos kívánalmakat 12 : <?xml version="1.0" encoding="iso "?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " <html xmlns=" xml:lang="hu"> <head> <title>ringató</title> <meta http-equiv="content-type" content="text/html; charset=iso " /> <meta http-equiv="content-style-type" content="text/css" /> <style type="text/css" media="all"> body {font-family : Garamond, sans-serif; text-align : justify; background : #fafafa; margin : 5%;} h1 {margin-top : 50px; margin-bottom : 20pt; text-indent : 40%; font-weight : normal;}.lg {text-indent : 40%;.lg div margin-bottom : 15pt;} {text-align : left; white-space : nowrap; line-height : 1.4em;} </style> </head> <body> <h1>ringató</h1> <div class="lg"> <div>holott náddal ringat,</div> <div>holott csobogással,</div> <div>kékellő derűvel,</div> <div>tavi csókolással.</div> </div> <div class="lg"> <div>lehet, hogy szerelme</div> <div>földerül majd mással,</div> <div>de az is ringassa</div> <div>ilyen ringatással.</div> </div> </body> </html> Példánk forráskódját ringato.html néven elmentve, majd böngészőben megnyitva az alábbi végeredményt kapjuk: 11 A verset a Neumann-ház Bibliotheca Hungarica Internetiana (BHI) Magyar Szövegtárából vettük, ám az itt bemutatott forráskód nem egyezik meg az abban használatossal. 12 A példában bemutatott megoldás speciális formázásokat tartalmazó versek pl. képversek, vagy eltérő sorbehúzásokat tartalmazó versszakok esetében nem alkalmazható. Ilyen esetekben ideálisabb előformázott szövegként, vagy a jobb formázhatóság érdekében egymásba ágyazott táblázatokban megjeleníteni a verset. 130

141 Lépcsős stíluslapok CSS JÓZSEF Attila Ringató c. verse IE 6.0-ban Úgy véljük, már az eddig használt CSS 1.0-ba tartozó utasítások is messze több lehetőséget kínálnak számunkra, mint azt a HTML valaha is tette. Indokolatlanul, feleslegesen azonban nem kell használni őket. Ha egy szövegben például félkövér, dőlt, alsó- vagy felsőindex formázásokkal akarunk kiemelni bizonyos szavakat, ne hozzunk létre egy stílusosztályt ennek megvalósítására, hanem használjuk nyugodtan az XHTML-ben is érvényes <b>, <i>, <sub> és <sup> elemeket. Vagyis több, azonos eredményre vezető megoldás közül mindig az egyszerűbbet, könnyebben megvalósíthatót válasszuk! 7. CSS és XML Láttuk, hogy HTML/XHTML állományokhoz milyen mechanizmusok segítségével kapcsolhatunk stílusokat. Azt is tapasztalhattuk, hogy ezek a lehetőségek nagymértékben a HTML nyelv bővítései révén kerültek az ajánlásba. Felvetődik tehát a kérdés: ugyanez működik XML fájloknál is? Nos, az XML alkalmazásakor kicsit más megközelítés szükséges, hiszen nincs <head> rész, melynek <style> elemében elhelyezhetnénk a belső stíluslapot, és nincs style attribútum sem hacsak a DTD vagy XML Schema minden eleméhez nem társítjuk. Egyértelműnek látszik tehát, hogy a külső CSS lapok kapcsolása a legmegfelelőbb és egyedüli járható út. Bár a CSS c. alfejezetben már érintőlegesen szó volt róla, azért felelevenítjük, hogy bármely XML dokumentum egy feldolgozó utasítás segítségével hivatkozhat az alkalmazandó stíluslapra. Elfogadott W3C ajánlás van érvényben az ilyen utasításokra, amelyek ráadásul mind a lépcsős, mind pedig a transzformációra képes stíluslapokkal képesek együttműködni. A szóban forgó elem az <xml-stylesheet>, melynek href tulajdonsága URL segítségével azonosítja a külső stíluslap helyét, type attribútuma pedig az alkalmazott stíluslap típusát. A CSS használatakor alkalmazandó típus értéke "text/css": <?xml-stylesheet href="*.css" type="text/css"?> Az <?xml-stylesheet...?> utasítás a bemutatott kettőn kívül számos egyéb opcionális paraméterrel rendelkezhet: title="string" Ebben a karakterláncot értékül kapó paraméterben, ha akarjuk, akkor címet adhatunk a stíluslapnak. 131

142 Lépcsős stíluslapok CSS media="string" XML dokumentumaink több eltérő alkalmazási célból is feldolgozhatóak, hiszen nem biztos, hogy a weben fogjuk publikálni őket. Itt lehet megadni a végeredmény médiatípusát a helyes működés elősegítése céljából. charset="string" Ha az XML dokumentumban egy kiterjesztett karakterkészletet használunk, akkor azt ezen a helyen kell definiálnunk. A megadott készletnek meg kell egyeznie az <?xml version="1.0"...?> vezérlési utasításban megadottal. alternate="yes no" Ha a dokumentumunkban több lehetséges stíluslap közül szeretnénk választani, akkor ezt az attribútumot igaz értékre kell állítani alapértelmezett mindig a "no". Nézzük a meghívási módot: <?xml-stylesheet type="text/css" href="kicsi.css" title="kicsi fontok" alternate="yes"?> <?xml-stylesheet type="text/css" href="nagy.css" title="nagy fontok" alternate="yes"?> Ha tehát az XML állomány az előbbi két sort tartalmazza, a feldolgozó alkalmazásnak kell kiválasztania a helyzethez leginkább illő stíluskészletet valahogy úgy, mint ahogy HTML/XHTML esetében is láttuk. Mivel a böngészőprogramokat alapvetően HTML érzékenységre tervezték, ezért az általunk készített stíluslapnak HTML/XHTML esetében nem is kell minden információról gondoskodnia. Miről is van szó konkrétan? Nem másról, minthogy szövegeinkben bárhol előfordulhatnak blokk szintű, illetve soros elemek. Blokk elem lehet például a bekezdés, a lista vagy egy címsor, soros elem pedig minden kiemelés félkövér, dőlt, aláhúzott alsó- és felsőindex, vagy a hivatkozások. Ha HTML/XHTML nyelvet használunk, akkor a browser-nek nem kell megmondanunk, hogy melyik elemünk melyik kategóriába tartozik, XML-nél viszont sajnos nem tudhatja, hiszen nincsenek előre definiált elemek. Ilyenkor hívhatjuk segítségül a CSS nyelv display tulajdonságát! display: block inline list-item none; 13 Ez a tulajdonság határozza meg, hogy egy elem legyen-e, és hogyan legyen ábrázolva a megjelenítőn. Az egyes jelölőkhöz a következő típusokat rendelhetjük: ( block ): az elem blokkszintű megjelenést kap; ( inline ): az elem soron belüli dobozban fog elhelyezkedni; ( list-item ): az elem listaelemként fog viselkedni; ( none ): nem jön létre a doboz; Ha egy elemhez nem adjuk meg a display tulajdonságot, akkor alapértelmezetten blokként viselkedik. A következő két példa tehát egyenértékű: cim {font-size : 14pt;} cim {font-size : 14pt; display : block;} A "blokk" érték azt jelenti a böngésző számára, hogy az elemtartalom előtt és után sortöréseket kell generálni. Ha "inline"-t állítunk be, akkor nem keletkezik sortörés az elem körül. Listaelemek számozása is automatikusan létrehozható, hiszen a "list-item" érték beállításával az elemtartalom előtt számozás jelenik meg. Amennyiben "none" megjelenítési értéket kap egy elem, úgy nem fog megjelenni a képernyőn. Nézzünk egy egyszerű példát: <!-- CSS --> bekezdes { 13 A CSS 2.0 és 2.1-es ajánlás további értékeket is meghatároz, melyekkel akár táblázatelemek is társíthatók az egyes XML jelölőkhöz. 132

143 Lépcsős stíluslapok CSS display : block; font-family : Garamond; } kiemeles { display : inline; font-style : italic; } elem { display : list-item; } <!-- XML --> <bekezdes>az <kiemeles>1998</kiemeles>-ik évi őszelő közepén egy kis utazó csoport közeledett a bájos völgynyíláshoz. A vándorok a következő személyek voltak:</bekezdes> <elem>winkler Tímea</elem> <elem>winkler Edina</elem> <elem>varga Luca</elem> Ahhoz tehát, hogy XML állományok tartalmát böngészőben megjelenítsük, nem kell semmi mást tenni, mint az egyes elemnevekhez stílust társítani. Ha a gyermekelemhez nem rendelünk külön tulajdonságokat, akkor a szülőtől örökli a megjelenési formát! A technológia viszonylagos egyszerűségén felbuzdulva tekintsük meg a korában bemutatott Ringató c. verset, ám ezúttal TEI XML-ben kódolva, majd CSS-sel formázottan megjelenítve: <!-- CSS (ringato.css) --> TEI { font-family : Garamond, sans-serif; text-align : justify; background : #fafafa; margin : 5%; } teiheader { display : none; } head { margin-top : 20pt; margin-bottom: 20pt; text-indent : 42%; font-size : 24pt; font-weight : normal; display : block; } lg { text-indent : 42%; margin-bottom: 15pt; display : block; } l { text-align : left; line-height : 1.4em; display : block; white-space : nowrap; } <!-- TEI P5 XML --> <?xml version="1.0" encoding="utf-8"?> <?xml-stylesheet type="text/css" href="ringato.css"?> <!DOCTYPE TEI PUBLIC "-//TEI P5//DTD Main Document Type//EN" " [ <!ENTITY % TEI.core 'INCLUDE' > <!ENTITY % TEI.header 'INCLUDE' > <!ENTITY % TEI.textstructure 'INCLUDE' > 133

144 Lépcsős stíluslapok CSS <!ENTITY % TEI.mixed 'INCLUDE' > <!ENTITY % TEI.figures 'INCLUDE' > <!ENTITY % TEI.linking 'INCLUDE' > <!ENTITY % TEI.verse 'INCLUDE' > ]> <TEI> <teiheader> "..." </teiheader> <text> <body> <head>ringató</head> <lg> <l>holott náddal ringat,</l> <l>holott csobogással,</l> <l>kékellő derűvel,</l> <l>tavi csókolással.</l> </lg> <lg> <l>lehet, hogy szerelme</l> <l>földerül majd mással,</l> <l>de az is ringassa</l> <l>ilyen ringatással.</l> </lg> </body> </text> </TEI> JÓZSEF Attila Ringató c. verse a Firefox Deer Park Alpha 2-ben -ben Természetesen a lépcsős stíluslapok újabb ajánlásaiban további tulajdonságok állnak rendelkezésünkre, amelyek segítségével még speciálisabb különbségeket tehetünk blokk- és sorszintű elemek között, listákat és listaelemeket azonosíthatunk, valamint olyan elemeket is, amelyekben több szóközt meg kell őrizni. Ezek a tulajdonságok nem létfontosságúak a HTML/XHTML használata során, de az XML semmiképp nem formázható nélkülük. Akit tehát részletesebben érdekelnek a display, white-space, liststyle-type, list-style-image, list-style-position és fist-style stb. tulajdonságok, annak javasoljuk, hogy mélyedjen el a fejezetben meghivatkozott ajánlásokban. Ugyanakkor tisztában kell lennünk azzal, hogy ezeknek az újabb, speciálisabb tulajdonságoknak az alkalmazásánál gyakran nem azt kapjuk, amire a beállítások alapján 134