Domokos László
      Az SGML és az információs forradalom

      Jó néhány nagy szervezetnél létezik egy úgynevezett virtuális feneketlen hordó, amelyben jelentős összegek tűnnek el. A hordó neve rendszerint „dokumentálás” vagy „belső információs rendszer”. A pénzeket olyan feladatokra fordítják, mint a tervezés, az írás, az ellenőrzés, a korrekció, a keresés, a konvertálás, a formázás és a nyomtatás. Ez a folyamat azután minden apróbb termék-, piac- és információváltozásnál újra és újra lejátszódik. A lényeg pedig eltűnik ebben a hordóban: a munkatársak tapasztalata, tudása és észrevételei - egyszóval az információ. Az az információ, amely a vállalatot versenyképesebbé és sikeresebbé tehetné. Eltűnik, mert pusztán kiadványok készülnek jól kezelhető információ helyett.
      Az SGML olyan technológia, amely a dokumentumok és a bennük foglalt információ felett korábban nem tapasztalt uralmat nyújt.

      Szöveghalmaz
      Minden új technológiára jellemző, hogy először a meglévő folyamatok gyorsítására, automatizálására használják, s csak ezt követően kerül sor forradalmian új lehetőségek megteremtésére.
      Ez a folyamat jól megfigyelhető az információfeldolgozásban is. Gondoljunk csak arra, hogy a kezdeti állomány- és rekordorientált adatfeldolgozás mellé miként léptek be a gyökeresen új adatbázisok. Ezzel együtt járt olyan szakmák megjelenése, mint az adatbázis-tervezés, adatbázis-menedzser stb. Kialakultak az adatbázisok szabványos modelljei, például a relációs modell, a szabványos lekérdezések és felületek (SQL, ODBC). Mindezek elősegítették a táblázatszerű rendszerbe foglalt adatok feldolgozását.
      És mi a helyzet a szöveges információ területén? A kérdés fontos, hiszen az információk döntő hányada nem táblázatos, hanem szabad szöveges formában készül. A számítógépek természetesen itt is hatalmas változást idéztek elő. Egyre-másra jelennek meg és tűnnek el a különböző szövegszerkesztő programok, amelyek egyre többet tudnak, s gyakorlatilag nyomdai minőségű kiadványokat készíthetünk velük. Valójában azonban ezek a programok nem mások, mint fantasztikus tudású, jól kezelhető, klasszikus írógépek.Mesterien megformált oldalakat készíthetünk velük, de nem többet. Az általuk nap mint nap kezelt adatmennyiség gigantikus. A probléma abban rejlik, hogy a létrehozott állományok csak arra használhatók hatékonyan, amire készültek, vagyis a szöveg oldalakon való megjelenítésére, ráadásul általában csak annak a gyártónak a szoftverével, amivel készültek. Más gyártmányú szoftver, sőt sok esetben az azonosnak egy másik verziója is problémát okoz. Rossz rágondolni mi lesz a Worddel és más hasonló programokkal írt állományokkal tíz-húsz év múlva! Sok száz millió oldalt kitevő tudásanyag van beágyazva egy-egy szoftvergyártó cég saját, állandóan változó, alig dokumentált, oldalszemléletű, tipográfia utasításokkal teletűzdelt formátumaiba.
      Aki adatfeldolgozással foglalkozik, hamar megtapasztalja, hogy az idegen, nem dokumentált állományok konverziója mennyire időigényes feladat. A nehézség rendkívüli is lehet, ha például az előállító szoftvernek már a gyártója sem létezik. Gondoljunk csak az egykor oly népszerű Wordstarral készült állományokra!
      Mi a jövő, van-e ezekre a kérdésekre megoldás? Milyen elvárásaink lehetnek?
      A relációs modell analógiáját folytatva, a következő igényeket támaszthatjuk:

  1. Legyen az információ (a továbbiakban információ alatt szöveges információt értünk) szerkezete tervezhető. Legyen olyan elfogadott szabvány, amellyel az ember és a gép számára le lehet írni az információ szerkezetét, meg lehessen jelölni a felhasználás számára lényeges elemeket.
  2. Legyen az információ tárolására általánosan elfogadott, dokumentált, gyártófüggetlen szabvány.
  3. Az információ legyen számítógéppel könnyen feldolgozható.
  4. A kívánt információt gyorsan, pontosan meg lehessen találni
  5. A tárolt információ legyen hordozható.
  6. A tárolt információ legyen sokoldalúan újrafelhasználható.

      Szerkezetleírás
      A megoldás régóta létezik. Ez pedig nem más, mint az SGML nemzetközi szabvány, illetve annak az utóbbi hónapokban egyre többet hallható XML leszűkítése.
      Az SGML (Standard Generalized Markup Language, amelyet magyarra általános szabványos kijelölő nyelvként fordíthatunk) kialakulása a hetvenes-nyolcvanas évekre nyúlik vissza. Kidolgozásának mozgatórugója az volt, hogy a korán erősen számítógépesített, nagy és több részlegből álló, ill. sok beszállítóval rendelkező vállalatok hamar megtapasztalták: az elektronikus formában érkező dokumentumok egységes gépesített feldolgozása gyakorlatilag lehetetlen. Ennek oka nemcsak a dokumentumok formátumbeli eltérése volt, hanem belső szerkezetük heterogenitása és a dokumentumok elemeinek azonosítatlansága is. A probléma megoldására született SGML 1986 óta nemzetközi ISO szabvány (ISO 8879:1986). Az SGML az IBM-nél már korábban is használatos GML továbbfejlesztése.
      A szabvány két fő részből áll: az információ szerkezetének megadására szolgáló metanyelvből és az SGML dokumentumok tárolási formátumának leírásából. Ezen túlmenően a szabvány kitér több technikai kérdésre, amelyek ismertetésétől itt eltekintünk. Ilyen például az úgynevezett SGML deklaráció, amely az alkalmazás konfigurálására, az alapértékek (default) felülírására használatos. Az SGML szabvány nem rendelkezik az információ megjelenítéséről. Erre jelenleg egyéb szabványok, ill. eszközfüggő egyéni megoldások használatosak.
      Az SGML technológia alkalmazásakor az egyik leglényegesebb feladat a dokumentumok típusokra osztása és ezen típusok szerkezetének leírása, azaz a DTD - dokumentumtípus-definició - elkészítése. Erre szolgál az SGML szabványban rögzített metanyelv. A DTD ún. tartalmazási modellje megadja, hogy az adott típusú dokumentum milyen kötelező vagy opcionális elemekből áll. Az elemekre ismétlődési és sorrendi megkötések szabhatók. A DTD leírja továbbá az elemekhez rendelhető úgynevezett attribútumokat, hivatkozásokat a dokumentumon belüli és kívüli objektumokra. Ugyancsak a DTD adja meg a dokumentumban használható úgynevezett entity-ket. Ezek speciális karakterek, hosszabb sztringek, és az állományon kívüli szövegrészek, elemcsoportok, képek, táblázatok, stb. jelölésére szolgálnak.
      A DTD természete jól nyomon követhető a Byte Magyarország cikkeinek szerkezetén át (lásd 1. keretes cikkünket).

