doc/hu_HU.ISO8859-2/books/fdp-primer/sgml-primer/chapter.xml
Gabor Kovesdan d1543284b1 - Avoid comments in CDATA sections so that these documents can easily be
converted to DocBook 5.0.  This results in an ugly markup at some parts
  but this can be corrected after the conversion is done.  Anyway, these
  sections need serious rewriting.
- Fix a double application element
2013-06-20 10:40:37 +00:00

2084 lines
65 KiB
XML

<?xml version="1.0" encoding="iso-8859-2"?>
<!-- Copyright (c) 1998, 1999 Nik Clayton, All rights reserved.
Redistribution and use in source (SGML DocBook) and 'compiled' forms
(SGML, HTML, PDF, PostScript, RTF and so forth) with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code (SGML DocBook) must retain the above
copyright notice, this list of conditions and the following
disclaimer as the first lines of this file unmodified.
2. Redistributions in compiled form (transformed to other DTDs,
converted to PDF, PostScript, RTF and other formats) must reproduce
the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials
provided with the distribution.
THIS DOCUMENTATION IS PROVIDED BY NIK CLAYTON "AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL NIK CLAYTON BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
$FreeBSD$
-->
<!-- The FreeBSD Hungarian Documentation Project
Translated by: PALI, Gabor <pgj@FreeBSD.org>
%SOURCE% en_US.ISO8859-1/books/fdp-primer/sgml-primer/chapter.xml
%SRCID% 1.50
-->
<chapter id="sgml-primer" lang="hu">
<title>SGML alapismeretek</title>
<para>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.</para>
<para>A bemutatás alapjául szolgáltak Mark
Galassi <ulink
url="http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro/docbook-intro.html">Get Going With DocBook</ulink>
címû írásának egyes
részei.</para>
<sect1 id="sgml-primer-overview">
<title>Áttekintés</title>
<para>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.</para>
<para>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
<quote>írógépszerû</quote>, a
nyomtatásban viszont már
<quote>dõltbetûs</quote> stílusban
szeretnénk látni, nem is beszélve a
szöveg megjelenésének számtalan
egyéb módjáról.</para>
<para>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.</para>
<para>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:</para>
<blockquote>
<para>Az &man.rm.1; parancs használatával
töröljük a <filename>/tmp/ize</filename>
állományt:</para>
<screen>&prompt.user; <userinput>rm /tmp/ize</userinput></screen>
</blockquote>
<para>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.</para>
<para>A <quote>jelölõ</quote> szó eredetijét
(markup) gyakran olyan értelemben használják
mint <quote>haszonkulcs</quote> vagy <quote>kockázati
pótlék</quote>. 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.</para>
<para>A jelölõkben tárolt adatok tehát
<emphasis>növelik a dokumentumok hasznát</emphasis>. 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
<emphasis>pótlékot kell nyújtanunk</emphasis>
(vagyis további költségeket
ráfordítanunk) a dokumentumok
megírásához.</para>
<para>Az elõzõ példában szereplõ
szöveget ennek megfelelõen a következõ
módon írjuk meg:</para>
<programlisting><![CDATA[<para>Az &man.rm.1; parancs használatával
töröljük a <filename>/tmp/ize</filename>
állományt:</para>
<screen>&prompt.user; <userinput>rm /tmp/ize</userinput></screen>]]></programlisting>
<para>Láthatjuk, hogy a jelölõk nagyon jól
elkülöníthetõek a szöveg
tartalmától.</para>
<para>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.</para>
<para>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
<emphasis>meta-jelölõnyelvnek</emphasis>.</para>
<para>Az SGML, avagy <emphasis>Standard Generalized Markup
Language</emphasis> (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.</para>
<para>Az egyes nyelvek részletes
leírását hivatalosan
dokumetumtípus-definíciónak
(<emphasis>Documentum Type Definition</emphasis>,
<emphasis>DTD</emphasis>) 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
<emphasis>alkalmazásait</emphasis>.</para>
<para id="sgml-primer-validating">A DTD tartalmazza az
<emphasis>összes</emphasis> 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õ
<emphasis>elemzõ</emphasis>, 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 <quote>dokumentum
érvényesítésének</quote>.</para>
<note>
<para>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
<emphasis>helyes</emphasis> használatát azonban
<emphasis>nem</emphasis> 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).</para>
</note>
<para>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.</para>
</sect1>
<sect1 id="sgml-primer-elements">
<title>Elemek, címkék és
tulajdonságok</title>
<para>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
<emphasis>tartalom</emphasis> és az
<emphasis>elem</emphasis>.</para>
<para>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.</para>
<para>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
<quote>könyv</quote> 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.</para>
<para>Az egészet úgy képzelhetjük el mint
a tartalom <quote>feldarabolását</quote>. 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.</para>
<para>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.</para>
<para>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
<emphasis>címkékkel</emphasis> oldják
meg.</para>
<para>A címkékkel mondhatjuk meg hol kezdõdnek
és hol fejezõdnek be az egyes elemek. <emphasis>A
címke nem az elem része.</emphasis> 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.</para>
<para>Egy <replaceable>elem</replaceable> elemhez tartozó
kezdõcímke általános alakja az
<sgmltag><replaceable>elem</replaceable></sgmltag>. Az
hozzá tartozó zárócímke pedig az
<sgmltag>/<replaceable>elem</replaceable></sgmltag>.</para>
<example>
<title>Elem (kezdõ- és
zárócímkék) használata</title>
<para>A HTML-ben a bekezdéseket a <sgmltag>p</sgmltag>
(mint paragrafus) elemmel jelölhetjük. Ehhez az elemhez
tartozik kezdõ- és
zárócímke.</para>
<programlisting><![CDATA[<p>]]>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.<![CDATA[</p>
<p>]]>Ez meg egy másik bekezdés. Ez viszont már rövidebb.<![CDATA[</p>]]></programlisting>
</example>
<para>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.</para>
<example>
<title>Elem (csak kezdõcímke)
használata</title>
<para>A HTML-ben van egy <sgmltag>hr</sgmltag> 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.</para>
<programlisting><![CDATA[<p>]]>Ez itt egy bekezdés.<![CDATA[</p>
<hr>
<p>]]>Ez pedig egy másik bekezdés. Az elõzõ bekezdéstõl egy vízszintes
vonal választja el.<![CDATA[</p>]]></programlisting>
</example>
<para>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.</para>
<example>
<title>Elemek elemekben, az <sgmltag>em</sgmltag> elem</title>
<programlisting><![CDATA[<p>]]>Ez egy egyszerû <![CDATA[<em>]]>bekezdés<![CDATA[</em>]]>, amelyben néhány <![CDATA[<em>]]>szót<![CDATA[</em>]]>
szépen <![CDATA[<em>]]>kiemeltünk<![CDATA[</em>.</p>]]></programlisting>
</example>
<para>A DTD pontosan tartalmazza mely elemek tartalmazhatnak
további elemeket, valamint az elemek egymásba
ágyazhatóságának
szabályait.</para>
<important>
<para>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.</para>
<para>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.</para>
<para>Amikor ez a dokumentum (vagy bárki, az SGML
használatában járatos személy)
<quote>a <sgmltag>p</sgmltag> címkére</quote>
hivatkozik, akkor ez alatt a <literal>&lt;</literal>,
<literal>p</literal>, <literal>&gt;</literal> karakterekbõl
álló sorozatot érti. Ezzel szemben viszont
<quote>a <sgmltag>p</sgmltag></quote> a teljes elemre
vonatkozik.</para>
<para>Ez egy <emphasis>nagyon</emphasis> kicsi
eltérés, de mindig tartsuk észben!</para>
</important>
<para>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.</para>
<para>Az elemek tulajdonságait mindig az adott elem
kezdõcímkéjén
<emphasis>belül</emphasis> soroljuk fel,
<literal><replaceable>tulajdonság</replaceable>="<replaceable>érték</replaceable>"</literal>
alakban.</para>
<para>A HTML újabb változataiban például
a <sgmltag>p</sgmltag> elemnek van egy <sgmltag>align</sgmltag>
tulajdonsága, amely a HTML megjelenítése
során javasolja, hogy az általa jelölt
bekezdést merre igazítsuk.</para>
<para>Ez az <sgmltag>align</sgmltag> tulajdonság négy
elõre meghatározott érték
valamelyikét kaphatja meg: <literal>left</literal> (balra
zárt), <literal>center</literal> (középre
zárt), <literal>right</literal> (jobbra zárt)
és <literal>justify</literal> (sorkizárt). Ha nem
adjuk meg a tulajdonság értékét a
kezdõcímkében, akkor
alapértelmezés szerint <literal>left</literal>
lesz.</para>
<example>
<title>Tulajdonság használata elemben</title>
<programlisting><![CDATA[<p align="left">]]>Az 'align' tulajdonság ebben a bekezdésben igazából
teljesen felesleges, hiszen alapértelmezés szerint is balra zárt
lenne.<![CDATA[</p>]]>
<![CDATA[<p align="center">]]>Ennek viszont már középre kellene kerülnie.<![CDATA[</p>]]></programlisting>
</example>
<para>Egyes tulajdonságok csak adott értékeket
vehetnek fel, mint például <literal>left</literal>
vagy <literal>justify</literal>, másoknál viszont
lényegében bármit megadhatunk. Ha a
tulajdonság értékének
megfogalmazása során idézõjeleket
(<literal>"</literal>) is használni akarunk, akkor az
egész kifejezést tegyük egyszeres
idézõjelbe.</para>
<example>
<title>A tulajdonságok értékének
megadása egyszeres idézõjellel</title>
<programlisting><![CDATA[<p align='right'>]]>Jobbra zárt!<![CDATA[</p>]]></programlisting>
</example>
<para>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 <emphasis>mindig</emphasis> idézõjelbe
tenni a tulajdonságok értékeit.</para>
<para>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 <filename
role="package">textproc/docproj</filename> 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.</para>
<sect2>
<title>Egy kis gyakorlás&hellip;</title>
<para>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.</para>
<procedure>
<step>
<para>Töltsük le és telepítsük a
<filename role="package">textproc/docproj</filename> portot a
&os; Portgyûjteményébõl. Ez
portoknak a portja, tehát egy
<emphasis>metaport</emphasis>, így a
Dokumentációs Projektben használt
összes eszköz rajta keresztül
letöltõdik és
telepítõdik.</para>
</step>
<step>
<para>A parancssorunk konfigurációs
állományában állítsuk be az
<envar>SGML_CATALOG_FILES</envar> 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.)</para>
<example id="sgml-primer-envars">
<title>Minta <filename>.profile</filename>
állomány &man.sh.1; és &man.bash.1;
parancssorokhoz</title>
<programlisting>SGML_ROOT=/usr/local/share/xml
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/xml/catalog:$SGML_CATALOG_FILES
SGML_CATALOG_FILES=/usr/doc/en_US.ISO8859-1/share/xml/catalog:$SGML_CATALOG_FILES
export SGML_CATALOG_FILES</programlisting>
</example>
<example>
<title>Minta <filename>.cshrc</filename>
állomány &man.csh.1; és &man.tcsh.1;
parancssorokhoz</title>
<programlisting>setenv SGML_ROOT /usr/local/share/xml
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/xml/catalog:$SGML_CATALOG_FILES
setenv SGML_CATALOG_FILES /usr/doc/en_US.ISO8859-1/share/xml/catalog:$SGML_CATALOG_FILES</programlisting>
</example>
<para>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.</para>
</step>
</procedure>
<procedure>
<step>
<para>Hozzunk létre egy
<filename>próba.xml</filename> nevû
állományt, és írjuk bele az
alábbi szöveget:</para>
<programlisting><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>]]>Próba HTML állomány<![CDATA[</title>
</head>
<body>
<p>]]>Ebben a bekezdésben legyen valamennyi szöveg.<![CDATA[</p>
<p>]]>Az utána következõ bekezdésbe is rakjunk még valamennyi szöveget.<![CDATA[</p>
<p align="right">]]>Ennek a bekezdésnek jobbra zártnak kellene lennie.<![CDATA[</p>
</body>
</html>]]></programlisting>
</step>
<step>
<para>Próbáljuk meg az állományt
érvényesíteni valamelyik SGML
elemezõvel.</para>
<para>A <filename role="package">textproc/docproj</filename>
csomagnak része az <command>onsgmls</command>
nevû <link
linkend="sgml-primer-validating">érvényesítést végzõ elemezõ</link>.
Az <command>onsgmls</command> 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).</para>
<para>Ha viszont az <command>onsgmls</command> parancsnak
megadjuk a <option>-s</option> 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.</para>
<para>Az <command>onsgmls</command> parancs
használatával tehát
ellenõrizzük az imént létrehozott
dokumentumunk
érvényességét:</para>
<screen>&prompt.user; <userinput>onsgmls -s próba.xml</userinput></screen>
<para>Láthatjuk, hogy az <command>onsgmls</command> nem
jelez semmiféle hibát, ami azt jelenti, hogy a
dokumentumunk valóban érvényes.</para>
</step>
<step>
<para>Nézzük meg mi történik akkor, ha
kihagyjuk a kötelezõ elemeket.
Töröljük például a
<sgmltag>title</sgmltag> és <sgmltag>/title</sgmltag>
címkéket, majd próbáljuk meg
újra az
érvényesítést.</para>
<screen>&prompt.user; <userinput>onsgmls -s próba.xml</userinput>
onsgmls:próba.xml:5:4:E: character data is not allowed here
onsgmls:próba.xml:6:8:E: end tag for "HEAD" which is not finished</screen>
<para>Az <command>onsgmls</command> által
generált hibaüzenetek kettõspontokkal
tagolt csoportokba vagy oszlopokba
sorolhatóak.</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>Oszlop</entry>
<entry>Jelentés</entry>
</row>
</thead>
<tbody>
<row>
<entry>1</entry>
<entry>A hibát jelzõ program neve. Ez
minden esetben az <literal>onsgmls</literal>.</entry>
</row>
<row>
<entry>2</entry>
<entry>A hibát tartalmazó
állomány neve.</entry>
</row>
<row>
<entry>3</entry>
<entry>A hibát tartalmazó sor
száma.</entry>
</row>
<row>
<entry>4</entry>
<entry>A hibát tartalmazó oszlop
száma.</entry>
</row>
<row>
<entry>5</entry>
<entry>A generált üzenet jellegét
megadó egybetûs kód. Az
<literal>I</literal> információt, a
<literal>W</literal> figyelmeztetést, az
<literal>E</literal> hibát
<footnote>
<para>Ez nem minden esetben az ötödik
oszlopban szerepel. Az <command>onsgmls
-sv</command> például az
<literal>onsgmls:I: "OpenSP" version "1.5.2"</literal>
üzenetet adja vissza (a tényleges
verziójától
függõen). Ez például
egy információs
üzenet.</para>
</footnote>, végül pedig az
<literal>X</literal> a kereszthivatkozást
jelez. Ebbõl
megállapítható, hogy az
iménti üzenetek hibákra
vonatkoznak.</entry>
</row>
<row>
<entry>6</entry>
<entry>Az üzenet szövege.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Egyedül a <sgmltag>title</sgmltag> címke
elhagyásával két
különbözõ hibát kaptunk.</para>
<para>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
<sgmltag>head</sgmltag> elemen belül szabályosan
elhelyezhetõ elem
kezdõcímkéjét várja
(amilyen például a
<sgmltag>title</sgmltag>).</para>
<para>A második hibát pedig azért kaptuk,
mert a <sgmltag>head</sgmltag> elemeknek tartalmazniuk
<emphasis>kell</emphasis> <sgmltag>title</sgmltag> elemet.
Az <command>onsgmls</command> ezt azonban nem ebben a
formában közli: mivel az elemet még a
befejezõdése (tehát a
<sgmltag>title</sgmltag> megemlítése)
elõtt lezártuk, szerinte egyszerûen csak
nem ért véget rendesen.</para>
</step>
<step>
<para>Tegyük vissza a <sgmltag>title</sgmltag>
elemet.</para>
</step>
</procedure>
</sect2>
</sect1>
<sect1 id="sgml-primer-doctype-declaration">
<title>A DOCTYPE deklarációk</title>
<para>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.</para>
<para>Ezt az információt általában
egyetlen sorban, a DOCTYPE deklarációban adjuk
meg.</para>
<para>A HTML DTD 4.0 változatának megfelelõ
dokumentumokat tehát például így
vezetjük be:</para>
<programlisting><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN">]]></programlisting>
<para>Ebben a sorban több különbözõ
típusú alkotórészt fedezhetünk
fel.</para>
<variablelist>
<varlistentry>
<term><literal>&lt;!</literal></term>
<listitem>
<para>Ez egy <emphasis>jelzés</emphasis>, amellyel
jelezzük egy SGML-beli deklaráció
kezdetét. Ez a sor a dokumentum
típusát határozza meg.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>DOCTYPE</literal></term>
<listitem>
<para>A dokumentumtípus SGML-beli
deklarációját vezeti be.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>html</literal></term>
<listitem>
<para>A dokumentumban elsõként megjelenõ
<link linkend="sgml-primer-elements">elemet</link>
nevezi meg.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>PUBLIC "-//W3C//DTD HTML 4.0//EN"</literal></term>
<listitem>
<indexterm>
<primary>formális publikus
azonosító</primary>
</indexterm>
<para>Megadja a dokumentum DTD-jéhez tartozó
formális publikus azonosítót
(<emphasis>Formal Public Identifier</emphasis>,
<emphasis>FPI</emphasis>). Az SGML elemzõ ennek
alapján találja meg a dokumentum
feldolgozása során szükséges
DTD-t.</para>
<para>A <literal>PUBLIC</literal> nem része az
azonosítónak, azonban segít az SGML
elemzõnek megtalálni a benne megfogalmazott
DTD-t. <link
linkend="sgml-primer-fpi-alternatives">Késõbb</link>
további módszereket is láthatunk majd
erre.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>&gt;</literal></term>
<listitem>
<para>A deklaráció
lezárása.</para>
</listitem>
</varlistentry>
</variablelist>
<sect2>
<title>Formális publikus azonosítók</title>
<indexterm significance="preferred">
<primary>formális publikus
azonosító</primary>
</indexterm>
<note>
<para>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.</para>
</note>
<para>A formális publikus azonosítók (FPI)
egy speciális felírással rendelkeznek, amely
a következõ:</para>
<programlisting>"<replaceable>Tulajdonos</replaceable>//<replaceable>Kulcsszó</replaceable> <replaceable>Leírás</replaceable>//<replaceable>Nyelv</replaceable>"</programlisting>
<variablelist>
<varlistentry>
<term><replaceable>Tulajdonos</replaceable></term>
<listitem>
<para>Ez határozza meg kihez tartozik az FPI.</para>
<para>Ha az értéke az <quote>ISO</quote>
részlettel kezdõdik, akkor az FPI az ISO
tulajdona. Például a <literal>"ISO
8879:1986//ENTITIES Greek Symbols//EN"</literal>
esetén a görög szimbólumokat
tartalmazó egyedkészlet tulajdonosa. Az ISO
8879:1986 az SGML szabvány ISO száma.</para>
<para>Minden más esetben az értéke a
következõ alakú lesz:
<literal>-//<replaceable>Tulajdonos</replaceable></literal>
vagy
<literal>+//<replaceable>Tulajdonos</replaceable></literal>
(vegyük észre, hogy a két
változat csak a sor elején levõ
<literal>+</literal> és <literal>-</literal>
jelekben tér el).</para>
<para>Ha az érték a <literal>-</literal>
jellel kezdõdik, akkor a tulajdonos adatai nem
regisztráltak, a <literal>+</literal>
esetében pedig regisztráltak.</para>
<para>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.</para>
<para>Mivel a &os; Projekt nem regisztrálta
magát, a hozzá tartozó
érték tehát a
<literal>-//&os;</literal> lesz. Látható
egyébként, hogy a W3C sem
regisztrálta még magát.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable>Kulcsszó</replaceable></term>
<listitem>
<para>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 <literal>DTD</literal>,
<literal>ELEMENT</literal>, <literal>ENTITIES</literal>
és <literal>TEXT</literal>. A
<literal>DTD</literal> csak DTD
állományokhoz használatos, az
<literal>ELEMENT</literal> pedig olyan DTD
részletekhez, amelyekeben csak egyedek vagy elemek
leírásai találhatóak. A
<literal>TEXT</literal> SGML tartalmat jelent
(szövegeket és jelölõket).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable>Leírás</replaceable></term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable>Nyelv</replaceable></term>
<listitem>
<para>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 <literal>EN</literal>.</para>
</listitem>
</varlistentry>
</variablelist>
<sect3>
<title>Katalógusok</title>
<para>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.</para>
<para>Mindehhez egy katalógusra lesz
szükségünk. Ezek (amelyeket
általában <filename>catalog</filename>
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ó:</para>
<programlisting>PUBLIC "-//W3C//DTD HTML 4.0//EN" "4.0/strict.dtd"</programlisting>
<para>Az SGML feldolgozó a <filename>catalog</filename>
állományt tartalmazó könyvtár
<filename>4.0</filename> alkönyvtárában
levõ <filename>strict.dtd</filename>
állományban fogja keresni az adott DTD-t.</para>
<para>Nézzünk szét kicsit a
<filename>/usr/local/share/xml/html/catalog</filename>
állományban. Ez tartalmazza a <filename
role="package">textproc/docproj</filename> portból
telepített HTML DTD-kre vonatkozó
állományinformációkat.</para>
</sect3>
<sect3>
<title>Az <envar>SGML_CATALOG_FILES</envar> környezeti
változó</title>
<para>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.</para>
<para>Emellett az <envar>SGML_CATALOG_FILES</envar>
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.</para>
<para>Az esetek döntõ többségében a
következõ állományokat kell ilyen
módon felvennünk:</para>
<itemizedlist>
<listitem>
<para><filename>/usr/local/share/xml/docbook/4.1/catalog</filename></para>
</listitem>
<listitem>
<para><filename>/usr/local/share/xml/html/catalog</filename></para>
</listitem>
<listitem>
<para><filename>/usr/local/share/xml/iso8879/catalog</filename></para>
</listitem>
<listitem>
<para><filename>/usr/local/share/xml/jade/catalog</filename></para>
</listitem>
</itemizedlist>
<para>Ezt egyébként <link
linkend="sgml-primer-envars">korábban már elvégeztük</link>.</para>
</sect3>
</sect2>
<sect2 id="sgml-primer-fpi-alternatives">
<title>Azonosítók helyett</title>
<para>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.</para>
<para>Ennek felírása némileg
eltér:</para>
<programlisting><![CDATA[<!DOCTYPE html SYSTEM "]]>/az/elérési/út/állomány.dtd<![CDATA[">]]></programlisting>
<para>A <literal>SYSTEM</literal> 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.</para>
<para>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 <literal>SYSTEM</literal> kulcsszóval
adnánk meg, akkor mindig az adott helyre kellene tenni a
DTD állományokat.</para>
</sect2>
</sect1>
<sect1 id="sgml-primer-sgml-escape">
<title>Visszaváltás az SGML
használatára</title>
<para>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.</para>
<para>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.</para>
<para>Az ilyen részeket <literal>&lt;! &hellip;
&gt;</literal> 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.</para>
<para>Az elõbb bemutatott <link
linkend="sgml-primer-doctype-declaration">DOCTYPE deklaráció</link>
erre éppen remek példaként
szolgálhat.</para>
</sect1>
<sect1 id="sgml-primer-comments">
<title>Megjegyzések</title>
<para>A megjegyzések tehát SGML-beli
konstrukciók, és általában csak a
DTD-ben érvényes a használatuk. A <xref
linkend="sgml-primer-sgml-escape"/>ban viszont láthattuk,
hogy az SGML szerkezetei akár a dokumentumokban is
használhatóak.</para>
<para>Az SGML megjegyzéseket
<quote><literal>--</literal></quote> 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.</para>
<example>
<title>Általános SGML megjegyzés</title>
<programlisting>&lt;!-- próba megjegyzés --&gt;</programlisting>
<programlisting>
&lt;!&hyphen;- Most a megjegyzés belsejében vagyunk -&hyphen;&gt;
&lt;!&hyphen;- Ez pedig egy másik megjegyzés -&hyphen;&gt;
&lt;!&hyphen;- Így lehet például
többsoros megjegyzéseket írni -&hyphen;&gt;
&lt;!&hyphen;- Ez egy másik módja a -&hyphen;
&hyphen;- többsoros megjegyzések írásának -&hyphen;&gt;</programlisting>
</example>
<para>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
<literal>&lt;!--</literal> karaktersorozat vezeti be, és
csak a <literal>--&gt;</literal> zárhatja le.</para>
<para>Valójában viszont <emphasis>nem</emphasis>
í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.</para>
<example>
<title>Hibás SGML megjegyzések</title>
<programlisting>
&lt;!&hyphen;- Most egy megjegyzés belsejében vagyunk -&hyphen;&gt;
KÍVÜL VAGYUNK A MEGJEGYZÉSEN!
&hyphen;- ismét megjegyzésben vagyunk -&hyphen;&gt;</programlisting>
<para>Az SGML elemzõ ezt valahogy így fogja
értelmezni:</para>
<programlisting>&lt;!KÍVÜL VAGYUNK A MEGJEGYZÉSEN&gt;</programlisting>
<para>Ez nem szabályos SGML és
ráadásul félrevezetõ hibaüzenetet
eredményez.</para>
<programlisting>&lt;!&hyphen;&hyphen;&hyphen;&hyphen;&hyphen; Ez nem szép dolog! &hyphen;&hyphen;&hyphen;&hyphen;&hyphen;&gt;</programlisting>
<para>A példa szövege szerint <emphasis>sem</emphasis>
javasolt ilyen megjegyzéseket írni.</para>
<programlisting>&lt;!&hyphen;-===================================================-&hyphen;&gt;</programlisting>
<para>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.</para>
</example>
<sect2>
<title>Egy kis gyakorlás&hellip;</title>
<procedure>
<step>
<para>Tegyünk néhány megjegyzést a
korábban készített
<filename>próba.xml</filename>
állományunkba, majd az
<command>onsgmls</command> segítségével
ellenõrizzük, hogy közben
érvényes marad.</para>
</step>
<step>
<para>Tegyünk néhány
érvénytelen megjegyzést a
<filename>próba.xml</filename>
állományba, majd nézzük meg, hogy
az <command>onsgmls</command> milyen hibaüzeneteket ad
rájuk.</para>
</step>
</procedure>
</sect2>
</sect1>
<sect1 id="sgml-primer-entities">
<title>Egyedek</title>
<para>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.</para>
<para>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.</para>
<para>Az egyedek kétfajta típusa létezik,
amelyek mindegyike eltérõ helyzetekben
használható: ezek az
<emphasis>általános egyedek</emphasis> és a
<emphasis>paraméteregyedek</emphasis>.</para>
<sect2 id="sgml-primer-general-entities">
<title>Általános egyedek</title>
<para>Á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 <link
linkend="sgml-primer-parameter-entities">paraméteregyedekkel</link>.</para>
<para>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):
<literal>&amp;<replaceable>egyednév</replaceable>;</literal>.
Vegyük például, hogy van egy
<literal>jelenlegi.valtozat</literal> nevû egyedünk,
amely a termékünk jelenlegi
verziószámát helyettesíti be a
szövegbe. Ezt így fogalmaznánk meg:</para>
<programlisting><![CDATA[<para>]]>A termékünk jelenlegi változata a(z)
<![CDATA[&jelenlegi.valtozat;.</para>]]></programlisting>
<para>Í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.</para>
<para>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 <literal>&lt;</literal>
és a <literal>&amp;</literal> normális esetben
nem lehet része SGML dokumentumoknak. Amikor ugyanis az
SGML elemzõ egy <literal>&lt;</literal> szimbólumot
észlel, feltételezi, hogy ezzel egy (kezdõ-
vagy záró) címke kezdõdik, illetve
amikor pedig egy <literal>&amp;</literal> szimbólumot
talál, akkor a következõ lépésben
egy egyed nevét várja.</para>
<para>Szerencsére ezek a szimbólumok a
szövegben bármikor kiválthatóak az
<literal>&amp;lt;</literal> és
<literal>&amp;amp;</literal> általános egyedek
használatával.</para>
<para>Á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.</para>
<example>
<title>Általános egyedek
definíciója</title>
<programlisting><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY jelenlegi.valtozat "3.0-RELEASE">
<!ENTITY legutolso.valtozat "2.2.7-RELEASE">
]>]]></programlisting>
<para>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.</para>
<para>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.</para>
</example>
</sect2>
<sect2 id="sgml-primer-parameter-entities">
<title>Paraméteregyedek</title>
<para>Az <link
linkend="sgml-primer-general-entities">általános egyedekhez</link>
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
<link
linkend="sgml-primer-sgml-escape">SGML környezetekben</link>
használhatóak.</para>
<para>A paraméteregyedek az általános
egyedekhez hasonló módon
definiálhatóak, az
<literal>&amp;<replaceable>egyednév</replaceable>;</literal>
felírás helyett azonban az
<literal>%<replaceable>egyednév</replaceable>;</literal>
alakban tudunk rájuk hivatkozni. Továbbá a
definíciójukban az <literal>ENTITY</literal>
kulcsszó és az egyed neve közé be kell
szúrni a <literal>%</literal> (százalékjel)
szimbólumot.</para>
<example>
<title>Paraméteregyedek megadása</title>
<programlisting><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY % param.valami "valami">
<!ENTITY % param.szoveg "szöveg">
<!ENTITY % param.uj "%param.valami más %param.szoveg">
]]></programlisting>
</example>
<para>Ez most még nem tûnik
különösebben hasznosnak. Késõbb
viszont majd az lesz.</para>
</sect2>
<sect2>
<title>Egy kis gyakorlás&hellip;</title>
<procedure>
<step>
<para>Tegyük bele a
<filename>próba.xml</filename>
állományunkba a következõ
általános egyedet:</para>
<programlisting><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
<!ENTITY valtozat "1.1">
]>
<html>
<head>
<title>Egy minta HTML állomány</title>
</head>
<body>
<p>Ebben a bekezdésben van egy kis szöveg.</p>
<p>Ez a bekezdés még tartalmaz némi szöveget.</p>
<p align="right">Ennek a bekezdésnek jobbra zártnak kellene lennie.</p>
<p>A dokumentum jelenlegi változata: &valtozat;</p>
</body>
</html>]]></programlisting>
</step>
<step>
<para>Az <command>onsgmls</command> használatával
vizsgáltassuk meg a dokumentum
érvényességét.</para>
</step>
<step>
<para>Töltsük be a
<filename>próba.xml</filename>
állományt a böngészõnkbe
(elõfordulhat, hogy másolatot kell
készíteni róla
<filename>próba.html</filename> néven, mert a
böngészõnk csak így ismerné
fel HTML dokumentumként).</para>
<para>Hacsak a böngészõnk nem annyira
fejlett, a dokumentumban a <literal>&amp;valtozat;</literal>
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<footnote>
<para>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.</para>
</footnote>.</para>
</step>
<step>
<para>A megoldást a dokumentum
<emphasis>normalizálása</emphasis> 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.</para>
<para>Erre a célra az <command>osgmlnorm</command>
használható.</para>
<screen>&prompt.user; <userinput>osgmlnorm próba.xml &gt; próba.html</userinput></screen>
<para>Ennek hatására
<filename>próba.html</filename> 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.</para>
</step>
<step>
<para>Ha most megnézzük az
<command>osgmlnorm</command> által gyártott
végeredményt, akkor tapasztalhatjuk, hogy az
elején nem szerepel DOCTYPE deklaráció.
Ezt a <option>-d</option> kapcsolóval tehetjük
hozzá:</para>
<screen>&prompt.user; <userinput>osgmlnorm -d próba.xml &gt; próba.html</userinput></screen>
</step>
</procedure>
</sect2>
</sect1>
<sect1 id="sgml-primer-include">
<title>Állományok tartalmának
elérése egyedeken keresztül</title>
<para>Az (<link
linkend="sgml-primer-general-entities">általános</link>
és <link
linkend="sgml-primer-parameter-entities">paraméter-</link>)
egyedek különösen hasznosak olyan esetekben, amikor
állományok tartalmát akarjuk beilleszteni
másik állományokba.</para>
<sect2 id="sgml-primer-include-using-gen-entities">
<title>Állományok tartalmának
elérése általános egyedekkel</title>
<para>Tegyük fel, hogy egy könyvön dolgozunk az
SGML felhasználásával, amelyet
fejezetenként állományokra bontottunk,
<filename>fejezet1.xml</filename>,
<filename>fejezet2.xml</filename> stb. néven, illetve a
<filename>könyv.xml</filename> állomány
tartalmazza ezeket a fejezeket.</para>
<para>Az állományok tartalmát a
<literal>SYSTEM</literal> 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.</para>
<example>
<title>Állományok tartalmának
elérése általános egyeddel</title>
<programlisting><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY fejezet.1 SYSTEM "fejezet1.xml">
<!ENTITY fejezet.2 SYSTEM "fejezet2.xml">
<!ENTITY fejezet.3 SYSTEM "fejezet3.xml">
]>
<html>
&fejezet.1;
&fejezet.2;
&fejezet.3;
</html>]]></programlisting>
</example>
<warning>
<para>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
<filename>fejezet1.xml</filename>,
<filename>fejezet2.xml</filename> és a többi)
<emphasis>nem</emphasis> kezdõdhetnek DOCTYPE
deklarációval. Ez szintaktikai hibát
eredményez!</para>
</warning>
</sect2>
<sect2>
<title>Állományok tartalmának
elérése paraméteregyedekkel</title>
<para>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?</para>
<para>Így tudunk gondoskodni az általános
egyedek
újrafelhasználhatóságáról.</para>
<para>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.</para>
<para>A könyvek elején fel lehetne sorolni az
egyedeket, de ezzel viszont gyorsan kezelhetetlenné
válnának.</para>
<para>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.</para>
<example>
<title>Állományok beillesztése
paraméteregyedekkel</title>
<para>Elõször vegyük az egyedek
definícióit egy külön
<filename>fejezetek.ent</filename> állományba.
Ebben a következõek
találhatóak:</para>
<programlisting><![CDATA[<!ENTITY fejezet.1 SYSTEM "fejezet1.xml">
<!ENTITY fejezet.2 SYSTEM "fejezet2.xml">
<!ENTITY fejezet.3 SYSTEM "fejezet3.xml">]]></programlisting>
<para>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:</para>
<programlisting><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY % fejezetek SYSTEM "fejezetek.ent">
%fejezetek;
]>
<html>
&fejezet.1;
&fejezet.2;
&fejezet.3;
</html>]]></programlisting>
</example>
</sect2>
<sect2>
<title>Egy kis gyakorlás&hellip;</title>
<sect3>
<title>Állományok beillesztése
általános egyedek
segítségével</title>
<procedure>
<step>
<para>Hozzunk létre három
állományt: <filename>bekezd1.xml</filename>,
<filename>bekezd2.xml</filename> és
<filename>bekezd3.xml</filename>.</para>
<para>Töltsük fel ezeket valami hasonló
szöveggel:</para>
<programlisting><![CDATA[<p>]]>Ez az elsõ bekezdés.<![CDATA[</p>]]></programlisting>
</step>
<step>
<para>Szerkesszük át a
<filename>próba.xml</filename>
állományunk tartalmát az
alábbi módon:</para>
<programlisting><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY valtozat "1.1">
<!ENTITY bekezd1 SYSTEM "bekezd1.xml">
<!ENTITY bekezd2 SYSTEM "bekezd2.xml">
<!ENTITY bekezd3 SYSTEM "bekezd3.xml">
]>
<html>
<head>
<title>Próba HTML állomány</title>
</head>
<body>
<p>A dokumentum jelenlegi változata: &valtozat;</p>
&bekezd1;
&bekezd2;
&bekezd3;
</body>
</html>]]></programlisting>
</step>
<step>
<para>A <filename>próba.xml</filename>
normalizálásával hozzuk létre a
<filename>próba.html</filename>
állományt.</para>
<screen>&prompt.user; <userinput>osgmlnorm -d próba.xml &gt; próba.html</userinput></screen>
</step>
<step>
<para>Nyissuk meg a böngészõnkkel a
<filename>próba.html</filename>
állományt és ellenõrizzük,
hogy a
<filename>bekezd<replaceable>n</replaceable>.xml</filename>
állományok tartalma bekerült a
<filename>próba.html</filename>
állományba.</para>
</step>
</procedure>
</sect3>
<sect3>
<title>Állományok beillesztése
paraméteregyedek
segítségével</title>
<note>
<para>Ehhez elõször végezzük el az
elõbbi lépéseket.</para>
</note>
<procedure>
<step>
<para>Szerkesszük át a
<filename>próba.xml</filename>
állományt a következõeknek
megfelelõen:</para>
<programlisting><![CDATA[<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY % egyedek SYSTEM "egyedek.xml"> %egyedek;
]>
<html>
<head>
<title>]]>Próba HTML állomány<![CDATA[</title>
</head>
<body>
<p>]]>A dokumentum jelenlegi változata: <![CDATA[&valtozat;</p>
&bekezd1;
&bekezd2;
&bekezd3;
</body>
</html>]]></programlisting>
</step>
<step>
<para>Hozzunk létre egy új
állományt <filename>egyedek.xml</filename>
néven a következõ tartalommal:</para>
<programlisting><![CDATA[<!ENTITY valtozat "1.1">
<!ENTITY bekezd1 SYSTEM "bekezd1.xml">
<!ENTITY bekezd2 SYSTEM "bekezd2.xml">
<!ENTITY bekezd3 SYSTEM "bekezd3.xml">]]></programlisting>
</step>
<step>
<para>A <filename>próba.xml</filename>
normalizálásával állítsuk
elõ a <filename>próba.html</filename>
állományt:</para>
<screen>&prompt.user; <userinput>osgmlnorm -d próba.xml &gt; próba.html</userinput></screen>
</step>
<step>
<para>Nyissuk meg a böngészõnkben a
<filename>próba.html</filename>
állományt és ellenõrizzük,
hogy a
<filename>bekezd<replaceable>n</replaceable>.xml</filename>
állományok szerepelnek a
<filename>próba.html</filename>
állományban.</para>
</step>
</procedure>
</sect3>
</sect2>
</sect1>
<sect1 id="sgml-primer-marked-sections">
<title>Jelölt szakaszok</title>
<para>Az SGML tartalmaz olyan megoldást, amellyel a
dokumentum bizonyos részeit speciális
feldolgozásra jelölhetjük meg. Ezeket nevezik
<quote>jelölt szakaszoknak</quote>.</para>
<example>
<title>A jelölt szakaszok
felépítése</title>
<programlisting>&lt;![ <replaceable>KULCSSZÓ</replaceable> [
A jelölt szakasz tartalma.
]]&gt;</programlisting>
</example>
<para>A korábbiakban tapasztaltak szerint
természetesen a jelölt szakaszokat az SGML
részeként a <literal>&lt;!</literal>
szimbólummal vezetjük be.</para>
<para>Ezt követõen az elsõ szögletes
zárójel határolja el a jelölt
szakaszt.</para>
<para>Az elemzõ a feldolgozás során a
<replaceable>KULCSSZÓ</replaceable> alapján
értelmezi az adott jelölt szakaszt.</para>
<para>A második szögletes zárójellel
kezdõdik a jelölt szakasz tényleges
tartalma.</para>
<para>A jelölt szakasz az iménti két
szögletes zárójel
lezárásával ér véget, majd a
<literal>&gt;</literal> szimbólummal visszaváltunk
az SGML környezetbõl a dokumentum
környezetébe.</para>
<sect2>
<title>A jelölt szakaszok kulcsszavai</title>
<sect3>
<title><literal>CDATA</literal>, <literal>RCDATA</literal></title>
<para>A kulcsszavakkal a jelölt szakasz <emphasis>tartalmi
modelljét</emphasis> tudjuk
megváltoztatni.</para>
<para>Az SGML elemzõ a dokumentum feldolgozása
során tárol egy ún. <quote>tartalmi
modellt</quote>.</para>
<para>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.</para>
<para>A két ilyen leghasznosabb tartalmi modell a
<literal>CDATA</literal> és az
<literal>RCDATA</literal>.</para>
<para>A <literal>CDATA</literal> jelentése
<quote>Character Data</quote>, vagyis <quote>karakteres
adat</quote>. Az elemzõ ebben a tartalmi modellben
kizárólag csak karaktereket lát. Ebben a
modellben a <literal>&lt;</literal> és
<literal>&amp;</literal> szimbólumok
elveszítik különleges
jelentésüket.</para>
<para>Az <literal>RCDATA</literal> jelentése
<quote>Entity references and character data</quote>, vagyis
<quote>egyedhivatkozások és karakteres
adatok</quote>. Ebben a tartalmi modellben az elemzõ
karakterekre <emphasis>és</emphasis> egyedekre
számít. A <literal>&lt;</literal>
szimbólum ilyenkor elveszíti a
különleges jelentését, azonban az
<literal>&amp;</literal> továbbra is
általános egyedek kezdetét fogja
jelölni.</para>
<para>Ezek használata különösen hasznos
abban az esetben, amikor rengeteg <literal>&lt;</literal>
és <literal>&amp;</literal> karaktert tartalmazó
nyers szöveget akarunk beilleszteni valahova a
dokumentumba. Természetesen ez megoldható
úgy is, ha minden <literal>&lt;</literal>
szimbólumot <literal>&amp;lt;</literal>
karaktersorozattá, illetve minden
<literal>&amp;</literal> szimbólumot
<literal>&amp;amp;</literal> karaktersorozattá
alakítunk, de sokkal könnyebb ezeket a szakaszokat
<literal>CDATA</literal> típusúnak
megjelölni. Az SGML elemzõk ilyenkor tehát
figyelmen kívül hagyják a tartalomban
talált <literal>&lt;</literal> és
<literal>&amp;</literal> szimbólumokat.</para>
<note>
<para>A <literal>CDATA</literal> vagy
<literal>RCDATA</literal> kulcsszavakat bemutató SGML
példákkal kapcsolatban megjegyezzük, hogy
a <literal>CDATA</literal> 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 <literal>CDATA</literal>
részbe.</para>
</note>
<example>
<title>CDATA típusú jelölt szakaszok
használata</title>
<programlisting>&lt;para>Ebben a példában láthatjuk hogyan tudunk sok &lt;literal>&amp;lt;&lt;/literal>
és &lt;literal>&amp;amp;&lt;/literal> szimbólumot tartalmazó szöveget elhelyezni
a dokumentumunkban. A minta most egy HTML kódrészlet lesz, az ezt övezõ
szöveg (&lt;para>) és (&lt;programlisting>) pedig DocBook.&lt;/para>
&lt;programlisting>
&lt;![CDATA[ <![CDATA[
<p>]]>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.<![CDATA[</p>
<ul>
<li>]]>Ez egy listaelem<![CDATA[</li>
<li>]]>Ez egy másik listaelem<![CDATA[</li>
<li>]]>Ez már egy harmadik listaelem<![CDATA[</li>
</ul>
<p>]]>Itt a vége a példának.<![CDATA[</p>]]>
]]&gt;
&lt;/programlisting></programlisting>
<para>Ha megnézzük a dokumentum
forrását, láthatjuk a
jelölésnél alkalmazott
megoldásokat.</para>
</example>
</sect3>
<sect3>
<title><literal>INCLUDE</literal> és
<literal>IGNORE</literal></title>
<para>Az <literal>INCLUDE</literal> kulcsszó
megadásakor a jelölt szakasz teljes tartalma
feldolgozódik. Ezzel szemben viszont az
<literal>IGNORE</literal> 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.</para>
<example>
<title>Az <literal>INCLUDE</literal> és
<literal>IGNORE</literal> használata jelölt
szakaszokban</title>
<programlisting>&lt;![ INCLUDE [
Ez a szöveg feldolgozódik és beillesztõdik.
]]&gt;
&lt;![ IGNORE [
Ez a szöveg nem dolgozódik fel és nem is illesztõdik be.
]]&gt;</programlisting>
</example>
<para>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.</para>
<para>Sokkal hasznosabbá válhatnak viszont a
számunkra, ha észrevesszük, hogy <link
linkend="sgml-primer-parameter-entities">paraméteregyedek</link>
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
<emphasis>pontosan</emphasis> egy ilyen SGML környezetben
vannak.</para>
<para>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.</para>
<para>Hozzunk létre egy paraméteregyedet és
legyen az értéke <literal>INCLUDE</literal>.
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.</para>
<para>Amikor a dokumentumot nyomtatásra akarjuk
elõkészíteni, akkor legyen a
paraméteregyed értéke
<literal>IGNORE</literal>, majd dolgozzuk fel újra az
egész dokumentumot.</para>
<example>
<title>Jelölt szakaszok vezérlése
paraméteregyeddel</title>
<programlisting>&lt;!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
&lt;!ENTITY % elektronikus.valtozat "INCLUDE">
]]&gt;
...
&lt;![ %elektronikus.valtozat [
Ez a rész csak a dokumentum elektronikus változatában fog megjelenni.
]]&gt;</programlisting>
<para>A nyomtatott változat
elõkészítésekor így
állítsuk át az egyed
értékét:</para>
<programlisting>&lt;!ENTITY % elektronikus.valtozat "IGNORE"></programlisting>
<para>A dokumentum újbóli feldolgozása
során a jelölt szakaszok a
<literal>%elektronikus.valtozat</literal>
értékét fogják
kulcsszóként megkapni, és így
kimaradnak.</para>
</example>
</sect3>
</sect2>
<sect2>
<title>Egy kis gyakorlás&hellip;</title>
<procedure>
<step>
<para>A következõ szöveggel hozzunk
létre egy állományt
<filename>szakasz.xml</filename> néven:</para>
<programlisting>&lt;!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
&lt;!ENTITY % szoveges.kimenet "INCLUDE">
]&gt;
&lt;html>
&lt;head>
&lt;title>Példa a jelölt szakaszok használatára&lt;/title>
&lt;/head>
&lt;body>
&lt;p>Ez a bekezdés &lt;![CDATA[sok-sok &lt;
karaktert (&lt; &lt; &lt; &lt; &lt;) tartalmaz, így érdemesebb
CDATA szakaszba tenni]]&gt;.&lt;/p>
&lt;![IGNORE[
&lt;p>Ez a bekezdés egyértelmûen nem fog látszódni az eredményben.&lt;/p>
]]&gt;
&lt;![ <![CDATA[%szoveges.kimenet]]> [
&lt;p>Ez a bekezdés nem fog feltétlenül megjelenni az eredményben.&lt;/p>
&lt;p>A konkrét megjelenését a <![CDATA[%szoveges.kimenet]]>
paraméteregyed értéke befolyásolja.&lt;/p>
]]&gt;
&lt;/body>
&lt;/html></programlisting>
</step>
<step>
<para>A <command>osgmlnorm</command>
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.</para>
</step>
<step>
<para>A <literal>szoveges.kimenet</literal>
értéke legyen <literal>INCLUDE</literal> az
<literal>IGNORE</literal> helyett. Futassuk le újra
így a normalizálást és
vizsgáljuk meg mi változott az
eredményben.</para>
</step>
</procedure>
</sect2>
</sect1>
<sect1 id="sgml-primer-conclusion">
<title>Befejezés</title>
<para>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.</para>
</sect1>
</chapter>