Programozás | XML » Bíró Szabolcs - Szövegfeldolgozás XML alapokon

Szövegfeldolgozás XML alapokon 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árInformatikai 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, 2005. februárja Bíró Szabolcs Neumann-ház Tartalom Előszó 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” 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 Attribútumok Entitások 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 Attribútum-lista deklarációk Entitás deklarációk NOTATION deklarációk Szövegjelölés TEI DTD alapján TEI A TEI alapelvei és előnyei A TEI felépítése A TEI jövője Szövegjelölés DocBook DTD alapján DocBook A DocBook előnyei A DocBook felépítése 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 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 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 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 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 A táblázatok listája 1. Kulcsszavak SGML/XML-ben 1. Bonyolult táblázat 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?  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, 2005. februárja KORA András Walt Disney Internet Group Bevezetés Tartalom 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 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-k1 , 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, 128XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition) What is XHTML? [Elektronikus dokumentum.] URL: http://wwww3org/TR/xhtml1/#xhtml A letöltés időpontja 2005. 07 25 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, informatikuskö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. 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 129W3C hírek – Archívum. [Elektronikus dokumentum] URL:

http://www.w3chu/archivum/2002/w3cnewshtml A letöltés időpontja 2005 07 25 szolgáltatása3 – 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 1.2”4 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ő,

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, informatikus-kö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; 130RAGETT, Dave: My web site is standard! And yours? / ford.: SIKOS László: Az én weblapom szabványos! És az Öné? [Elektronikus dokumentum.] URL: http://www.w3org/QA/2002/04/Web-Quality A letöltés időpontja 2005 07 25 131BATES, Chris: XML: elmélet és gyakorlat. Bp: Panem Kiadó, 2004 p 378 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. 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én6 alapul – bővebben az Irodalomjeyzékből lehet tájékozódni. 132DOM – 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. 133Modularization of

XHTML™. [Elektronikus dokumentum] URL: http://www.w3org/TR/xhtml-modularization/ A letöltés időpontja 2005 07 25 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. 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 --> SGML/XML --> <!-- 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. 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 Az XML-hez vezető út – áttekintés Tartalom 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” HTML – az SGML „gyermeke” XML – az SGML „öccse” 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. 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.7 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 1.75 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? 134XHTML namespace. [Elektronikus dokumentum] URL: http://wwww3org/1999/xhtml A letöltés időpontja 2005. 07 25  Ékezethelyesen kapják-e meg a szövegeket?8 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-n9 kívül nincs olyan szervezet, amely további fejlődését kizárólagosan befolyásolhatná. Ezzel szemben a PDF az Adobe10 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, 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, 135SÜ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, 2001 p 225 136KISS Gergő, KOVÁCS László, MICSIK András: HEKTÁR: Hazai elektronikus könyvtári rendszerek összekapcsolása. [Elektronikus

dokumentum] URL: http://mek.oszkhu/html/irattar/ajanlas/hektar2004pdf A letöltés időpontja 2005 07 25 137POWELL, Andy: Expressing Dublin Core in HTML/XHTML meta and link elements. [Elektronikus dokumentum.] URL: http://dublincoreorg/documents/dcq-html/ A letöltés időpontja 2005. 07 25 felhasználási lehetőségeik gyakorlatilag „nullára redukálódhatnak”.11 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. 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? 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.12 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 138RDF – 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: http://www.w3org/RDF/ A letöltés időpontja 2005 07 25 139DC-dot Dublin Core Metadata editor. [Honlap] URL: http://wwwukolnacuk/cgibin/dcdotpl A letöltés időpontja 2005 07 25 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. 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. 1985-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. 1985 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.13 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 140MathML Namespace. [Elektronikus dokumentum] URL: http://www.w3org/1998/Math/MathML/ A letöltés időpontja 2005 07 29 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. 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 40);  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. E-mail ü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ő”) e-mail ü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 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 egyremá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. 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 XMLhez 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:14 1. Könnyű használhatóság 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 141Az Amaya a W3C tesztböngészője, amely szerkesztésre és böngészésre egyaránt használható. Amaya Home Page. [Honlap] URL: http://wwww3org/Amaya/Overviewhtml A letöltés időpontja 2005. 07 29 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évterek15, sémák16 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 SGML-en, vagyis egy ASCII17 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. 142Fonts for MathML-enabled Mozilla. [Honlap]

URL: http://www.mozillaorg/projects/mathml/fonts/ A letöltés időpontja 2005 07 29 143SVG – 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: http://www.w3org/TR/SVG/ A letöltés időpontja 2005 07 29 144Web Center Features – SVG – Manual Download. [Honlap] URL: http://www.adobecom/svg/viewer/install/mainhtml A letöltés időpontja 2005 07 29 8. Formális és tömör tervezé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:18 145Az 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. A jelölőnyelvek fejlődése napjainkig Az SGML/XML jelölésrendszer – kódolás Tartalom Leíró kontra műveleti jelölés Leíró jelölés Műveleti jelölés Szintaktika – SGML/XML Elemek Attribútumok Entitások Megjegyzések Nem elemzett karakteres adatok XML-deklaráció Dokumentumtípus-deklaráció (DTD) 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 XMLprogramok 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. 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 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ó.] 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: <!-- SGML/XML --> <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? 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. 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 STAGC ETAGO ETAGC (Start Tag Open) (Start Tag Close) (End Tag Open) (End Tag Close) = = = = a a a a kezdő jelölőelem nyitó eleme kezdő jelölőelem záró eleme befejező jelölőelem nyitó eleme 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 sgmldef é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: <!-- SGML/XML --> <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/XML-alkalmazásról beszélünk, akkor a jelölőnyelv olyan használatát vizsgáljuk, melyhez számos elemet definiáltunk. Ezért mondhatjuk, hogy a HTML valójában SGMLalkalmazás, a WML vagy az XHTML pedig XML-alkalmazá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. whitespace19 karaktereket Ha szövegfeldolgozásba kezdünk és saját jelölésrendszert akarunk kialakítani20, akkor a következőkre mindenképp oda kell figyelni: 1. Kisbetűk és nagybetűk 146MIME – 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. 147A 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 2005 szeptemberében megjelenő Firefox 15 alapja Deer Park Alpha 2 Start Page. [Honlap]