A BYTE esete az SGML-lel

Az alábbi DTD leegyszerűsítve, a teljesség igénye nélkül a BYTE Magyarország cikkeinek szerkezetét mutatja.

<!DOCTYPE ByteCikk [ [1]
<!ELEMENT ByteCikk - - (Admin? , Fej , Test , KeretesIras* , Alairas+) > [2]
<!ELEMENT Admin - - (ErkDatum , Statusz? , Megjelent?) >
<!ELEMENT Fej - - (RovatNev , Tema , Absztrakt? , SzerzoNeve+ , Cim) >
<!ELEMENT Test - - (Resz , (ReszCim , Resz)*) >
<!ELEMENT Para - - ((#PCDATA) | Kep | Kiemeles | Kulcsszo | Lista)+ >
<!ELEMENT Kep - - (KepObjekt , KepAlairas) >
<!ELEMENT Alairas - - (Beosztas? , SzerzoNev , EmailCim?) >
<!ELEMENT Megjelent - - (Ev , Honap) >
<!ELEMENT Ev - - (#PCDATA) > [3]
<!ELEMENT Resz - - (Para+) >
<!ELEMENT Honap - - (#PCDATA) >
<!ELEMENT EmailCim - - (#PCDATA) >
<!ELEMENT SzerzoNev - - (#PCDATA) >
<!ELEMENT Beosztas - - (#PCDATA) >
<!ELEMENT KeretesIras - - (Resz? | .....) >
<!ELEMENT Lista - - (#PCDATA) >
<!ELEMENT Kulcsszo - - (#PCDATA) >
<!ELEMENT Kiemeles - - (#PCDATA) >
<!ELEMENT KepAlairas - - (#PCDATA) >
<!ELEMENT ReszCim - - (#PCDATA) >
<!ELEMENT Cim - - (#PCDATA) >
<!ELEMENT SzerzoNeve - - (#PCDATA) >
<!ELEMENT Absztrakt - - (#PCDATA) >
<!ELEMENT Tema - - (#PCDATA) >
<!ELEMENT ErkDatum - - (#PCDATA) >
<!ELEMENT RovatNev - - (#PCDATA) >
<!ELEMENT Statusz - - (#PCDATA) >
<!ELEMENT KepObjekt - - EMPTY >
<!ATTLIST Statusz allapot ("NYERS","KONTROLLALT","KESZ") NYERS > [4]
<!ATTLIST KepObjekt KepNev ENTITY #REQUIRED > [5]
]>

 

A cikkek szerkezete grafikusan ábrázolva:

      Ez a DTD a következőképpen értelmezendő:

[1] A DTD a „ByteCikk” típusú dokumentumok szerkezetére vonatkozik
[2] A „ByteCikk” elem a megadott sorrendben tartalmazza az opcionális „Admin”, a kötelező „Fej”, „Test”, az opcionális és ismételhető „Keretesiras” és végül a kötelező és ismételhető „Aláírás” elemeket.
[3] A #PCDATA szabad szöveget jelent (a félreérthető delimeterként alkalmazott jelekre megkötések érvényesek)
[4] Az „Allapot” a „Statusz” elemhez tartozó úgynevezett attribútum, amelynek lehetséges értékei „NYERS”, „KONTROLLALT”, „KÉSZ”, a default érték pedig „NYERS”.
[5] A „KepObjekt” elem „KepNev” attribútuma egy ún. entity referencia, amelynek értéke - általában egy fájl azonosító - a hivatkozott kép helyét adja meg.

      A DTD-t vizsgálva a következő megfigyeléseket tehetjük:

      A keretes példa természetesen nem meríti ki az összes lehetőséget. Ezek felsorolása azonban messze túlhaladná ezen cikk terjedelmét. A lényeg azonban nyilvánvaló. A DTD a dokumentumok tartalmi szerkezetének tervrajzaként tekinthető. Fontos megemlíteni, hogy az SGML-es eszközök, mint a szerkesztő programok, a DTD-t aktívan használják. Az SGML szövegszerkesztő program nem engedi meg például, hogy a „ByteCikk” elem „Nev” elemet tartalmazzon, megköveteli viszont, hogy a „ByteCikk”-en belül kötelező elemeket megadjuk Hasonlóan, az SGML parser programok a DTD-t felhasználva ellenőrzik, hogy az adott dokumentum szerkezete szintaktikailag és szemantikailag helyes-e.
      A DTD tervezés az SGML alkalmazások meghatározó feladata, amely nagy szaktudást igényel. A tervezéskor általában nem csak meglévő dokumentumokat, hanem jövőre vonatkozó igényeket, a feldolgozás folyamatát, az információ használatát és mozgását is figyelembe kell venni. Ennek elvégzésére új szakma, az information architect és az information engineer vannak kialakulóban. Nem ritkaság, hogy komplex DTD tervezési feladatok hónapokat, sőt éveket vesznek igénybe. A munkát segítheti, hogy elkészült több szabványosított, vagy de facto szabványnak tekintett DTD. Ezek a rendszerint igen bonyolult DTD-k akár közvetlenül is használhatók, vagy kiindulásul szolgálhatnak egy egyszerűsített, testre szabott változat elkészítéséhez. Példaként említhető az ISO 12083 Book DTD, amely általános könyvek leírására szolgál, vagy a CALS program keretében, a hadiipar technikai dokumentációs igényeire kifejlesztett MIN-STD-38784 DTD család.
      Minden bizonnyal a legszélesebb körben használt SGML dokumentum típus a HTML. Az Internet közismert nyelve ugyanis nem más, mint egy SGML alkalmazás, amely az általánosság igényét kielégítve elsősorban dokumentumszerkezeti (cím, lista, hivatkozás), és nem tartalmi elemeket használ. A HTML DTD karbantartását, dokumentálását a World Wide Web Consortium (W3C) végzi.

      Az SGML formátum
      Az (ISO 8879:1976) SGML szabvány második része a SGML-ben készült dokumentumok tárolási formátumát rögzíti. Mivel a HTML egyben SGML is, a formátum valószínűleg széleskörűen ismert. Lényege az, hogy az elemek kezdetét <elemnév>-vel, a végét pedig </elemnév>-vel jelöljük. Ezeket az angol „tag” fordításaként címkének nevezzük. A DTD-ben megengedhetjük a kezdő- és/vagy a végcímke elhagyását. A címke elhagyása - amit korábban a szűkös tárkapacitás kímélésére használtak - ma már egyre kevésbé szokás.
      Az SGML formátum megelégszik az egységesen használt 7 bites ASCII karakterek alkalmazásával. Minden egyéb karaktert, így pl. az ékezetes vagy görög betűket entityként lehet megadni. Az entity formája egy '&' és ';' karakterekkel határolt azonosító. Például az 'ő', 'É', 'ö' és 'ß' karakterek reprezentációi: &odblac; &Eacute; &ouml; és &beta;. Az ismert nyelvek betűi és sok egyéb általánosan használt speciális karakternek ISO szabványosított entityneve van. Amennyiben más nevet vagy egyéb karaktert akarunk entityként megadni, akkor ezt a DTD-ben jelezni kell. A HTML DTD például nem engedi meg a magyarban használatos 'ő', 'Ő', 'ű' és 'Ű' betűket leíró &odblac; &Odblac; &udblac; és &Udblac; egyedek használatát.
      Fontos, hogy az SGML állományok csak 7 bites ASCII karaktereket tartalmaznak, hiszen ez garantálja a tökéletes hordozhatóságot az ASCII és EBCDIC platformok között! Meg kell jegyezni, hogy ezzel „csupán” az információ hordozhatóságát oldották meg. A különböző karakterek helyes megjelenítése a képernyőn vagy nyomtatásban már az SGML-t feldolgozó szoftver feladata.
      Láthatjuk, hogy az SGML szabvány sem a DTD-ben, sem a tárolási formátumban nem rendelkezik a dokumentum papíron, képernyőn vagy egyéb eszközön való megjelenítéséről. A klasszikus szövegszerkesztőkhöz (Wordhöz, WordStarhoz, WordPróhoz stb.) szokott felhasználók ezt hiányosságként értékelhetik, pedig nem az. Éppen ellenkezőleg, az SGML filozófiájának lényege a tartalom és forma elválasztása. Az információ, amely a klasszikus, írógépszerű feldolgozásnál egy oldalközpontú szemlélet által vezérelt formátumba van beágyazva, az SGML-nél független az ábrázolástól. Ez lehetővé teszi, hogy az információ annak bármiféle változtatása nélkül a mindenkori technikának és médiának megfelelő módon legyen ábrázolható. Ez úgynevezett stíluslapok elkészítésével történhet, ami lényegében a tartalmi elemekhez megjelenítési információ hozzárendelését jelenti.
      Ezen egyszerű eljárás hallatlan előnyei nyilvánvalóak: egyetlen stíluslappal az adott dokumentumtípushoz tartozó összes, több ezer vagy akár több millió dokumentum megjelenítését egységes módon meghatározhatjuk Ugyanakkor egy dokumentumtípushoz tetszőleges számú stíluslapot lehet rendelni. Ezáltal egy dokumentum annak megváltoztatása nélkül különböző formában, sőt különböző tartalommal jeleníthető meg. A fenti példánál maradva, a szerkesztőségnél használt stíluslap megmutatja a belső használatra szánt adminisztrációs „Admin” elem tartalmát, a nyomtatott formát készítő tördelő program által használt stíluslap viszont nem.

      Jön az XML
      A stíluslapok szerkezetét a nemrég kidolgozott DSSSL (Document Style and Semantics Specification Language) szabvány dokumentálja. Ennek használata azonban, részben bonyolultsága és újdonsága miatt, még nem általános, ezért a stíluslapok hordozhatósága korlátozott.
      A tartalom szerint strukturált, alkalmazás-semleges tárolás szavatolja, hogy az SGML adatokból könnyen készíthető nyomtatott mű, Internet/intranet információszolgáltatás, jól kereshető adatbázis vagy CD.
      Példaként itt látható ezen cikknek néhány részlete a fentebb mutatott DTD-szerinti SGML formátumban, már a szerkesztés után.

A megszerkesztett cikk DTD formában

<ByteCikk> <Admin>
      <Statusz állapot="KONTROLLALT"></Statusz>
</Admin>

<Fej>

<RovatNev>......</RovatNev>
<Téma>.......</Téma>
<SzerzoNeve></SzerzoNeve>
<Cim>SGML &eacute;s az inform&aacute;ci&oacute;s forradalom</Cim>
</Fej>

<Test>

<Resz><Para> Sok nagy szervezetn&eacute;l&eacute;tezik egy virtu&aacute;lis feneketlen hord&oacute;, ....</Para>....</Resz>
<ReszCim>Mi az SGML</ReszCim>
<Resz><Para> Az SGML .....<Para>...... </Resz>
</Test>

<Alairas>

......
<EmailCim>step@step.hu</EmailCim>
</Alairas>

</ByteCikk>

 

      A ma Magyarországon kevéssé ismert SGML népszerűsége gyorsan növekszik. Angol nyelvterületeken, különösen Amerikában az olyan iparágakban mint az autó-, repülőgép- és hadiipar, az SGML használata előírás. Számos egyéb területen - könyvkiadók, államigazgatás, távközlés, lapkagyártás, gyógyszeripar, szabadalmi hivatalok, nyelvészet, stb. - egyre szélesebb körben használatos.
      Az Internet hallatlan népszerűsége nem kis mértékben egy SGML alkalmazásnak, a HTML-nek köszönhető. A HTML ereje könnyű kezelhetőségében, hardver- és szoftvergyártóktól való (majdnem) függetlenségében rejlik. Mindezek az SGML tulajdonságai is. A HTML egyre szorítóbb béklyóit az SGML-nek egy egyszerűsített, leszűkített és a webes alkalmazásokra optimalizált változata, az XML (eXtensible Markup Language) hivatott megoldani. Az SGML/XML technológia minden bizonnyal hatalmas fejlődés előtt áll, s ez az információ kezelésében további távlatokat nyit.

      Domokos László ügyvezető, EMPOLIS Kft.
      E-mail: laszlo.domokos@empolis.hu