A könyv az Oktatási Minisztérium támogatásával, az NKTH által lebonyolított Felsőoktatási Tankönyv- és Szakkönyv-támogatási Pályázat keretében jelent meg. Az elektronikus kiadás DocBook XML formátumát Bíró Szabolcs készítette. Copyright © 2005 Neumann Kht. Copyright © 2005 Bíró Szabolcs
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
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.
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:
Átírtam az XSL lapot. Így most szebb lett a HTML kimenet.
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
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-k11 , nem utolsó sorban pedig azok felhasználói, egyre jobban „megkövetelik”, hogy digitalizált dokumentumaink többféle formátumban elérhetővé váljanak számukra. Ennek hatékony, gyors és korszerű megvalósítása azonban több okból sem egyszerű feladat, hiszen sok digitalizálással, szövegfeldolgozással foglalkozni akaró „szakember” még az adattárolási, illetve 1128XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition). What is XHTML? [Elektronikus dokumentum.] URL: http://www.w3.org/TR/xhtml1/#xhtml. A letöltés időpontja 2005. 07. 25.
megjelenítési formátumok közti különbségekkel sincs tisztában.2 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
2129W3C hírek – Archívum. [Elektronikus dokumentum.] URL: http://www.w3c.hu/archivum/2002/w3cnews.html. A letöltés időpontja 2005. 07. 25.
szolgáltatása33 – 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”44 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; 3130RAGETT, 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.w3.org/QA/2002/04/Web-Quality. A letöltés időpontja 2005. 07. 25. 4131BATES, 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”55 nevet viseli. A könyv elsősorban ezen és Neil BRADLEY XML kézikönyvén66 alapul – bővebben az Irodalomjeyzékből lehet tájékozódni.
5132DOM – 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. 6133Modularization of XHTML™. [Elektronikus dokumentum.] URL: http://www.w3.org/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ó.
Gyakran előfordul, hogy a példák bizonyos részeit félkövéren kiemeltük, például:
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.77 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 ekö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.7.5 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?
7134XHTML namespace. [Elektronikus dokumentum.] URL: http://www.w3.org/1999/xhtml. A letöltés időpontja 2005. 07. 25.
Ékezethelyesen kapják-e meg a szövegeket?88 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-n99 kívül nincs olyan szervezet, amely további fejlődését kizárólagosan befolyásolhatná. Ezzel szemben a PDF az Adobe1 100 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, felhasználási lehetőségeik gyakorlatilag „nullára redukálódhatnak”.1 111 Következésképp 8135SÜ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. 9136KISS Gergő, KOVÁCS László, MICSIK András: HEKTÁR: Hazai elektronikus könyvtári rendszerek összekapcsolása. [Elektronikus dokumentum.] URL: http://mek.oszk.hu/html/irattar/ajanlas/hektar2004.pdf. A letöltés időpontja 2005. 07. 25. 10137POWELL, Andy: Expressing Dublin Core in HTML/XHTML meta and link elements. [Elektronikus dokumentum.] URL: http://dublincore.org/documents/dcq-html/. A letöltés időpontja 2005. 07. 25. 11138RDF – 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.
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.1122 Az információt annak tartalma, illetve szerkezete alapján jelöli meg, innen származik a jelölőnyelv elnevezés. Tervezésekor az egyik alapvető célkitűzés az volt, hogy az SGML szabályait követő dokumentumok információveszteség nélkül hordozhatók legyenek az eltérő hardver- és szoftverkörnyezetek között.
Az SGML létrejöttének körülményei A nyelv jelenlegi formáját négy különböző kezdeményezés közös eredményeként nyerte el: 1. Az általános kódolás elmélete Kezdetben az elektronikus dokumentumokat alapszintű jelölőkódokkal, ún. makrókkal látták el. A makrók segítségével egyedi formázást tudtak megvalósítani. Később a beiktatott makrókat, melyeket elsősorban csak a feldolgozóprogramok tudtak értelmezni (pl. „format-17”) közérthetőbb jelölőelemekre cserélték le (pl. „heading”). Az 1960-as 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.w3.org/RDF/. A letöltés időpontja 2005. 07. 25. 12139DC-dot Dublin Core Metadata editor. [Honlap.] URL: http://www.ukoln.ac.uk/cgibin/dcdot.pl. A letöltés időpontja 2005. 07. 25.
é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.1133
13140MathML Namespace. [Elektronikus dokumentum.] URL: http://www.w3.org/1998/Math/MathML/. A letöltés időpontja 2005. 07. 29.
Az SGML az 1986-os megjelenését követő 10 évben gyakorlatilag változatlan maradt. Ezzel természetesen lemérhető, hogy kezdetektől fogva milyen erőteljes volt, hiszen egy évtized elteltével is csak kisebb felülvizsgálatokra volt szükség. Sőt megkockáztatjuk, hogy specifikációja talán túl fejlett volt, számos jellemzőjét még ma sem igazán használjuk ki. Fő hátrányát azonban éppen a teljesítménye jelentette, ugyanis még egy, a nyelv valamelyik tipikus részhalmazát támogató szoftver kifejlesztése is hatalmas programozási feladatot jelent. Az SGML-kompatibilis alkalmazások ezért általában lassan készültek el, nem voltak teljesek vagy hibára hajlamosak voltak, ugyanakkor a szabadalmaztatott megoldásokhoz viszonyítva sokba kerültek.
Az SGML lehetséges használati területei A „dokumentálás” módja vagy a „belső információs rendszer” miatt számtalan szervezetnél jelentős összegek tűnhetnek el. Ennek oka, hogy a pénzeket elsősorban olyan feladatokra fordítják, mint a tervezés, az írás, az ellenőrzés, a korrekció, a keresés, a konvertálás, a formázás és a nyomtatás. Ez a folyamat azután minden apróbb termék-, piac- és információváltozásnál újra és újra lejátszódik. A lényeg – ami nem más, mint a munkatársak tapasztalata, tudása és észrevételei, egyszóval az információ, amely magát az intézményt versenyképesebbé és sikeresebbé tehetné – pedig eltűnik. Eltűnik, mert pusztán kiadványok készülnek jól kezelhető információ helyett. Aki adatfeldolgozással foglalkozik, hamar megtapasztalja, hogy az ismeretlen/idegen, nem dokumentált állományok konverziója mennyire időigényes feladat. A nehézség rendkívüli is lehet, ha például az előállító szoftvernek már a gyártója sem létezik. Gondoljunk csak a régi szövegszerkesztő programokkal készült állományokra! Joggal vetődhetnek fel bennünk a kérdések: Mi a jövő, van-e ezekre a problémákra megoldás? Milyen elvárásaink lehetnek? A megoldás már régóta létezik, hiszen mindmáig ezeket a problémákat igyekszik kiküszöbölni az SGML – később látni fogjuk, hogy az XML is –, ami olyan technológia, mely a dokumentumok és a bennük foglalt információ felett korábban nem tapasztalt uralmat nyújt, mégpedig páratlanul széleskörű alkalmazhatósága, illetve eszköz- és rendszerfüggetlensége miatt. Az alábbiakban áttekintjük, hogy elsősorban mely területeken célszerű és hasznos az SGML nyelv használata: 1. Szövegdigitalizálási projektek, programok A fejlett számítástechnikai infrastruktúrájú országokban – elsősorban az USA-ban, Kanadában, Ausztráliában – sok-sok éve folynak szövegdigitalizálási programok. Hazánkban ezek még „gyerekcipőben járnak”, ám észrevehetően egyre nagyobb a
figyelem, az érdeklődés és a tenni akarás a digitalizálás területén, úgy állami, mint intézményi oldalról egyaránt. Többek között éppen ezeknek a fejlesztéseknek az eredményeképpen jött létre közel 20 évvel ezelőtt az SGML szabvány, hiszen a digitalizált szövegek hosszú távú archiválását, visszakeresését és sokoldalú feldolgozását csak ilyen, a hardver- és szoftvereszközöktől független formátum tudja biztosítani. Ha a szövegdigitalizálás egyszerűsített folyamatára gondolunk (papírlap szöveggel), digitalizálás (mentés képként), OCR felismertetés (mentés szövegként), a sor végén rögtön felmerül a kérdés: A „végeredményt” milyen formátumban tároljuk? Melyik ma létező cég formátumát kövessük? (Microsoft: RTF, DOC, Adobe: PDF); Melyik ma létező cég formátumát kövessük? (Microsoft: RTF, DOC, Adobe: PDF); Melyik verziót vegyük alapul? (RTF 1.6, HTML 4.0); Melyik szabványt kövessük? (ISO szabványok, W3C ajánlások); 2. Információkeresés; gépek számára is értelmezhető szövegek Manapság az elektronikus formában tárolt dokumentumokban nagyon nehéz – esetenként lehetetlen – megtalálni a számunkra fontos információkat, mivel az azokat kezelő szoftverek nem képesek értelmezni az ember számára értelmes szöveget. Amíg nincsenek nagy teljesítményű, majdnem emberi intelligenciával rendelkező számítógépeink, addig kénytelenek leszünk valamilyen módon megjelölni a szoftverek számára az információkat. Erre szolgál – többek között – az SGML. Vegyük az alábbi példát: A World Wide Web egyik legnépszerűbb keresőgépét, mondjuk a Google-t szeretnénk használni. Keresőkérdésünk igen egyszerű: meg szeretnénk tudni, hogy mi is az a Jáva. Ennek a szónak napjainkban már két értelmezése is ismert: Jáva – mint sziget, és Jáva – mint programozási nyelv. Milyen eredményeket kapunk, ha csupán az egyszerű „Jáva” szót adjuk meg? A jelöletlen szövegekben a keresőrobot mindkét értelmezést ugyanolyan „értékűnek” tekinti, tehát a találati listában szigetként és nyelvként is előfordul majd a Jáva szó. Jelölve viszont különbséget tud tenni közöttük:
<sziget>Jáva <programozasi_nyelv>Jáva
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: Bíró Szabolcs Cziráki Katalin Virág Telefonhívás Hívj fel ma délután! Szabolcs
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:1 144 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 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 –
14141Az 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://www.w3.org/Amaya/Overview.html. A letöltés időpontja 2005. 07. 29.
névterek1155, sémák1166 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 ASCII1177 szövegformátumon alapuló ember által is olvasható jelölőnyelven alapszik és nem rendelkezik minimalizálási jellemzőkkel – lásd 10. pont –, a cél egyértelműen megvalósult. 7. Az XML-szabvány gyors fejlesztése Az XML tervezésének gyorsan kell végbemennie. Figyelembe véve, hogy a fejlesztés 1996 közepén kezdődött és az XML 1.0 első elfogadott ajánlása 1998 februárjában jelent meg, mindenki eldöntheti, hogy gyors volt-e a munka vagy lassú. Mielőtt döntünk, azért vegyük figyelembe, ennyi idő kell egy új ajánláshoz még akkor is, ha „csak” a már meglévő SGML-t kellett egyszerűsíteni. 8. Formális és tömör tervezés 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
15142Fonts for MathML-enabled Mozilla. [Honlap.] URL: http://www.mozilla.org/projects/mathml/fonts/. A letöltés időpontja 2005. 07. 29. 16143SVG – 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.w3.org/TR/SVG/. A letöltés időpontja 2005. 07. 29. 17144Web Center Features – SVG – Manual Download. [Honlap.] URL: http://www.adobe.com/svg/viewer/install/main.html. A letöltés időpontja 2005. 07. 29.
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 „; ” 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:1 188 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 18145Az 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.
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 vagy 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>..., a lábjegyzeteket pedig ... 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:
költeményei
<szerzo> Petőfi Sándor Petőfi Sándor összes Szépirodalmi Könyvkiadó Budapest <ev>1955
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 (Start Tag Open) = a kezdő jelölőelem nyitó eleme > STAGC (Start Tag Close) = a kezdő jelölőelem záró eleme
>
ETAGC (End Tag Close)
= a befejező jelölőelem záró eleme
A hordozóelemek felépítése A kezdő és a befejező/záró jelölőelem magával a közte lévő szöveggel – elemtartalom – együtt alkotja a hordozóelemet. Pusztán érdekességképp jegyezzük meg, hogy az SGML nyelv lehetőséget biztosít a 2. ábrán bemutatott jelölőelemek – egyébként mindkét nyelvben alapértelmezett – nyitó és záró karaktereinek átdefiniálására. [Megj.: Az átdefiniálás más határérték-beállításokkal együtt rendszerint az sgml.def és a *.dtd állományokban végezhető el.] Ennek eredményeként például egy szövegben szereplő bekezdés a következőképpen is kinézhet: Alapértelmezett elemjelölő karakterek SGML/XML-ben.
//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 , az vagy . Nagyon fontos viszont, hogy egyetlen elemnév sem tartalmazhat ún. whitespace1 199 karaktereket. 19146MIME – 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.
Ha szövegfeldolgozásba kezdünk és saját jelölésrendszert akarunk kialakítani2 200, akkor a következőkre mindenképp oda kell figyelni: 1. Kisbetűk és nagybetűk Mivel az XML elemnevei egyaránt kis- és nagybetű érzékenyek – SGML esetében nincs ilyen –, ezért legnyilvánvalóbb a vagy csupa , vagy csupa 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. ; . 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”; Neumann-ház
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 – WML2 211, OEB2222. A módszer előnye, hogy az egyes elemnevek jelentésével mindenki tisztában van, ráadásul HTML2XML átalakítások2233 és szöveges tartalom beemelések is kevés bajlódással megoldhatók. 4. Elemnévhossz 20147A 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 1.5 alapja. Deer Park Alpha 2 Start Page. [Honlap.] URL: http://www.mozilla.org/projects/deerpark/alpha2.html. A letöltés időpontja 2005. 07. 29. 21148Building Mozilla with SVG Support. [Honlap.] URL: http://www.mozilla.org/projects/svg/build.html. A letöltés időpontja 2005. 07. 29. 22149The W3C Markup Validation Service. [Honlap.] URL: http://validator.w3.org. A letöltés időpontja 2005. 07. 25. 23150W3C Logo and Icon Usage. [Elektronikus dokumentum.] URL: http://www.w3.org/Consortium/Legal/logo-usage-20000308.html. A letöltés időpontja 2005. 07. 25.
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 sokkal többet mond, mint az . Ennek a szemléletnek viszont az a hátránya, hogy a hosszú nevek nagyobb fájlméretet eredményeznek. Köztes és egyben gyakorlatias megoldásként szolgál, ha a gyakran használt elemeket rövid névvel illetjük, a ritkán előfordulókat hosszabbakkal. Valahogy úgy, mint a HTML nyelv, ahol a rövid jelölőelem és bekezdésre utal, ám a