URL: http://www.mozillaorg/projects/deerpark/alpha2html A letöltés időpontja 2005 07 29 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 – WML21, OEB22. A módszer előnye, hogy az egyes elemnevek jelentésével mindenki tisztában van, ráadásul HTML2XML átalakítások23 é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 148Building Mozilla with SVG Support. [Honlap] URL: http://www.mozillaorg/projects/svg/buildhtml A letöltés időpontja 2005 07 29 149The W3C Markup Validation Service. [Honlap] URL: http://validatorw3org A letöltés időpontja 2005. 07 25 150W3C Logo and Icon Usage. [Elektronikus dokumentum] URL: http://www.w3org/Consortium/Legal/logo-usage-20000308html A letöltés időpontja 2005 07 25. 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ű 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)24 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.: 3214 Ü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: <!-- SGML/XML --> <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 151Source Code Availability for

The W3C Markup Validation Service. [Elektronikus dokumentum.] URL: http://validatorw3org/source/ A letöltés időpontja 2005 07 25 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: <!-- SGML/XML --> <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.25 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: <!-- SGML/XML --> <sortores/> Mivel az SGML nyelvben nem kötelező az üres elemek lezárása26, így a teljesség kedvéért mutatunk harmadik

lehetőséget is – ez értelemszerűen XML-ben nem használható: <!-- SGML/XML --> <sortores> Minimalizálási lehetőségek 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 152W3C Link Checker. [Honlap] URL:

http://validatorw3org/checklink A letöltés időpontja 2005. 07 25 153HTML Tidy Project Page. [Honlap] URL: http://tidysourceforgenet/ A letöltés időpontja 2005. 07 25 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: <!-- SGML/XML --> <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. 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.</> </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! 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.27 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: <!-- SGML/XML --> <kep filenev=”images/neumann.160x200png” hely=”jobb”> 154Clean up your Web pages with HTML TIDY. [Elektronikus dokumentum] URL: http://www.w3org/People/Raggett/tidy/ A letöltés időpontja 2005 07 25 <kepleiras>Neumann János arcképe</kepleiras> </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/XMLben 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: <!-- SGML/XML --> <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 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 token28, 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: 155Web Accessibility Initiative (WAI). [Honlap] URL: http://wwww3org/WAI/ A letöltés időpontja 2005. 07 25 <!-- XML --> <bekezdes xml:lang=”x-hungarian”>Egyéni attribútumérték.</bekezdes> 3. Lehet az érték IANA-nál29 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ákat30 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: 156Kézikönyv a minőségi elvekről (ford.: BÁRÁNY Barbara) Bp: OSZK – MEK, 2004 [Elektronikus dokumentum.] URL: http://mekoszkhu/minerva/html/dok/minoseg-10elvhtm A letöltés időpontja: 2005. 07 26 157Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 [Elektronikus dokumentum.] URL: http://wwww3org/TR/WAI-WEBCONTENT/full-checklisthtml A letöltés időpontja 2005. 07 25 <!-- SGML/XML --> ”.” <resz tipus="fejezet"><fejresz><cim tipus="cim1">Névadónk, Neumann János</cim></fejresz> ”.” <!-- SGML/XML --> ”.” <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”> / -------| 0 0 || o | | --- | ------</bekezdes> Fix szélességű betűtípussal, pl. Courier New tökéletes a megjelenítés: / -------| 0 0 || 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: / -------| 0 0 || 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: <!-- SGML/XML --> <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: &quot;, 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: <!-- SGML/XML --> <lista tipus="lower alpha"> <!-- SGML/XML --> <lista tipus="lower alpha"> 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 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.31 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”: <!-- SGML/XML --> A &DIA; program kortárs szerzők életművét dolgozza fel. 158Evaluation, Repair, and Transformation Tools for Web Content Accessibility. [Elektronikus

dokumentum.] URL: http://wwww3org/WAI/ER/existingtoolshtml A letöltés időpontja 2005 07. 25 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: <!-- SGML/XML --> ”.” <szerzo>Pet&otilde;fi S&aacute;ndor</szerzo> <cim>M&eacute;z &eacute;s cs&oacute;k</cim> <versszak> <sor>Kis m&eacute;h! te a f&uuml;vet,

f&aacute;t,</sor> <sor>S vir&aacute;gokat leped,</sor> <sor>Hogy &eacute;des kelyheikb&otilde;l</sor> <sor>Gy&uuml;jthessed m&eacute;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 ASCII32 karaktert jelöl. Az &#65; például a nagy „A” betűre való hivatkozás Amennyiben az érték 0 és 255 közé esik, úgy kiterjesztett ASCII-készletről – ISO 8859-1 (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 ű <!-- SGML/XML --> Példa decimális hivatkozások használatára. P&#233;lda decim&#225;lis hivatkoz&#225;sok

