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 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 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 < karaktersorozattá, illetve minden & szimbólumot & 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.
Megjegyzés: 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.
Példa 3-15. CDATA típusú jelölt szakaszok használata
<para>Ebben a példában láthatjuk hogyan tudunk sok <literal><</literal>
és <literal>&</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[
<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.</p>
<ul>
<li>Ez egy listaelem</li>
<li>Ez egy másik listaelem</li>
<li>Ez már egy harmadik listaelem</li>
</ul>
<p>Itt a vége a példának.</p>
]]>
</programlisting>Ha megnézzük a dokumentum forrását, láthatjuk a jelölésnél alkalmazott megoldásokat.
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.
Példa 3-16. Az INCLUDE és IGNORE 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.
Példa 3-17. 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.
A következő szöveggel hozzunk létre egy állományt szakasz.xml 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>
]]>
<![ %szoveges.kimenet [
<p>Ez a bekezdés nem fog feltétlenül megjelenni az eredményben.</p>
<p>A konkrét megjelenését a %szoveges.kimenet
paraméteregyed értéke befolyásolja.</p>
]]>
</body>
</html>A osgmlnorm 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.
Ha kérdése van a FreeBSD-vel kapcsolatban, a következő
címre írhat (angolul): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése,
kérjük erre a címre írjon: <gabor@FreeBSD.org>.