diff --git a/hu_HU.ISO8859-2/books/fdp-primer/sgml-primer/chapter.sgml b/hu_HU.ISO8859-2/books/fdp-primer/sgml-primer/chapter.sgml index 2cf9931db9..dc11edc3c1 100644 --- a/hu_HU.ISO8859-2/books/fdp-primer/sgml-primer/chapter.sgml +++ b/hu_HU.ISO8859-2/books/fdp-primer/sgml-primer/chapter.sgml @@ -1,2127 +1,2127 @@ SGML alapismeretek Az FDP keretében készített dokumentációk többsége az SGML valamilyen alkalmazásában íródik. Ebben a fejezetben részletesebben kifejtjük a mögötte álló fogalmakat, a dokumentumok alapjául szolgáló források megértését és írását, illetve a dokumentáció forrásainak tanulmányozása során elõkerülõ különféle SGML-trükköket. A bemutatás alapjául szolgáltak Mark Galassi Get Going With DocBook címû írásának egyes részei. Áttekintés A kezdeti idõkben még viszonylag könnyen el lehetett boldogulni az elektronikus formában tárolt szövegekkel. Elegendõ volt csupán annyit tudni., hogy az adott írást milyen karakterkódolással készítették (ez lehetett ASCII, EBCDIC vagy éppen valami más). A szöveg nem volt több mint egyszerû szöveg, és közvetlenül a végleges formáját adta. Semmi csel, semmi formázás, semmi hozzáadott értelem. Ezen a fokon aztán elkerülhetetlen módon tovább kellett lépni. Hiszen ha egyszer a szöveges információkat egy számítógép által kezelhetõ alakban tároljuk, akkor jogosan elvárhatjuk, hogy az képes legyen felhasználni és értelmesen feldolgozni. Szeretnénk a szöveg bizonyos részeit például kiemelni, felvenni egy szójegyzékbe, vagy éppen hivatkozással ellátni. Az állományok neveit a képernyõn írógépszerû, a nyomtatásban viszont már dõltbetûs stílusban szeretnénk látni, nem is beszélve a szöveg megjelenésének számtalan egyéb módjáról. Egy idõben a Mesterséges Intelligencia (MI) megjelenésétõl várták a megváltást ezen a területen. A számítógépünk majd szépen beolvassa az általunk írt dokumentumot és magától felismeri a fontosabb kulcsszavakat, állományneveket, a felhasználó által begépelendõ szövegeket, a példákat és így tovább. Sajnálatosan azonban a valóságban ez még egyáltalán nem valósult meg, a számítógépeknek ezért szükségünk van némi segítségre a szöveges adatok értelmes feldolgozásában. Pontosabban úgy fogalmazhatnánk, hogy segítenünk kell nekik az egyes elemek beazonosításában. Nézzük meg például ezt a szöveget:
Az &man.rm.1; parancs használatával töröljük a /tmp/ize állományt: &prompt.user; rm /tmp/ize
Emberi szemmel könnyedén fel tudjuk ismerni benne az állományneveket, a parancsokat, a man oldalak hivatkozásait és így tovább, azonban a számítógép erre önállóan nem képes. Ezért lesz szükségünk jelölõkre. A jelölõ szó eredetijét (markup) gyakran olyan értelemben használják mint haszonkulcs vagy kockázati pótlék. Kevés elvonatkoztatással ugyanez lényegében alkalmazható a szövegek esetében is. A jelölõk a dokumentumban szereplõ kiegészítõ, hasznos, az azonosítás kockázatát csökkentõ, a szöveg többi részétõl egyértelmûen megkülönböztethetõ további szöveges információkat jelentik. Ezek alapján a programok a dokumentumok feldolgozása során képesek önállóan meghozni bizonyos döntéseket. A szövegszerkesztõk el tudják rejteni ezeket a többletinformációkat az olvasók elõl, így azok egyáltalán nem zavarják õket. A jelölõkben tárolt adatok tehát növelik a dokumentumok hasznát. A jelölõk hozzáadását, a szöveg bejelölését értelemszerûen emberek végzik, hiszen ha erre a számítógépek is képesek lennének, akkor nem is lenne rájuk egyáltalán szükség. Ezzel azonban pótlékot kell nyújtanunk (vagyis további költségeket ráfordítanunk) a dokumentumok megírásához. Az elõzõ példában szereplõ szöveget ennek megfelelõen a következõ módon írjuk meg: Az &man.rm.1; parancs használatával töröljük a /tmp/ize állományt: &prompt.user; rm /tmp/ize]]> Láthatjuk, hogy a jelölõk nagyon jól elkülöníthetõek a szöveg tartalmától. A jelölõk használatához nyilvánvalóan valamilyen módon meg kell határoznunk, hogy az adott jelölõk mit jelentenek és hogyan kell azokat értelmezni. A jelölõk összefogásához tehát szükségünk van egy ún. jelölõnyelvre, amely alapján aztán jelölni fogjuk a dokumentumainkat. Ehhez természetesen egyetlen jelölõnyelv önmagában még nem feltétlenül lesz elég. A szaknyelven íródott dokumentációkhoz igazított jelölõnyelvvel szemben teljesen másak az elvárásaink, mint például a receptek leírásához használt nyelv esetében, ez pedig megint más, mint amivel verseket tudunk jelölni. Elõször tehát egy olyan nyelvet kell megfogalmaznunk, amely ilyen jelölõnyelvek elõírására használható. Ezt nevezzük a jelölõnyelvek jelölõnyelvének, vagyis a meta-jelölõnyelvnek. Az SGML, avagy Standard Generalized Markup Language (Szabványos Általánosított Jelölõnyelv) pontosan egy ilyen nyelv. Számos jelölõnyelv készült az SGML segítségével, többek közt az FDP által leginkább használt HTML és DocBook. Az egyes nyelvek részletes leírását hivatalosan dokumetumtípus-definíciónak (Documentum Type Definition, DTD) nevezik. A DTD felhasználásával adhatjuk meg a szövegben jelölõként alkalmazható elemeket, azok sorrendjét (vagy éppen egymásba ágyazhatóságának mikéntjét) és a hozzájuk kapcsolódó egyéb információkat. A DTD-ket gyakran csak úgy említik mint az SGML alkalmazásait. A DTD tartalmazza az összes felhasználható elem leírását, azok használatának sorrendjét, megadja, hogy ezek közül melyeknek kell szerepelniük, illetve melyek hagyhatóak el és így tovább. Ennek köszönhetõen készíthetõ egy olyan SGML alapján mûködõ elemzõ, amely a DTD és egy dokumentum birtokában képes megállapítani, hogy az adott dokumentum megfelel-e a DTD által meghatározott szabályoknak: a benne szereplõ elemek a megfelelõ sorrendben vannak, esetleg tartalmaznak hibákat. Ezt a lépést nevezik általában a dokumentum érvényesítésének. Az ellenõrzés folyamán egyszerûen annyi történik, hogy az elemzõ a megadott DTD alapján jóváhagyja a dokumentumban feltüntetett elemeket, azok rendezettségét és a többit. A jelölõk helyes használatát azonban nem vizsgálja. Ha éppen függvénynévként jelöljük be a szövegben megjelenõ állományok neveit, akkor az elemezõ ezt nem fogja hibának tekinteni (ekkor természetesen feltételezzük, hogy a DTD definiálja az állomány- és függvénynevek jelölésére alkalmas elemeket, illetve ezek ugyanazokon a helyeken szerepelhetnek). A Dokumentációs Projekt számára beküldött munkáinkban jó eséllyel a HTML vagy a DocBook nyelvek valamelyike szerint kell dokumentumokat megjelölnünk, és nem kell a DTD módosításával foglalkoznunk. Ennélfogva ez a leírás sem tér ki a DTD írásának részleteire. Elemek, címkék és tulajdonságok Az SGML használatával készített dokumentumtípus-definíciók mindegyikének vannak közös jellemzõi. Ez viszont aligha lesz számunkra meglepõ, ahogy majd fokozatosan megismerkedünk az SGML kialakítása mögött álló alapvetõ gondolatokkal. Ezek közül a legkézenfekvõbbek a tartalom és az elem. A dokumentáció minden esetben (legyen az most egy normál honlap vagy éppen egy vaskos könyv) rendelkezik valamilyen tartalommal, amelyet aztán tovább (esetleg még tovább) osztunk elemekre. A jelölõk elhelyezésének ezen elemek határainak kijelölésében és elnevezésében van szerepe a feldolgozás késõbbi szakaszaiban. Ehhez példaként tekintsünk egy hagyományos könyvet. A legfelsõ szinten ez a könyv önmagában egy elemet képvisel. Ez a könyv elem aztán magától értetõdõ módon tartalmaz fejezeteket, amelyek szintén önálló elemeknek tekinthetõek. Minden ilyen fejezet további elemeket foglal magában, például bekezdéseket, idézeteket és lábjegyzeteket. Minden egyes bekezdésben találhatunk újabb elemeket, amelyek elárulják nekünk, hogy a bennük szereplõ szövegben melyik részében beszélnek egymással a szereplõk, vagy éppen hogy hívják az egyes karaktereket. Az egészet úgy képzelhetjük el mint a tartalom feldarabolását. A legfelsõ szinten adott egy darab, maga a könyv. Ahogy haladunk kicsivel lentebb, újabb darabokat találunk, a fejezeteket. Ezeket aztán tovább bomlanak bekezdésekre, lábjegyzetekre, a karakterek neveire és a többi. Meglepõ, hogy az SGML lehetõségeinek igénybevétele nélkül milyen könnyen különbséget tudunk tenni az egyes elemek közt. Ehhez valójában elegendõ a könyv nyomtatott változata, néhány különbözõ színû kiemelõ, amelyekkel aztán bejelöljük a tartalom egyes részeit. Sajnos a kiemelõknek nem létezik elektronikus változata, ezért találnunk kell valamilyen egyéb módot a tartalom egyes részeinek megjelölésére. Az SGML-ben megfogalmazott nyelvek (HTML, DocBook és társaik) ezt címkékkel oldják meg. A címkékkel mondhatjuk meg hol kezdõdnek és hol fejezõdnek be az egyes elemek. A címke nem az elem része. Mivel a DTD általában azért készül, hogy a szövegben adott típusú információkat tudjunk jelölni, adott típusú elemeket fog elfogadni, ezért ezeknek megfelelõen kell címkéket létrehoznunk. Egy elem elemhez tartozó kezdõcímke általános alakja az elem. Az hozzátartozó zárócímke pedig az /elem. Elem (kezdõ- és zárócímkék) használata A HTML-ben a bekezdéseket a p (mint paragrafus) elemmel jelölhetjük. Ehhez az elemhez tartozik kezdõ- és zárócímke. ]]>Ez egy bekezdés. A 'p' elem kezdõcímkéjétõl indul és a 'p' zárócímkéjénél fejezdõdik be.

]]>Ez meg egy másik bekezdés. Ez viszont már rövidebb.]]> Nem mindegyik elemnél kell zárócímkét használnunk, egyes elemekhez ugyanis nem járul semmilyen tartalom. Például egy HTML állományban jelölhetjük, hogy legyen a dokumentumban egy vízszintes elválasztó. Ehhez a vonalhoz értelemszerûen nem kapcsolódik tartalom, ezért elég egy kezdõcímkét beszúrni. Elem (csak kezdõcímke) használata A HTML-ben van egy hr nevû elem, amellyel vízszintes elválasztókat (horizontal rule) jelölhetünk. Ennek az elemnek nincs tartalma, ezért csak kezdõcímkével rendelkezik. ]]>Ez itt egy bekezdés.

]]>Ez pedig egy másik bekezdés. Az elõzõ bekezdéstõl egy vízszintes vonal választja el.]]> Ha eddig még nem sejtettük volna, megemlítjük, hogy az elemek természetesen elemeket is tartalmazhatnak. A korábbi könyves példánkban a könyv elem magában foglalta az összes fejezet elemet, amelyek pedig a bekezdés elemeket és így tovább. Elemek elemekben, az <sgmltag>em</sgmltag> elem ]]>Ez egy egyszerû ]]>bekezdés]]>, amelyben néhány ]]>szót]]> szépen ]]>kiemeltünk.

]]> A DTD pontosan tartalmazza mely elemek tartalmazhatnak további elemeket, valamint az elemek egymásba ágyazhatóságának szabályait. Az emberek gyakran összetévesztik a címkéket az általuk jelölt elemekkel, és egymás szinonímájaként használják ezeket a kifejezéseket. Ez viszont helytelen. A dokumentumokat elemekbõl építjük fel. Minden elem elõre meghatározott módon kezdõdik és fejezõdik be. Az elemek kezdetét és végét címkék jelölik. Amikor ez a dokumentum (vagy bárki, az SGML használatában járatos személy) a p címkére hivatkozik, akkor ez alatt a <, p, > karakterekbõl álló sorozatot érti. Ezzel szemben viszont a p a teljes elemre vonatkozik. Ez egy nagyon kicsi eltérés, de mindig tartsuk észben! Az elemeknek lehetnek tulajdonságaik. A tulajdonságokat nevek és értékek párosai alkotják, segítségükkel az elemhez fejthetünk ki további információkat. Ez lehet az adott elem által jelölt tartalom megjelenítésére vonatkozó utasítás, esetleg az elem valamilyen azonosítója vagy valami más. Az elemek tulajdonságait mindig az adott elem kezdõcímkéjén belül soroljuk fel, tulajdonság="érték" alakban. A HTML újabb változataiban például a p elemnek van egy align tulajdonsága, amely a HTML megjelenítése során javasolja, hogy az általa jelölt bekezdést merre igazítsuk. Ez az align tulajdonság négy elõre meghatározott érték valamelyikét kaphatja meg: left (balra zárt), center (középre zárt), right (jobbra zárt) és justify (sorkizárt). Ha nem adjuk meg a tulajdonság értékét a kezdõcímkében, akkor alapértelmezés szerint left lesz. Tulajdonság használata elemben ]]>Az 'align' tulajdonság ebben a bekezdésben igazából teljesen felesleges, hiszen alapértelmezés szerint is balra zárt lenne.]]> ]]>Ennek viszont már középre kellene kerülnie.]]> Egyes tulajdonságok csak adott értékeket vehetnek fel, mint például left vagy justify, másoknál viszont lényegében bármit megadhatunk. Ha a tulajdonság értékének megfogalmazása során idézõjeleket (") is használni akarunk, akkor az egész kifejezést tegyük egyszeres idézõjelbe. A tulajdonságok értékének megadása egyszeres idézõjellel ]]>Jobbra zárt!]]> Elõfordulhat, hogy az érték megadásakor egyáltalán nem kell semmilyen idézõjelet használni. Ennek szabályai viszont nagyon halványak, ezért sokkal egyszerûbb mindig idézõjelbe tenni a tulajdonságok értékeit. Az elemekhez, címkékhez és tulajdonságokhoz tartozó információk SGML katalógusokban kerülnek tárolásra. A Dokumentációs Projektben használt eszközök ilyen katalógusok mentén nézik át a munkánkat. A textproc/docproj csomagban a segédprogramok mellett rengeteg ilyen SGML-katalógust találhatunk. A &os; Dokumentációs Projektnek is vannak saját katalógusai. Az alkalmazott eszközöknek mind a két fajta katalógusokat ismerniük kell. Egy kis gyakorlás… A szakaszban szereplõ példák kipróbálásához telepítenünk kell bizonyos szoftvereket, illetve beállítani egy környezeti változó értékét. Töltsük le és telepítsük a textproc/docproj portot a &os; Portgyûjteményébõl. Ez portoknak a portja, tehát egy metaport, így a Dokumentációs Projektben használt összes eszköz rajta keresztül letöltõdik és telepítõdik. A parancssorunk konfigurációs állományában állítsuk be az SGML_CATALOG_FILES környezeti változó értékét. (Amennyiben nem az angol nyelvû dokumentációval dolgozunk, itt érdemes a nyelvünknek megfelelõ könyvtárakat megadni.) Minta <filename>.profile</filename> állomány &man.sh.1; és &man.bash.1; parancssorokhoz SGML_ROOT=/usr/local/share/sgml SGML_CATALOG_FILES=${SGML_ROOT}/jade/catalog SGML_CATALOG_FILES=${SGML_ROOT}/docbook/4.1/catalog:$SGML_CATALOG_FILES SGML_CATALOG_FILES=${SGML_ROOT}/html/catalog:$SGML_CATALOG_FILES SGML_CATALOG_FILES=${SGML_ROOT}/iso8879/catalog:$SGML_CATALOG_FILES SGML_CATALOG_FILES=/usr/doc/share/sgml/catalog:$SGML_CATALOG_FILES SGML_CATALOG_FILES=/usr/doc/en_US.ISO8859-1/share/sgml/catalog:$SGML_CATALOG_FILES export SGML_CATALOG_FILES Minta <filename>.cshrc</filename> állomány &man.csh.1; és &man.tcsh.1; parancssorokhoz setenv SGML_ROOT /usr/local/share/sgml setenv SGML_CATALOG_FILES ${SGML_ROOT}/jade/catalog setenv SGML_CATALOG_FILES ${SGML_ROOT}/docbook/4.1/catalog:$SGML_CATALOG_FILES setenv SGML_CATALOG_FILES ${SGML_ROOT}/html/catalog:$SGML_CATALOG_FILES setenv SGML_CATALOG_FILES ${SGML_ROOT}/iso8879/catalog:$SGML_CATALOG_FILES setenv SGML_CATALOG_FILES /usr/doc/share/sgml/catalog:$SGML_CATALOG_FILES setenv SGML_CATALOG_FILES /usr/doc/en_US.ISO8859-1/share/sgml/catalog:$SGML_CATALOG_FILES A módosítások elvégzése után vagy jelentkezzük ki majd be, vagy pedig adjuk ki a közvetlenül parancssorban az adott parancsokat. Hozzunk létre egy próba.sgml nevû állományt, és írjuk bele az alábbi szöveget: ]]>Próba HTML állomány<![ CDATA [

]]>Ebben a bekezdésben legyen valamennyi szöveg.

]]>Az utána következõ bekezdésbe is rakjunk még valamennyi szöveget.

]]>Ennek a bekezdésnek jobbra zártnak kellene lennie. ]]> Próbáljuk meg az állományt érvényesíteni valamelyik SGML elemezõvel. A textproc/docproj csomagnak része az nsgmls nevû érvényesítést végzõ elemezõ. Az nsgmls beolvas egy tetszõleges SGML DTD szerint definiált elemekkel jelölt dokumentumot és ebbõl elkészíti a hozzátartozó elemstruktúra-információs halmazt (Element Structure Information Set, ESIS, de ezzel itt most nem foglalkozunk). Ha viszont az nsgmls parancsnak megadjuk a paramétert, akkor nem generál tényleges eredményt, csupán a hibaüzenetek jeleníti meg. Ennek köszönhetõen könnyen ellenõrizni tudjuk, hogy az általunk készített dokumentum érvényes vagy sem. Az nsgmls parancs használatával tehát ellenõrizzük az imént létrehozott dokumentumunk érvényességét: &prompt.user; nsgmls -s próba.sgml Láthatjuk, hogy az nsgmls nem jelez semmiféle hibát, ami azt jelenti, hogy a dokumentumunk valóban érvényes. Nézzük meg mi történik akkor, ha kihagyjuk a kötelezõ elemeket. Töröljük például a title és /title címkéket, majd próbáljuk meg újra az érvényesítést. &prompt.user; nsgmls -s próba.sgml nsgmls:próba.sgml:5:4:E: character data is not allowed here nsgmls:próba.sgml:6:8:E: end tag for "HEAD" which is not finished Az nsgmls által generált hibaüzenetek kettõspontokkal tagolt csoportokba vagy oszlopokba sorolhatóak. Oszlop Jelentés 1 A hibát jelzõ program neve. Ez minden esetben az nsgmls. 2 A hibát tartalmazó állomány neve. 3 A hibát tartalmazó sor száma. 4 A hibát tartalmazó oszlop száma. 5 A generált üzenet jellegét megadó egybetûs kód. Az I információt, a W figyelmeztetést, az E hibát Ez nem minden esetben az ötödik oszlopban szerepel. Az nsgmls -sv például az nsgmls:I: SP version "1.3" üzenetet adja vissza (a tényleges verziójától függõen). Ez például egy információs üzenet. , végül pedig az X a kereszthivatkozást jelez. Ebbõl megállapítható, hogy az iménti üzenetek hibákra vonatkoznak. 6 Az üzenet szövege. Egyedül a title címke elhagyásával két különbözõ hibát kaptunk. Ezek közül az elsõ jelzi, hogy az SGML elemzõ olyan helyen találkozott tartalommal (amely ebben esetben konkrétan karaktereket jelent és nem az elemet bevezetõ kezdõcímkét), ahol valami másra számított. Az elemzõ itt ugyanis valamelyik, a head elemen belül szabályosan elhelyezhetõ elem kezdõcímkéjét várja (amilyen például a title). A második hibát pedig azért kaptuk, mert a head elemeknek tartalmazniuk kell title elemet. Az nsgmls ezt azonban nem ebben a formában közli: mivel az elemet még a befejezõdése (tehát a title megemlítése) elõtt lezártuk, szerinte egyszerûen csak nem ért véget rendesen. Tegyük vissza a title elemet. A DOCTYPE deklarációk A dokumentumok elején mindig meg kell adni annak a dokumentípus-deklarációnak a nevét, amely alapján készítjük. Ennek köszönhetõen az SGML elemzõk elõ tudják keresni a dokumentum érvényesítéséhez kellõ DTD-t. Ezt az információt általában egyetlen sorban, a DOCTYPE deklarációban adjuk meg. A HTML DTD 4.0 változatának megfelelõ dokumentumokat tehát például így vezetjük be: ]]> Ebben a sorban több különbözõ típusú alkotórészt fedezhetünk fel. <! Ez egy jelzés, amellyel jelezzük egy SGML-beli deklaráció kezdetét. Ez a sor a dokumentum típusát határozza meg. DOCTYPE A dokumentumtípus SGML-beli deklarációját vezeti be. html A dokumentumban elsõként megjelenõ elemet nevezi meg. PUBLIC "-//W3C//DTD HTML 4.0//EN" formális publikus azonosító Megadja a dokumentum DTD-jéhez tartozó formális publikus azonosítót (Formal Public Identifier, FPI). Az SGML elemzõ ennek alapján találja meg a dokumentum feldolgozása során szükséges DTD-t. A PUBLIC nem része az azonosítónak, azonban segít az SGML elemzõnek megtalálni a benne megfogalmazott DTD-t. Késõbb további módszereket is láthatunk majd erre. > A deklaráció lezárása. Formális publikus azonosítók formális publikus azonosító Ebben a szakaszban csupán kiegészítõ ismeretek szerepelnek. Ezek viszont hasznos hátteret adhatnak például olyan esetekben, amikor ki akarjuk deríteni, hogy az SGML feldolgozó miért nem éri el a megadott DTD állományokat. A formális publikus azonosítók (FPI) egy speciális felírással rendelkeznek, amely a következõ: "Tulajdonos//Kulcsszó Leírás//Nyelv" Tulajdonos Ez határozza meg kihez tartozik az FPI. Ha az értéke az ISO részlettel kezdõdik, akkor az FPI az ISO tulajdona. Például a "ISO 8879:1986//ENTITIES Greek Symbols//EN" esetén a görög szimbólumokat tartalmazó egyedkészlet tulajdonosa. Az ISO 8879:1986 az SGML szabvány ISO száma. Minden más esetben az értéke a következõ alakú lesz: -//Tulajdonos vagy +//Tulajdonos (vegyük észre, hogy a két változat csak a sor elején levõ + és - jelekben tér el). Ha az érték a - jellel kezdõdik, akkor a tulajdonos adatai nem regisztráltak, a + esetében pedig regisztráltak. Az ISO 9070:1991 szabvány definiálja a regisztrált nevek elõállítását, amelynek értelmében egy ISO publikáció, egy ISBN kód vagy az adott szervezet ISO 6523 szabványnak megfelelõ kódjának számából kell származtatni, illetve a nevek kiosztását egy erre felhatalmazott szerv végzi. Ezt a feladatot az Amerikai Nemzeti Szabványügyi Intézetre (ANSI) bízta az ISO tanácsa. Mivel a &os; Projekt nem regisztrálta magát, a hozzátartozó érték tehát a -//&os; lesz. Látható egyébként, hogy a W3C sem regisztrálta még magát. Kulcsszó Az állományban található információ típusának megadására különbözõ kulcsszavak használhatóak. Ezek általában a DTD, ELEMENT, ENTITIES és TEXT. A DTD csak DTD állományokhoz használatos, az ELEMENT pedig olyan DTD részletekhez, amelyekeben csak egyedek vagy elemek leírásai találhatóak. A TEXT SGML tartalmat jelent (szövegeket és jelölõket). Leírás Minden egyéb adat, amit az állomány tartalmáról még meg akarunk adni. Tartalmazhat verziószámokat, vagy bármilyen számunkra értelmes és az SGML rendszer számára egyedien azonosítható rövid szöveget. Nyelv Kétkarakteres, ISO szabvány szerint megadott kód, amellyel az állomány natív nyelvét adjuk meg. Az angol esetében ez az EN. Katalógusok Az SGML feldolgozónak a dokumentum feldolgozása során valamilyen módon az így megadott formális publikus azonosítóból vissza kell tudnia fejtenie a DTD-t tartalmazó állomány nevét. Mindehhez egy katalógusra lesz szükségünk. Ezek (amelyeket általában catalog néven találhatunk meg) tartalmazzák az azonosítók és a hozzájuk tartozó állománynevek összerendeléseit. Például, ha egy katalógusban a következõ sor található: PUBLIC "-//W3C//DTD HTML 4.0//EN" "4.0/strict.dtd" Az SGML feldolgozó a catalog állományt tartalmazó könyvtár 4.0 alkönyvtárában levõ strict.dtd állományban fogja keresni az adott DTD-t. Nézzünk szét kicsit a /usr/local/share/sgml/html/catalog állományban. Ez tartalmazza a textproc/docproj portból telepített HTML DTD-kre vonatkozó állományinformációkat. Az <envar>SGML_CATALOG_FILES</envar> környezeti változó Az SGML feldolgozónak valahogy tudnia kell hol keresse a katalógusokat. Számos implementációjuk parancssori paramétereken keresztül teszi lehetõvé a feldolgozás során használni kívánt katalógus vagy katalógusok felsorolását. Emellett az SGML_CATALOG_FILES környezeti változó segítségével is megadhatóak ezek az állományok. A változó értékének a (teljes elérési útvonallal kifejtett) katalógusok vesszõvel tagolt felsorolását kell beállítani. Az esetek döntõ többségében a következõ állományokat kell ilyen módon felvennünk: /usr/local/share/sgml/docbook/4.1/catalog /usr/local/share/sgml/html/catalog /usr/local/share/sgml/iso8879/catalog /usr/local/share/sgml/jade/catalog Ezt egyébként korábban már elvégeztük. Azonosítók helyett A formális publikus azonosítók használata helyett akár közvetlenül meg is adhatjuk a dokumentum érvényességét definiáló DTD-t tartalmazó konkrét állomány nevét. Ennek felírása némileg eltér: /az/elérési/út/állomány.dtd]]> A SYSTEM kulcsszóval jelezzük, hogy az SGML feldolgozó a DTD leírását rendszerszinten keresse. Ez általában (de nem mindig) azt jelenti, hogy a DTD elérhetõségét állománynév formájában adjuk meg. Az FPI használata leginkább a hordozhatóság támogatása miatt ajánlott. Ilyenkor nem kell ugyanis a dokumentumokhoz mellékelni a DTD egy példányát, illetve ha a SYSTEM kulcsszóval adnánk meg, akkor mindig az adott helyre kellene tenni a DTD állományokat. Visszaváltás az SGML használatára Az alapismeretek tárgyalása során már korábban szóba került, hogy az SGML csak a dokumentumtípus-deklaráció leírásához használatos. Ez azonban nem tökéletesen igaz, mivel léteznek olyan SGML-beli szerkezetek, amelyeket magukban a dokumentumokban is fel tudunk használni. Például a dokumentumokba beszúrhatóak az elemzõ részérõl figyelmen kívül hagyandó megjegyzések. Ezeket az SGML szabályai szerint adjuk meg. A többi szerkezet használatára kicsivel késõbb mutatunk még példákat. Nyilvánvalóan valamilyen módon jeleznünk kell az SGML feldolgozónak, hogy a soron következõ elem tartalmát hagyja figyelmen kívül, de az elemzõ ezt alapvetõen az SGML alapján észleli. Az ilyen részeket <! … > formában jelöljük. Az elhatárolók között szabályos SGML szerkezetek szerepelhetnek, pontosan olyanok, amelyeket az DTD-k készítésénél is alkalmaznak. Az elõbb bemutatott DOCTYPE deklaráció erre éppen remek példaként szolgálhat. Megjegyzések A megjegyzések tehát SGML-beli konstrukciók, és általában csak a DTD-ben érvényes a használatuk. A ban viszont láthattuk, hogy az SGML szerkezetei akár a dokumentumokban is használhatóak. Az SGML megjegyzéseket -- szimbólumok használatával határolhatjuk el. A szimbólum elsõ elõfordulásával kezdjük a megjegyzést és a másodikkal zárjuk le. Általános SGML megjegyzés <!-- próba megjegyzés --> Most a megjegyzés belsejében vagyunk ]]> A két kötõjel használata A Postscript és PDF változatok esetén kisebb problémák jelentkeznek ennél a példánál, ugyanis bennük csak egyetlen kötõjel fog látszani a <! - és > szimbólumok + és > szimbólumok mellett. A forráskódban azonban két - (kötõjel) szimbólumot kell használnunk, nem pedig egyet. A Postscript és PDF változatokban az eredetileg két kötõjelet összevonják egyetlen hosszabb kötõjellé, ezáltal elrontják az iménti példát. A dokumentum HTML, szöveges és RTF változatait ez nem érinti. ]]> Ha dolgoztunk már korábban HTML kóddal, akkor elõfordulhat, hogy más meghatározást láttunk a megjegyzésekre. Ezért tévesen azt gondolhattuk, hogy a megjegyzéseket a <!-- karaktersorozat vezeti be, és csak a --> zárhatja le. Valójában viszont nem így van. Sok böngészõ hibás HTML elemzõt tartalmaz, ezért ezt érvényesnek fogadják el. A Dokumentációs Projektben használt SGML elemzõk azonban ennél sokkal szigorúbbak és az ilyen hibás dokumentumokat visszadobják. Hibás SGML megjegyzések Most egy megjegyzés belsejében vagyunk KÍVÜL VAGYUNK A MEGJEGYZÉSEN! ismét megjegyzésben vagyunk ]]> Az SGML elemzõ ezt valahogy így fogja értelmezni: <!KÍVÜL VAGYUNK A MEGJEGYZÉSEN> Ez nem szabályos SGML és ráadásul félrevezetõ hibaüzenetet eredményez. Ez nem szép dolog! ]]> A példa szövege szerint sem javasolt ilyen megjegyzéseket írni. ]]> Ez már (valamivel) értelmesebb megoldás, de még feláll a veszélye, hogy megtéveszti az SGML-ben járatlan olvasókat. Egy kis gyakorlás… Tegyünk néhány megjegyzést a korábban készített próba.sgml állományunkba, majd az nsgmls segítségével ellenõrizzük, hogy közben érvényes marad. Tegyünk néhány érvénytelen megjegyzést a próba.sgml állományba, majd nézzük meg, hogy az nsgmls milyen hibaüzeneteket ad rájuk. Egyedek Az egyedek felhasználásával neveket tudunk rendelni a tartalom egyes darabjaihoz. Az SGML elemzõ a dokumentum feldolgozása közben ezeket az egyedeket megtalálja és helyükre beszúrja az általuk hivatkozott tartalmat. Ezzel az SGML dokumentumokban könnyedén ki tudunk alakítani újrafelhasználható, gyorsan cserélhetõ tartalmat, illetve kizárólag ezen a módon lehet jelölõkkel ellátott SGML állományokat beletenni egy másik hasonló SGML állományba. Az egyedek kétfajta típusa létezik, amelyek mindegyike eltérõ helyzetekben használható: ezek az általános egyedek és a paraméteregyedek. Általános egyedek Általános egyedeket nem lehet SGML környezetben használni (habár definiálni igen), egyedül magában a dokumentumban. Vessük össze a paraméteregyedekkel. Mindegyik általános egyed rendelkezik egy névvel. Így tudunk hivatkozni egy általános egyedre (ezáltal mindarra a szövegre, amelyet képvisel a dokumentumunkban): &egyednév;. Vegyük például, hogy van egy jelenlegi.valtozat nevû egyedünk, amely a termékünk jelenlegi verziószámát helyettesíti be a szövegbe. Ezt így fogalmaznánk meg: ]]>A termékünk jelenlegi változata a(z) ]]> Így a verziószám változásakor egyszerûen csupán az általános egyed definícióját kell megváltoztatni, majd újra feldolgozni a dokumentumot. Az általános egyedek segítségével olyan karakterek is megadhatóvá válnak, amelyeket egyébként nem tudnánk SGML dokumentumokban leírni. Például a < és a & normális esetben nem lehet része SGML dokumentumoknak. Amikor ugyanis az SGML elemzõ egy < szimbólumot észlel, feltételezi, hogy ezzel egy (kezdõ- vagy záró) címke kezdõdik, illetve amikor pedig egy & szimbólumot talál, akkor a következõ lépésben egy egyed nevét várja. Szerencsére ezek a szimbólumok a szövegben bármikor kiválthatóak az &lt; és &amp; általános egyedek használatával. Általános egyedek csak SGML környezetben definiálhatóak. Ezeket általában közvetlenül a DOCTYPE deklaráció után sorolják fel. Általános egyedek definíciója ]>]]> Figyeljük meg, hogy a DOCTYPE deklarációt a sor végén egy szögletes nyitó zárójel elhelyezésével kibõvítettük: a kiegészítésként felvett két egyedet az utána következõ két sorban definiáltuk, majd bezártuk a szögletes zárójelet és DOCTYPE deklarációt. A szögletes zárójelek szükségesek ahhoz, hogy jelezzük a DOCTYPE deklarációban megadott DTD további kiegészítéseit. Paraméteregyedek Az általános egyedekhez hasonlóan a paraméteregyedek is újrafelhasználható szövegrészek elnevezését engedik meg. Miközben azonban az általános egyedek csak a dokumentumokban alkalmazhatóak, addig a paraméteregyedek csak SGML környezetekben használhatóak. A paraméteregyedek az általános egyedekhez hasonló módon definiálhatóak, az &egyednév; felírás helyett azonban az %egyednév; alakban tudunk rájuk hivatkozni. Továbbá a definíciójukban az ENTITY kulcsszó és az egyed neve közé be kell szúrni a % (százalékjel) szimbólumot. Paraméteregyedek megadása valami szöveg más ]>]]> Ez most még nem tûnik különösebben hasznosnak. Késõbb viszont majd az lesz. Egy kis gyakorlás… Tegyük bele a próba.sgml állományunkba a következõ általános egyedet: ]> ]]>Egy minta HTML állomány<![ CDATA [

]]>Ebben a bekezdésben van egy kis szöveg.

]]>Ez a bekezdés még tartalmaz némi szöveget.

]]>Ennek a bekezdésnek jobbra zártnak kellene lennie.

]]>A dokumentum jelenlegi változata: ]]> Az nsgmls használatával vizsgáltassuk meg a dokumentum érvényességét. Töltsük be a próba.sgml állományt a böngészõnkbe (elõfordulhat, hogy másolatot kell készíteni róla próba.html néven, mert a böngészõnk csak így ismerné fel HTML dokumentumként). Hacsak a böngészõnk nem annyira fejlett, a dokumentumban a &valtozat; egyedhivatkozás nem fog lecserélõdni a verziószámra. A böngészõk többségében nagyon primitív elemzõk találhatóak, amelyek nem képesek rendesen kezelni az SGML dokumentumokat Micsoda szégyen! Képzeljük csak el, mennyi gondot és ügyeskedést (mint például a szerver oldalán beemelt állományokat) el tudnánk kerülni, ha rendesen támogatnák. . A megoldást a dokumentum normalizálása jelenti, amelyet egy SGML normalizálóval tudunk elvégezni. A normalizáló beolvas egy érvényes SGML állományt és eredményként egy szintén érvényes, de valamilyen módon átalakított SGML állományt készít. Az SGML állományok átalakításának egyik ilyen módja a dokumentumban található egyedhivatkozások helyettesítése az általuk képviselt szöveggel. Erre a célra az sgmlnorm használható. &prompt.user; sgmlnorm próba.sgml > próba.html Ennek hatására próba.html néven létrejön a dokumentum normalizált (vagyis a kifejtett egyedhivatkozásokkal létrehozott) változata, és most már betölthetõ a böngészõnkbe. Ha most megnézzük az sgmlnorm által gyártott végeredményt, akkor tapasztalhatjuk, hogy az elején nem szerepel DOCTYPE deklaráció. Ezt a kapcsolóval tehetjük hozzá: &prompt.user; sgmlnorm -d próba.sgml > próba.html Állományok tartalmának elérése egyedeken keresztül Az (általános és paraméter-) egyedek különösen hasznosak olyan esetekben, amikor állományok tartalmát akarjuk beilleszteni másik állományokba. Állományok tartalmának elérése általános egyedekkel Tegyük fel, hogy egy könyvön dolgozunk az SGML felhasználásával, amelyet fejezetenként állományokra bontottunk, fejezet1.sgml, fejezet2.sgml stb. néven, illetve a könyv.sgml állomány tartalmazza ezeket a fejezeket. Az állományok tartalmát a SYSTEM kulcsszó használatával tudjuk egyedek értékeként megadni. Ennek hatására az SGML elemzõ a megadott állomány tartalmát adja az egyed értékének. Állományok tartalmának elérése általános egyeddel ]> &fejezet.1; &fejezet.2; &fejezet.3; ]]> Amikor általános egyedeken keresztül illesztünk be állományokat egy másik állományba, a beillesztett állományok (amilyen például a fejezet1.sgml, fejezet2.sgml és a többi) nem kezdõdhetnek DOCTYPE deklarációval. Ez szintaktikai hibát eredményez! Állományok tartalmának elérése paraméteregyedekkel Emlékezzünk vissza, hogy a paraméteregyedek csak SGML környezetben alkalmazhatóak. Miért akarnánk állományokat beilleszteni egy SGML környezetbe? Így tudunk gondoskodni az általános egyedek újrafelhasználhatóságáról. Tegyük fel, hogy a dokumentumunkban rengeteg fejezet található és ezeket két különbözõ könyvben is felhasználtuk, azonban eltérõ stílusban. A könyvek elején fel lehetne sorolni az egyedeket, de ezzel viszont gyorsan kezelhetetlenné válnának. Ehelyett csak tegyünk az általános egyedekre vonatkozó definíciókat egyetlen állományba és a dokumentumunkban erre építve paraméteregyedek beiktatásával végezzük az adott állományok beillesztését. Állományok beillesztése paraméteregyedekkel Elõször vegyük az egyedek definícióit egy külön fejezetek.ent állományba. Ebben a következõek találhatóak: ]]> Most pedig hozunk létre egy paraméteregyedet az állomány tartalmának hivatkozására. Ezután az iménti paraméteregyeddel illesszük be az állományt a dokumentumba, így az összes általános egyed elérhetõvé válik. Innentõl már a megszokott módon használhatjuk az általános egyedeket: A fejezetekhez tartozó egyedek betöltéséhez definiálunk egy paraméteregyedet %fejezetek; ]> &fejezet.1; &fejezet.2; &fejezet.3; ]]> Egy kis gyakorlás… Állományok beillesztése általános egyedek segítségével Hozzunk létre három állományt: bekezd1.sgml, bekezd2.sgml és bekezd3.sgml. Töltsük fel ezeket valami hasonló szöveggel: ]]>Ez az elsõ bekezdés.]]> Szerkesszük át a próba.sgml állományunk tartalmát az alábbi módon: ]> ]]>Próba HTML állomány<![ CDATA [

]]>A dokumentum jelenlegi változata: &bekezd1; &bekezd2; &bekezd3; ]]> A próba.sgml normalizálásával hozzuk létre a próba.html állományt. &prompt.user; sgmlnorm -d próba.sgml > próba.html Nyissuk meg a böngészõnkkel a próba.html állományt és ellenõrizzük, hogy a bekezdn.sgml állományok tartalma bekerült a próba.html állományba. Állományok beillesztése paraméteregyedek segítségével Ehhez elõször végezzük el az elõbbi lépéseket. Szerkesszük át a próba.sgml állományt a következõeknek megfelelõen: %egyedek; ]> ]]>Próba HTML állomány<![ CDATA [

]]>A dokumentum jelenlegi változata: &bekezd1; &bekezd2; &bekezd3; ]]> Hozzunk létre egy új állományt egyedek.sgml néven a következõ tartalommal: ]]> A próba.sgml normalizálásával állítsuk elõ a próba.html állományt: &prompt.user; sgmlnorm -d próba.sgml > próba.html Nyissuk meg a böngészõnkben a próba.html állományt és ellenõrizzük, hogy a bekezdn.sgml állományok szerepelnek a próba.html állományban. Jelölt szakaszok Az SGML tartalmaz olyan megoldást, amellyel a dokumentum bizonyos részeit speciális feldolgozásra jelölhetjük meg. Ezeket nevezik jelölt szakaszoknak. A jelölt szakaszok felépítése <![ KULCSSZÓ [ A jelölt szakasz tartalma. ]]> A korábbiakban tapasztaltak szerint természetesen a jelölt szakaszokat az SGML részeként a <! szimbólummal vezetjük be. Ezt követõen az elsõ szögletes zárójel határolja el a jelölt szakaszt. Az elemzõ a feldolgozás során a KULCSSZÓ alapján értelmezi az adott jelölt szakaszt. A második szögletes zárójellel kezdõdik a jelölt szakasz tényleges tartalma. A jelölt szakasz az iménti két szögletes zárójel lezárásával ér véget, majd a > szimbólummal visszaváltunk az SGML környezetbõl a dokumentum környezetébe. A jelölt szakaszok kulcsszavai <literal>CDATA</literal>, <literal>RCDATA</literal> A kulcsszavakkal a jelölt szakasz tartalmi modelljét tudjuk megváltoztatni. Az SGML elemzõ a dokumentum feldolgozása során tárol egy ún. tartalmi modellt. Röviden úgy foglalhatnánk össze, hogy ez a tartalmi modell írja le az elemzõ részérõl várt információkat és azok feldolgozását. A két ilyen leghasznosabb tartalmi modell a CDATA és az RCDATA. A CDATA jelentése Character Data, vagyis karakteres adat. Az elemzõ ebben a tartalmi modellben kizárólag csak karaktereket lát. Ebben a modellben a < és & szimbólumok elveszítik különleges jelentésüket. Az RCDATA jelentése Entity references and character data, vagyis egyedhivatkozások és karakteres adatok. Ebben a tartalmi modellben az elemzõ karakterekre és egyedekre számít. A < szimbólum ilyenkor elveszíti a különleges jelentését, azonban az & továbbra is általános egyedek kezdetét fogja jelölni. Ezek használata különösen hasznos abban az esetben, amikor rengeteg < és & karaktert tartalmazó nyers szöveget akarunk beilleszteni valahova a dokumentumba. Természetesen ez megoldható úgy is, ha minden < szimbólumot &lt; karaktersorozattá, illetve minden & szimbólumot &amp; karaktersorozattá alakítunk, de sokkal könnyebb ezeket a szakaszokat CDATA típusúnak megjelölni. Az SGML elemzõk ilyenkor tehát figyelmen kívül hagyják a tartalomban talált < és & szimbólumokat. A CDATA vagy RCDATA kulcsszavakat bemutató SGML példákkal kapcsolatban megjegyezzük, hogy a CDATA szakaszok tartalma nem érvényesítõdik. Az így beillesztett SGML szöveget valamilyen más módon kell ellenõrizni. Például írjuk meg a karakteres szakasz tartalmát egy másik dokumentumban, ellenõriztessük le, majd másoljuk be a CDATA részbe. CDATA típusú jelölt szakaszok használata <para>Ebben a példában láthatjuk hogyan tudunk sok <literal>&lt;</literal> és <literal>&amp;</literal> szimbólumot tartalmazó szöveget elhelyezni a dokumentumunkban. A minta most egy HTML kódrészlet lesz, az ezt övezõ szöveg (<para>) és (<programlisting>) pedig DocBook.</para> <programlisting> <![ CDATA [ ]]>Ezzel a példával mutatjuk HTML elemek használatát a dokumentumban. Mivel elég sok relációjelet kell ilyenkor megadni, sokkal egyszerûbb azt mondani, hogy legyen az egész példa egy CDATA szakaszban, mintsem végig egyedekkel jelöljük a balra és jobb nyitó relációjeleket.

  • ]]>Ez egy listaelem
  • ]]>Ez egy másik listaelem
  • ]]>Ez már egy harmadik listaelem

]]>Itt a vége a példának.]]> ]]> </programlisting> Ha megnézzük a dokumentum forrását, láthatjuk a jelölésnél alkalmazott megoldásokat. <literal>INCLUDE</literal> és <literal>IGNORE</literal> Az INCLUDE kulcsszó megadásakor a jelölt szakasz teljes tartalma feldolgozódik. Ezzel szemben viszont az IGNORE kulcsszó esetén a jelölt szakasz tartalmát figyelmen kívül fogja hagyni az elemzõ és ezáltal nem dolgozódik fel, tehát nem jelenik meg az eredményben. Az <literal>INCLUDE</literal> és <literal>IGNORE</literal> használata jelölt szakaszokban <![ INCLUDE [ Ez a szöveg feldolgozódik és beillesztõdik. ]]> <![ IGNORE [ Ez a szöveg nem dolgozódik fel és nem is illesztõdik be. ]]> Ezek önmagukban nem túlzottan hasznosak, elvégre, ha el akarunk távolítani egy szövegrészt a dokumentumunkból, akkor vagy egyszerûen kivágjuk, vagy megjegyzésbe tesszük. Sokkal hasznosabbá válhatnak viszont a számunkra, ha észrevesszük, hogy paraméteregyedek segítségével mindez vezérelhetõ. Emlékezzünk vissza, hogy a paraméteregyedek csak SGML környezetben használhatóak, és a jelölt szakaszokhoz tartozó kulcsszavak pontosan egy ilyen SGML környezetben vannak. Például tegyük fel, hogy egy dokumentáció nyomtatott és elektronikus változatán dolgozunk egyszerre. Az elektronikus változatban szeretnénk azonban néhány olyan elemet is betenni, amelyeket nem akarunk megjelentetni nyomtatásban. Hozzunk létre egy paraméteregyedet és legyen az értéke INCLUDE. Készítsük el a dokumentumot, és jelölt szakaszokkal határoljuk el a csak az elektronikus változat megjelenõ részeket. Ezekben a jelölt szakaszokban a kulcsszavak helyére írjuk be az elõbbi paraméteregyedet. Amikor a dokumentumot nyomtatásra akarjuk elõkészíteni, akkor legyen a paraméteregyed értéke IGNORE, majd dolgozzuk fel újra az egész dokumentumot. Jelölt szakaszok vezérlése paraméteregyeddel <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [ <!ENTITY % elektronikus.valtozat "INCLUDE"> ]]> ... <![ %elektronikus.valtozat [ Ez a rész csak a dokumentum elektronikus változatában fog megjelenni. ]]> A nyomtatott változat elõkészítésekor így állítsuk át az egyed értékét: <!ENTITY % elektronikus.valtozat "IGNORE"> A dokumentum újbóli feldolgozása során a jelölt szakaszok a %elektronikus.valtozat értékét fogják kulcsszóként megkapni, és így kimaradnak. Egy kis gyakorlás… A következõ szöveggel hozzunk létre egy állományt szakasz.sgml néven: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [ <!ENTITY % szoveges.kimenet "INCLUDE"> ]> <html> <head> <title>Példa a jelölt szakaszok használatára</title> </head> <body> <p>Ez a bekezdés <![ CDATA [sok-sok < karaktert (< < < < <) tartalmaz, így érdemesebb CDATA szakaszba tenni]]>.</p> <![ IGNORE [ <p>Ez a bekezdés egyértelmûen nem fog látszódni az eredményben.</p> ]]> <![ [ <p>Ez a bekezdés nem fog feltétlenül megjelenni az eredményben.</p> <p>A konkrét megjelenését a paraméteregyed értéke befolyásolja.</p> ]]> </body> </html> A &man.sgmlnorm.1; használatával normalizáljuk ezt az állományt, majd elemezzük az eredményt. Nézzük meg melyik bekezdések tûntek el, melyek jelentek meg és mi történt a CDATA szakaszok tartalmával. A szoveges.kimenet értéke legyen INCLUDE az IGNORE helyett. Futassuk le újra így a normalizálást és vizsgáljuk meg mi változott az eredményben. Befejezés Ezzel befejeztük az SGML alapismeretek bemutatását. A helyigény, illetve a bonyolultság visszaszorítása érdekében bizonyos témákkal teljes mélységében (vagy egyáltalán) nem foglalkoztunk, azonban az iménti szakaszokban elkerült SGML ismeretek elegendõek lesznek az FDP által készített dokumentáció megértéséhez.