haszn&#225;lat&#225;ra. Jól látszik, hogy amíg az &#233; hivatkozás „é”, addig az &#255; „á” 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 65535 közé eső számértékekhez tartozó Unicode33 – ISO 10646 – készletet kell igénybe vennünk: <!-- SGML/XML --> Könnyű bőbeszédűen írni a szövegjelölésről. K&#246;nny&#369; b&#337;besz&#233;d&#369;en &#237;rni a sz&#246;vegjel&#246;l&#233;sr&#337;l. 159Bobby – Web Accessibility Testing. [Elektronikus dokumentum] URL: http://www.watchfirecom/products/desktop/bobby/defaultaspx A letöltés időpontja 2005 07 25 160Watchfire WebXACT. [Honlap] URL: http://webxactwatchfirecom/ A letöltés időpontja: 2005. 07 26 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: <!-- SGML/XML --> Tr&#38;#252;kk az &#38;#250;jb&#38;#243;li elemz&#38;#233;shez. Mindez azt eredményezi, hogy első elemzés esetén csak az „és” jelek jönnek létre a karakterhivatkozásokból &#38; -> & – létrehozva ezzel az ékezetes karakterek hivatkozásait. Ezek viszont már kizárólag újbóli elemzés során lesznek értelmezve: <!-- SGML/XML --> Tr&#252;kk az &#250;jb&#243;li elemz&#233;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 09-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. &#x00E1; vagy &#xE1; á á 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 Unicode34 karakterre hivatkozhatunk, például: ő - &#x0151; ű - &#x0171;. <!-- SGML/XML --> Példa hexadecimális hivatkozások használatára. P&#x00E9;lda hexadecim&#x00E1;lis hivatkoz&#x00E1;sok haszn&#x00E1;lat&#x00E1;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. <!-- SGML/XML --> <bekezdes>A &lt;bekezdes&gt; elemek között használhatunk &lt;kiemeles&gt; elemeket is.</bekezdes> A <bekezdes> elemek között használhatunk <kiemeles> elemeket is. Az SGML/XML nyelvben az „&lt;” (kisebb mint – less than) entitásnév jelöli a „<” karaktert, és a „&gt;” (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 &amp; (és –

ampersand) karakterhivatkozást kell használni: <!-- SGML/XML --> 82Netán a Neumann-ház többéves, a TEI alapú szövegfeldolgozás területén szerzett tapasztalatára. <cim>SGML &amp; 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 &quot; entitással helyettesíthető. Összefoglalva tehát:  &lt; a „<” helyett – decimális ASCII kódja: &#60;  &gt; a „>” helyett – decimális ASCII kódja: &#62;  &amp; az „&” helyett – decimális ASCII kódja: &#38;  &apos; a „’” helyett (attribútum-értékekben) – decimális ASCII kódja: &#39;  &quot; a „”” helyett

(attribútum-értékekben) – decimális ASCII kódja: &#34;. 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. 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: <!-- SGML/XML --> <!-- 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. II. A kettes számrendszer alkalmazása. 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. „&gt;”, „&lt;”, „&amp;” 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: <!-- SGML/XML --> Szövegszerkesztőkben az &lt;&lt;&lt;ENTER&gt;&gt;&gt; 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 CDATAszakaszoknak.35 A CDATA-szakasz kezdetét a „<![CDATA[” karaktersorozat jelzi, 83KIRÁLY Péter: Kritikai kiadás és XML. [Elektronikus dokumentum] URL: http://php.arcanumhu/xsl/editXMLhtm A letöltés időpontja 2005 07 06 végéről pedig a „]]>” karakterek gondoskodnak.36 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: <!-- SGML/XML --> &lt;![CDATA[Szövegszerkesztőkben az <<<ENTER>>> billentyű 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: <!-- SGML/XML --> &lt;![CDATA[Az &lt;, &gt;, &amp; stb. vezérlőkódok a kimeneti állományban is ugyanezt a formát öltik.]]--> Az &lt;, &gt;, &amp; 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-ás37 változatot támogatják, ezért mindig ezt a verziószámot adjuk meg a deklarációban: <!-- XML --> <?xml version=”1.0” ?> 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-8859-2 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-838: <!-- XML --> <?xml version=”1.0” encoding=”iso-8859-2” ?> 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

XML-deklarációról, tehát az SGML állományok soha nem ilyen utasítással kezdődnek, hanem ún. dokumentumtípus-deklarációval! 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=”1.0” ?> <!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.: <!-- SGML/XML --> <!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: <!-- SGML/XML --> <!DOCTYPE dokumentum SYSTEM . > vagy <!DOCTYPE dokumentum PUBLIC . > Negyedikként a külső-azonosító kap helyet, ami SYSTEM kulcsszónál egy URI-t39 takar, PUBLIC használatakor pedig valamilyen publikus azonosítót és egy URI-t: <!-- SGML/XML --> <!DOCTYPE dokumentum SYSTEM ”dokumentum.dtd” > <!DOCTYPE dokumentum PUBLIC ”-//NEUMANN//DTD DigLib.TEIP4DTD//HU” ”http://www.neumann-hazhu/dtd/tei2dtd” > 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 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. A DTD-k szerkezeti felépítése Tartalom A DTD-kről általában Elem-típus deklarációk Attribútum-lista deklarációk Entitás deklarációk NOTATION deklarációk 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!40 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. 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.41 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; o ELEMENT – elem-típus deklarációk (element type declaration); o ATTLIST – attribútum-lista deklarációk (attribute-list declaration); o ENTITY – entitás deklarációk (entity declaration); o NOTATION – adatformátum deklarációk (notation declaration); o 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)> Ugyanez SGML-hez készült DTD-nél: <!kulcsszó név minimalizálási szabályok (tartalmi modell)> 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 <!ELEMENT vers <!ELEMENT szerzo <!ELEMENT cim (vers+) > (szerzo?, cim?, versszak+) > (#PCDATA) > (#PCDATA) > <!ELEMENT versszak <!ELEMENT sor (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 <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT --> antologia vers szerzo cim versszak sor - O O O O O (vers+) > (szerzo?, cim?, versszak+) >

(#PCDATA) > (#PCDATA) > (sor+) > (#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: <!-- 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: <!-- SGML/XML --> <!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: <!-- SGML/XML --> <!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;  ? (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, 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: <!-- SGML/XML --> <!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útumlistá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: SGML XML Értelmezés Az attribútum csak karakteres adat lehet. Ezt az CDATA CDATA 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ó. Több entitást is meg lehet adni referenciaként. Az ENTITIES ENTITIES 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. Az attribútum referenciát tartalmaz egy ID-re, mely IDREF IDREF 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. Az attribútum értéke lehet bármilyen szó vagy NAME NMTOKEN lexikális elem – szám, betű, írásjelek (kötőjel, kettőspont, aláhúzásjel). NAMES NMTOKENS NMTOKEN NMTOKEN NMTOKENS NMTOKENS NUMBER NMTOKEN NUMBERS NMTOKENS NUTOKEN NMTOKEN NUTOKENS NMTOKENS Egymástól szóközzel elválasztott NMTOKEN értékek listája. Az attribútum értéke egy NOTATION adattípus, NOTATION NOTATION melynek deklarációja a DTD egy másik pontján helyezkedik el. A lehetséges értékek egy listáját tartalmazza. A listát zárójelek közt kell elhelyezni, ahol az adatok Felsorolás Felsorolás függőleges vonallal vannak elválasztva egymástól. A konkrét érték mindig a felsorolás valamelyik eleme kell, hogy legyen. 1. táblázat - Kulcsszavak SGML/XML-ben 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;42 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: <!-- SGML/XML --> <!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 43. Attribútum-minimalizálás 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:44 <!-- SGML --> <!ELEMENT bekezdes (.tartalmi modell helye)> <!ATTLIST bekezdes fuggo NUMBER 0 behuzas (5|10|15) #IMPLIED> ”.” <bekezdes fuggo=10 behuzas=5> ”.” </bekezdes> <!-- XML --> <!ELEMENT bekezdes (.tartalmi modell helye)> <!ATTLIST bekezdes fuggo NMTOKEN "0" behuzas

(5 | 10 | 15) #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.45 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> [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.] 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; o belső entitás-deklarációval megadott entitások; o 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. <!-- SGML/XML --> <!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: „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: <!-- SGML/XML --> <!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: <!-- SGML/XML --> <!ENTITY egyedek SYSTEM "http://www.w3schoolscom/entities/entitiesxml"> Ö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 DTD-n 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: <!-- SGML/XML --> <!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 ( 8 | 10 | 12 | 14 | 18 | 24 | 36) #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 NUMBER-re 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 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: <!-- SGML/XML --> <!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 50.000 $” 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:46  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 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.47  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.48 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: <!-- SGML/XML --> Ezekben az esetekben a bank megtéríti az ügyfél kárát. <![ IGNORE [A felelősség felső határa 50.000 dollár]]&gt; 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é: <!-- SGML/XML --> Ezekben az esetekben a bank megtéríti az ügyfél kárát. <![ %Maryland; [A felelősség felső határa 50.000 dollár]]&gt; 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: <!-- SGML/XML --> <!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: <!-- SGML/XML --> ”.” <!ENTITY % NEUMANN.bevitel "INCLUDE"> <![ %NEUMANN.bevitel; [ <!-- Ide <!ENTITY <!ENTITY <!ENTITY <!ENTITY <!ENTITY "." kerülnek az egyes elemek paraméter entitásai. % bekezdes "INCLUDE"> % sortores "INCLUDE"> % kiemeles "INCLUDE"> % lista

"INCLUDE"> % listaelem "INCLUDE"> --> A deklaráció hatására minden olyan megjelölt rész, amely a NEUMANN.bevitel-lel kapcsolatos, bekerül a DTD-be – 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;> ]]&gt; 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: <!-- SGML/XML --> ”.” <!NOTATION PNG SYSTEM ”/usr/bin/display”> <!ENTITY nemzetimuz SYSTEM ”http://biro:8888/~biro/kepek/nemzetimuz.png” NDATA PNG> ”.” ”.” <kep entity=”nemzetimuz” hely=”kozep”> <kepleiras>Magyar nemzeti Múzeum</kepleiras> </kep> ”.” 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: <!-- SGML/XML --> ”.” <!NOTATION BMP PUBLIC "+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION Microsoft Windows Bitmap//EN"> <!ENTITY vetitogep SYSTEM ”./kepek/vetitogepbmp” 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] Szövegjelölés TEI DTD alapján Tartalom TEI A TEI alapelvei és előnyei A TEI felépítése A TEI

jövője 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. TEI A TEI49 (Text Encoding Initiative - Szövegkódolási Kezdeményezés) fontos nemzetközi projekt, amelyet 1987-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ípus-deklará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 DTD-nek az SGML

mellett egyaránt létezik XML és XML Schema változata. Jelenleg a TEI P5-ös verzióján dolgoznak a szakemberek50, 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 Lite51, 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”52, 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 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.53 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.54 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.55 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őelem- ké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íteni56 – 1987-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; <!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.namesdates – 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écet57, 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> 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: <!-- SGML/XML --> ”.” <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: <!-- 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 (18251904)</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">963 00 7857 3</idno> <availability> <p>Copyright 1964, Akadémiai Kiadó</p> </availability> <distributor>Neumannház</distributor> <address> <addrLine>Budapest</addrLine> <addrLine>Színház utca 13.</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, hogy a tényleges szövegeket nem mondhatják magukénak.58 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. MARC59, Dublin Core, Qualified Dublin Core60 stb Gondoljunk csak bele, hogy így gyakorlatilag bármilyen szabványhoz igazodva XMLben á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 P561 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: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <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> ”.” 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.62 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ó63 –, 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: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <back> <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.64 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.65 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: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <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. 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 XSLFO66 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="http://www.w3org/XSL/Format"> ”.” <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: <!-- SGML/XML --> <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: <!-- SGML/XML --> ”.” <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. 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ása67 a lépcsős stíluslapok ajánlásának listákhoz kapcsolódó értékkészletéből68: <!-- SGML/XML --> ”.” <!ENTITY % list INCLUDE > <![ %list; [ <!ELEMENT %n.list; ””> <!ATTLIST %n.list;

%tei.globalattributes; type CDATA "simple" TEIform CDATA list > ]]&gt; ”.” <!-- SGML/XML --> ”.” <!ENTITY % list INCLUDE > <![ %list; [ <!ELEMENT %n.list; ””> <!ATTLIST %n.list; %tei.globalattributes; type (none | disc | simple | decimal | lower-alpha | upper-roman) ”simple” TEIform CDATA list > ]]&gt; ”.” 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: <!-- SGML/XML --> ”.” <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”): <!-- SGML/XML --> ”.” <list type=”disc”>

<!-- vagy --> <list> <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: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <list type="lower-alpha"> <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!69 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 TEIP4DTD//HU"

"http://biro:8888/~biro/test/dtd/TEI-P4/tei2.dtd" [ <!NOTATION html PUBLIC -//W3C//NOTATION HTML 4.0 Transitional//EN> <!ENTITY BHIorokzene SYSTEM "http://www.neumann-hazhu/scripts /webkat?infile=virt keret.html&amp;oid=43118&amp; dok=http://www.neumannhazhu/scripts/SGML/BHISGMLtr?juhaszgy/juhaszgy0429sgml" NDATA html> <!ENTITY Neumann-honlap SYSTEM "http://www.neumann-hazhu" 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 P5ben, NOTATION és külső entitás-hivatkozások nélkül: <!-- TEI P5 XML --> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE TEI PUBLIC "-//TEI P5//DTD Main Document Type//EN"

"http://biro:8888/~biro/test/dtd/TEI-P5/schema/dtd/p5/tei2.dtd" [ <!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="http://www.neumannhazhu/scripts/webkat?infile=virt kerethtml &amp;oid=43118&amp;dok=http://www.neumann-hazhu/scripts/ SGML/BHISGMLtr?juhaszgy/juhaszgy0429.sgml">A vers a BHIban</ref> <lb/> <ref target="http://www.neumann-hazhu">A 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éterentitá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.70 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: <!-- SGML/XML --> ”.” <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> ”.” 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.71 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 TEIP4DTD//HU" "http://biro:8888/~biro/test/dtd/TEI-P4/tei2.dtd" [ <!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őelemet72: <!-- TEI P5 XML --> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE TEI PUBLIC "-//TEI P5//DTD Main Document Type//EN"

"http://biro:8888/~biro/test/dtd/TEI-P5/schema/dtd/p5/tei2.dtd" [ <!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> ”.” <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.)73 [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" "http://biro:8888/~biro/test/dtd/TEI-P5/schema/dtd/p5/tei2.dtd" [ <!NOTATION TeX PUBLIC -//Donald E. Knuth 1983//NOTATION TeX Mathematical Markup//EN>

<!ENTITY <!ENTITY <!ENTITY <!ENTITY <!ENTITY <!ENTITY <!ENTITY % % % % % % % TEI.core INCLUDE > TEI.header INCLUDE > TEI.textstructure INCLUDE > TEI.mixed INCLUDE > TEI.figures INCLUDE > TEI.linking INCLUDE > TEI.graphics "INCLUDE"> ]> <TEI> ”.” <p>Itt egy példát láthatunk TeX kódra: <formula notation="TeX">$$ {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 20-ás ajánlásának második kiadása 2003. októberében

jelent meg74 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.75 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" "http://biro:8888/~biro/test/dtd/TEI-P5/schema/dtd/p5/tei2.dtd" [ <!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> </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.76 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álja77 é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.]78 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át79 – 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.80 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 vannak81, 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 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őre82 – is szükségünk van! Feltéve ha mi magunk nem vagyunk azok83 Szövegjelölés DocBook DTD alapján Tartalom DocBook A DocBook előnyei A DocBook felépítése A DocBook jövője A szövegfeldolgozás területének másik nagy, nemzetközileg elismert jelölésrendszere a DocBook84 á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. DocBook A DocBook dokumentumtípust több mint tíz évvel ezelőtt a HaL Computer Systems és az OReilly & 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 OASIS85 (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 V4586-ö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 TEIt megközelítő számú – több, mint 300 – elemmel rendelkezik87 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. A DocBook felépítése 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.88 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 stb89  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> 90 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: <!-- SGML/XML --> ”.” <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>, <email> 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: <!--

SGML/XML --> ”.” <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> <email>pkiszl@ludens.eltehu</email> </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: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <biblioid>ISBN 963 389 565 0</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: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <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. <!-- SGML/XML --> ”.” <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: <!-- XML --> <?xml version="1.0" encoding="utf-8" standalone=”no”?> <!DOCTYPE book PUBLIC "-//EDUCATIO Kht.//DocBook V43-alapu DTD V1.1//HU" "http://www.hikhu/tankonyvpalyazat/dtd2/tankonyvdtd"> <book lang="hu"> <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 963 218 740 7</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 A DocBook dokumentum gyökere a <book> 91 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> 92, az előszó <preface> 93 kap helyet, majd ezt követik a könyv egyes fejezetei

<chapter> 94. A bibliográfia a <bibliography> 95, a függelék az <appendix> 96, a tárgymutató pedig az <index> 97 elemben kell, hogy szerepeljen. Az egyes szerkezeti egységekhez tartozó címeket a <title> jelölővel kell ellátni: <!-- SGML/XML --> <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: <!-- SGML/XML --> ”.” <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 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ékgenerá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> 98 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> 99 azzal a megkötéssel használható, hogy nem

tartalmazhat további bekezdésszintű – blokként megjelenített – elemeket, pl. listákat A <formalpara> 100 olyan bekezdést jelöl, melynek kötelezően címet <title> is adunk. <!-- SGML/XML --> ”.” <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> 101 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: <!-- SGML/XML --> "." <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: <!-- SGML/XML --> <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 <superscript>2</superscript>.</para> A víz képlete H2O. Matematikában az a2+b2=c2. Á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> 102 jelölő fogja közre, az egyes listaelemek pedig <member> elemek közé kerülnek. Szimbólum nélküli lista: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <itemizedlist mark="disc"> <listitem><para>listaelem</para></listitem> <listitem><para>listaelem</para></listitem> <listitem><para>listaelem</para></listitem> </itemizedlist> ”.”  listaelem  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útumlistá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: <!-- SGML/XML --> ”.” <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: <!-- SGML/XML --> ”.” <ulink url="http://www.hikhu/">A 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: <!-- SGML/XML --> ”.” <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> 103 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: <!-- SGML/XML --> ”.” <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> ”.” 11 24 39 A bonyolultabb táblázatok, melyek összevont cellákat, táblafejet, címet tartalmaznak, a <table> 104 elemmel hozhatók létre: <!-- SGML/XML --> ”.” <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> ”.” f1 b1 c1 d1 Vízszintes cellaösszevonás f2 b2 a3 f3 b3 a4 a5 f4 f5 b4 Függőleges

cellaösszevonás c4 Több sort és oszlopot átfogó cella d4 d5 1. táblázat - Bonyolult táblázat 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 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> 105 elemmel jelöljük: <!-- SGML/XML --> ”.” <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> 106 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 V42-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. DocBook-ban 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>107 – blokként formázott egyenlet;  <inlineequation>108 – szövegen belüli egyenlet; (ha grafikus objektumot tartalmaz, azt az <inlinemediaobject> használatával adjuk meg.)  <informalequation>109 – kevésbé részletezett formában megadott (általában cím nélküli) egyenlet; <!-- XML --> ”.” <informalequation> <mml:math> <mml:mrow> <mml:mo>&sum;</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.110 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. <!-- SGML/XML --> ”.” <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> ”.” 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> 111 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ó: <!-- SGML/XML --> ”.” <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="http://www.tankonyvtarhu">Ez 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: <!-- SGML/XML --> ”.” <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">: <!-- SGML/XML --> ”.” <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 <!-- SGML/XML --> ”.” <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)112 implementálta Felsőoktatási Digitális Tankönyvtárához (KFFDT)113, tehát hazai viszonylatban ők rendelkeznek a legnagyobb tapasztalattal ennek alkalmazásában.] A megjelenítésről általában Tartalom Röviden a megjelenítésről Stílusorientált szolgáltatási formátumok (X)HTML PDF RTF Stíluslapnyelvek DSSSL CSS XSL 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 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: <!-- SGML/XML --> <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! 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 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íz-hú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! (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! 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.114 Belenézve egy PDF forrásába, találhatunk értelmezhető, jelölt részeket: %PDF-1.4 . <</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:20050217091157)>>>>

/LastModified(D:20050217091157)/MarkInfo<</Marked true/LetterspaceFlags 0>>>> endobj 311 0 obj<</Type/OCG/Name(HeaderFooter)/Usage<</CreatorInfo <</Creator(Acrobat PDFMaker 6.0 for Word)>>/PageElement<</SubType/HF>>>>>> 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 vektorosnak115, nem konvertálja őket pixelgrafikussá116, 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 Reader117 szükséges: Dokumentum az Adobe Reader 7.01-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: Formanyelvek { tf1ansiansicpg1250uc1deff0stshfdbch0stshfloch0 stshfhich0stshfbi0deflang1038deflangfe1038{fonttbl{f0 fromanfcharset238fprq2{*panose 02020603050405020304}Times New Roman;}{f38fromanfcharset0fprq2 Times New Roman;} . {*generator Microsoft Word 10.02627;}{info{ itle Formanyelvek}{author Szabolcs Bedrf3}{operator Szabolcs Bedrf3}{creatimyr2005mo4dy28hr19min50}{ evtimyr2005 mo4dy28hr19min51}{version1}{edmins1}{ ofpages1}{ ofwords2 } { ofchars17}{*company Neumann Kht.} { ofcharsws18}{vern16437}}paperw11906paperh16838margl1417ma rgr1 . {insrsid4980766 Formanyelvek}{insrsid1248861 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 97-2000 és 60-95) – 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: { tf1ansideff0adeflang1025 {fonttbl{f0fromanfprq2fcharset238 Times New Roman;} . } {info{author Szabolcs Bedrf3}{creatimyr2005mo4 dy28hr16min5}{operator Szabolcs Bedrf3}{ evtimyr2005 mo4dy28hr16min6}{printimyr1601mo1dy1hr0min0}{comment StarWriter}{vern6450}}deftab709 . {lochf0fs24lang1033i00 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. Jelenleg az RTF 1.6-os specifikációja118 a legújabb, ezt 1999 májusában bocsátotta ki a Microsoft Corporation. Alternatív megjelenítési formátumként érdemes szolgáltatni 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ámogatja119, ráadásul sokszor a potenciális alkalmazói körök is kerülik, mivel szintaxisa szintén nem olyan egyszerű: <!-- SGML/XML --> <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.120 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 szovegfeldxml 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ógusra121 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 CSS-sel „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 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)122 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 fontweight=”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)123 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 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 CSSné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: <!-- SGML/XML --> <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="font-style: italic;"). Sőt, hogy ne legyen olyan egyszerű a dolgunk, minden sablon esetén társul ezekhez XPath 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ő.124 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: <!-- SGML/XML --> <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ű XML2XML125 á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 .inxalanjar;inxml-apisjar;inxercesImpljar org.apachexalanxsltProcess -IN pelda.xml -XSL peldaxsl -XML -OUT peldafo 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ó XEP126, mely a RenderX terméke, vagy a szabad forrású FOP127, 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 peldapdf 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őbb-utó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. Az XHTML Tartalom 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 WAI tippek – akadálymentesítés 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. 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 – 10, 20, 30, 32, 40, 401 – 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 1999. december 24-én, a HTML 401 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.128 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 11 (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) 2005. május 27-én adta ki az XHTML 20 legújabb – hetedik – munkatervét Az XHTML 2.0 a web ismert leírónyelveinek – HTML 401, XHTML 10 és 11 – rokona, de nem szándékozik felülről kompatibilis maradni azokkal. A munkaterv az XHTML 20 leírónyelvet és moduljait írja le, amelyek célja látványos, hordozható web-alapú alkalmazások létrehozása.129] 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 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.130 [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 HTMLné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 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.131 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.132  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 XHTML-konform 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ő XHTMLkonform modulokhoz. Mindezek az XHTML Modularizáció specifikációban133 vannak részletezve. Ezek a modulok lehetővé teszik a létező és új

tulajdonságkészletek kombinációját a tartalomfejlesztés és böngészőtervezés során. 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ípusdefiní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 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3org/TR/xhtml1/DTD/xhtml1-strictdtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3org/TR/xhtml1/DTD/xhtml1-transitionaldtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3org/TR/xhtml1/DTD/xhtml1-framesetdtd"> XHTML 1.1 esetén <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3org/TR/xhtml11/DTD/xhtml11dtd"> 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!] 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-8859-2"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3org/TR/xhtml1/DTD/xhtml1-strictdtd"> <html xmlns="http://www.w3org/1999/xhtml" xml:lang="hu" lang="hu"> <head> <title>8. Az XHTML</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" /> <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="http://www.w3org/1999/xhtml" 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ímen134 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 1.06-ban 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.135 Elsősorban ez vezetett azokhoz a struktúrájukban 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ás-fejlesztő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)]136 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="http://purlorg/dc/elements/11/" /> <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="2002-09-09" /> <meta name="DC.identifier" content="http://dublincore.org/documents/dcq-html" /> <link rel="DC.relation" href="http://dublincore.org/documents/2000/08/15/dcq-html" /> <meta name="DC.description" content="This document describes how qualified Dublin Core metadata can be encoded in HTML/XHTML &lt;meta&gt; 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 dokumentumnak137 minősített változata is létezik, amelyet a következő példa szemléltet: <!-- XHTML --> ”.” <head> ”.” <link rel="schema.DC" href="http://purlorg/dc/elements/11/" /> <link rel="schema.DCTERMS" href="http://purlorg/dc/terms/" /> <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="DCTERMSW3CDTF" content="2003-11-01" /> <meta name="DC.identifier" scheme="DCTERMSURI" content="http://dublincore.org/documents/dcq-html/" /> <link rel="DCTERMS.replaces" hreflang="en" href="http://dublincore.org/documents/2000/08/15/dcq-html/" /> <meta name="DCTERMS.abstract" content="This document describes how qualified Dublin Core metadata can be encoded in HTML/XHTML &lt;meta&gt; elements" /> <meta name="DC.format" scheme="DCTERMSIMT" content="text/html" /> <meta name="DC.type" scheme="DCTERMSDCMIType" 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="http://purlorg/dc/elements/11/" /> Minősített DC használatánál: <link rel="schema.DCTERMS" href="http://purlorg/dc/terms/" /> A meghatározott névterek tulajdonképpen XML alapú RDF138 á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: <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-dot139 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. XHTML szabályok Noha az XHTML 1.0 ugyanazt az elemkészletet tartalmazza, mint a HTML 401-es verziója, az elemek használatának módja jelentős mértékben megszigorodott. Az ok egyszerű. Míg a HTML 401 valójában SGML-alkalmazá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 XHTMLnek 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 401 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: <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 10-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. ]]&gt; </script> 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 &#X00C9; Helyes: Pl. É betű esetén &#x00c9; 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: Content-Type: text/html; charset=iso-8859-2 2. 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=iso8859-2" /> 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-8859-1 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.] 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-8859-2"?> <!DOCTYPE math PUBLIC "-//W3C//DTD MathML 2.0//EN"

"http://www.w3org/TR/MathML2/dtd/mathml2dtd"> <math xmlns="http://www.w3org/1998/Math/MathML"> <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> a2+b2=c2 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 "http://www.w3org/Math/DTD/mathml1/mathmldtd"> MathML 2.0 esetén: <!DOCTYPE math PUBLIC "-//W3C//DTD MathML 2.0//EN" "http://www.w3org/TR/MathML2/dtd/mathml2dtd"> 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 XHTML-né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ímen140 található meg: <math xmlns="http://www.w3org/1998/Math/MathML"> 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, Amaya141 – 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 106-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-8859-2"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 20//EN" "http://www.w3org/TR/MathML2/dtd/xhtml-math11-fdtd"> <html xmlns="http://www.w3org/1999/xhtml"> <head> <title>MathML kód XHTML-ben</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" /> <meta http-equiv="Content-Style-Type" content="text/css" /> <style type="text/css"></style> </head> <body> <math xmlns="http://www.w3org/1998/Math/MathML"> <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 20-s DTD-jét: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 20//EN" "http://www.w3org/TR/MathML2/dtd/xhtml-math11-fdtd"> 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 – mathmlxhtml – é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 fontok142 letöltésére, illetve telepítésére is.] A mathml.xhtml állomány képletei Firefox 106-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 mathmlhtml-re és a következő végeredményt kaptuk: A mathml.html állomány képletei Firefox 106-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. 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 SVG143 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" "http://www.w3org/TR/2001/REC-SVG-20010904/DTD/svg10dtd"> SVG 1.1 esetén: <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3org/Graphics/SVG/11/DTD/svg11dtd"> SVG 1.1 Basic esetén: <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1 Basic//EN" "http://www.w3org/Graphics/SVG/11/DTD/svg11-basicdtd"> SVG 1.1 Tiny esetén: <!DOCTYPE svg PUBLIC

"-//W3C//DTD SVG 1.1 Tiny//EN" "http://www.w3org/Graphics/SVG/11/DTD/svg11-tinydtd"> 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="0 0 1200 400" xmlns="http://www.w3org/2000/svg"> 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-t144 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" "http://www.w3org/Graphics/SVG/11/DTD/svg11dtd"> <svg version="1.1" xmlns=http://www.w3org/2000/svg width="12cm" height="4cm" viewBox="0 0 1200 400"> <desc>T&#x00E9;glalap &#x00E9;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&#x00E1;ki Vir&#x00E1;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 svgsvg 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 60-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ő.145 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> 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 MIME146 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 20 és az SVG 11 közös DTD-jére való hivatkozás: <!DOCTYPE

html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 20 plus SVG 11//EN" "http://www.w3org/2002/04/xhtml-math-svg/xhtml-math-svgdtd"> 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-8859-2"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 20 plus SVG 11//EN" "http://www.w3org/2002/04/xhtml-math-svg/xhtml-math-svgdtd"> <html xmlns="http://www.w3org/1999/xhtml"> <head> <title>MathML és SVG kód XHTML-ben</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" /> <meta http-equiv="Content-Style-Type" content="text/css" /> <style type="text/css"></style>

</head> <body> <math xmlns="http://www.w3org/1998/Math/MathML"> <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> <svg:svg version="1.1" xmlns:svg="http://www.w3org/2000/svg" width="12cm" height="4cm" viewBox="0 0 1200 400"> <svg:desc>T&#x00E9;glalap &#x00E9;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&#x00E1;ki Vir&#x00E1;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 2147-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 148

á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: XHTML-be ágyazott MathML és SVG forrás helyes megjelenése a Deer Park Alpha 2 1.0+-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. 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.149 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.70-á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 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:150 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.70) 2005 augusztus 8-án vált elérhetővé –, bárki részt vehet fejlesztésében és letöltheti forráskódját.151 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.70-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 (http://www.htmlhelpcom/tools/validator/);  Doctor HTML (http://www.doctor- html.com/RxHTML/cgi-bin/singlecgi);  CSE HTML Validator Online Check (http://www.htmlvalidatorcom); W3C Link Checker A honlapokon szereplő linkek és ugrópontok ellenőrzésére hasznos és egyszerű eszköz a W3C Link Checker152, 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ó.153 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.154 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.] 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)155 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.156 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. 10-15 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 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.157 Ezeket a szoftvereket, melyek felsorolása megtalálható a W3C honlapján158, minden kulturális intézménynek célszerű használnia. A példák között említhető a Watchfire Corporation, Bobby159

nevet viselő teszt eszköze, mely a WAI irányelvek szerint ellenőrzi a weboldalakat. A program az 50-s verziótól sajnos már nem ingyenes, helyette viszont egyszerű oldalakhoz alkalmazható a Watchfire WebXACT160 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. Lépcsős stíluslapok – CSS Tartalom 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 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 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 10-s ajánlásával foglalkozik161, 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. 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. 1995-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.162 Í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 10163 – 1996 december 17-én, annak felülvizsgált verziója pedig 1999. január 11-én jelent meg A CSS 20164 1998 május 12-én vált ajánlássá, jelenleg ennek felülvizsgált, 2.1-es165

verziója munkapéldány, sőt már a 30-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.166 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 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. 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-8859-2"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0

Strict//EN" "http://www.w3org/TR/xhtml1/DTD/xhtml1-strictdtd"> <html xmlns="http://www.w3org/1999/xhtml" xml:lang="hu" lang="hu"> <head> <title>9. Lépcsős stíluslapok &ndash; CSS </title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" /> <meta http-equiv="Content-Style-Type" content="text/css" /> <link rel="stylesheet" title="Neumann design" type="text/css" href="neuweb.css" media="screen" />