Standard Generalized Markup Language (Sgml): de basis voor het bekende Html, het gereedschap van elke web-ontwikkelaar. Het is ook de basis voor een nieuwe metataal, Extended Markup Language (eml) genaamd, terwijl Sgml ook aan de basis ligt van het document als database, ofwel de database die bestaat uit ogenschijnlijk ongestructureerde velden. Sgml wordt steeds belangrijker omdat meer en meer documenten, denk maar aan catalogi, platform- en machine-onafhankelijk worden uitgewisseld en gebruikt.Daarmee is niet gezegd dat Sgml een eenvoudige zaak is. Even gauw met Sgml een documentje in elkaar steken is er niet bij.
Het genereren van een document met Sgml is een complexe zaak. Deze metataal is dan ook in eerste instantie bedoeld voor professioneel gebruik. Sgml is zelfs een Iso-standaard (ISO-8879) voor het machine-onafhankelijk publiceren van teksten in elektronische vorm.
Sgml is een taal om elektronische markup te beschrijven. Onder markup wordt verstaan de code die in de tekst wordt geplaatst en die dient om de tekst op een bepaalde manier voor te stellen of om er een structuur aan te geven. Met markup verrijkt de auteur zijn tekst zodanig dat die steeds weer dezelfde structuur behoudt, ongeacht hoe vaak de tekst gewijzigd wordt.
Neem bijvoorbeeld een losbladig juridisch werk. Dat moet voor elk hoofdstuk, voor elke toevoeging of weglating, eenzelfde structuur hebben. Ook als er een dozijn auteurs aan werken. Een juridisch werk is op zich al ingewikkeld genoeg om te lezen. Een eenvoudige structuur maakt het de lezer dan tenminste iets gemakkelijker.
De ontwikkelaars van de metataal hadden daarbij vooral de hergebruiker voor ogen, de schrijver die de tekst van een ander moet aanvullen met zijn eigen werk.
Sgml ontstond in de jaren zestig, toen IBM-er Charles Goldfarb en zijn team een methode uitdachten voor het bewerken van tekst. Het heette toen nog gewoon Generalized Markup Language (gml) en het diende vooral om over verschillende platforms heen teamgewijs documenten te kunnen bewerken.
Na twintig jaar verfijnen en aanpassen werd gml in 1986 Sgml. De metataal kreeg toen ook zijn ISO-status. Vanaf dat moment werd Sgml steeds vaker gebruikt als metataal voor het samen bewerken van documenten in open omgevingen. De klemtoon kwam ook steeds meer te liggen op technische documenten. Sgml wordt nu vooral gebruikt in de vliegtuigbouw, de automobiel- en farmaceutische industrie, in de elektronica en telecommunicatie.
Beschrijven
Om een metataal te kunnen ontwikkelen, moest Goldfarb eerst weten hoe een document opgebouwd is. Een document bestaat uit drie typen informatie: de gegevens die ook beeld omvatten, de structuur waarmee de relatie tussen gegevenselementen wordt beschreven, en de formattering die bepaalt hoe het document eruit ziet. Sgml houdt zich bezig met de twee eerste typen informatie in een document: de gegevens en de structuur.
Er zijn drie eigenschappen waardoor Sgml zich onderscheidt van andere markup-talen. Allereerst is Sgml een beschrijvende taal, die zich weinig gelegen laat liggen aan procedures. Op de tweede plaats werkt deze metataal met het concept van een documenttype. Tenslotte is de metataal volkomen onafhankelijk van welk systeem ook om het script weer te geven waarin een tekst werd geschreven.
Het mooie aan de beschrijvende eigenschap van Sgml is dat zij de structuur van een document beschrijft, terwijl het formatteren kan worden overgelaten aan externe programma’s of procedures. Overigens kent iedereen die ooit een web-pagina heeft samengesteld, het soort beschrijvende markup die in Sgml wordt gebruikt. Labels als
Het onderscheiden van documenten in typen biedt het voordeel dat ze gemakkelijk verwerkt kunnen worden door computers op een van te voren vastgestelde manier. Als de Sgml-editorsoftware bijvoorbeeld een tekst voorgeschoteld krijgt met een titel, een of meer secties en tussenkoppen, ‘weet’ het dat het om een rapport gaat. Bijkomend voordeel van documenttypen is dat de schrijver geen onderdelen kan vergeten ‘in te vullen’. Als het documenttype voorschrijft dat na de titel eerst een sectiekop moet komen en daarna een paragraafkopje, dan laat de Sgml-tekstverwerker hem in principe niet toe het even gauw anders te doen.
Dat geeft dan weer aanleiding tot een consistentie in de opbouw van documenten die anders niet mogelijk is. De structuurregels kunnen nu eens heel flexibel zijn opgesteld, dan weer zo zijn opgebouwd dat interpretatie onmogelijk is. In dat laatste geval kunnen blokken tekst worden beschouwd als de velden van een relationele database, zodat zoeken op tekstblokken mogelijk wordt.
Dat is ook de reden waarom verschillende industrieën, waaronder de software-ontwikkelaars en bouwers van microprocessoren, hun eigen zeer uitgebreide documenttype-definities hebben uitgebouwd.
Het laatste grote voordeel van Sgml is de volledige uitwisselbaarheid tussen alle mogelijke hard- en softwareplatformen. Om die reden is ook het formatteren van teksten voor Sgml-schrijvers van ondergeschikt belang. Formatteringsprocedures zijn immers meer platformgebonden dan tekststructuren. Op het Mac-platform bijvoorbeeld hebben we Postscript en Colorsync, terwijl Colorsync op het Windows-platform niet eens bestaat, en de lettertypen er het liefst van het Truetype-soort zijn.
Een goed voorbeeld van hoe verschillend platform-onafhankelijke formatteringscodes geïnterpreteerd kunnen worden, merkt iedereen dagelijks op het Web, waar elke Html-browser een mooi opgebouwde Html-formattering anders weergeeft, terwijl de structuur van het document toch over alle platformen en browsers heen op dezelfde wijze wordt weergegeven.
De basis
De documenttype-definitie (dtd) is de basis waarop elk Sgml-document steunt voor de opbouw van een tekst. Ook Html-teksten hebben een dtd, zij het een impliciete en een wel erg simpele waarvan de inhoud en opbouw zijn vastgelegd door de Sgml-Workgroup. De dtd bepaalt welke elementen op elkaar moeten volgen. De DocBook dtd (de dtd die de software-industrie gebruikt voor het structureren van handleidingen) biedt een dwingend keurslijf. De schrijver of ontwerper van deze dtd heeft ervoor gezorgd dat de regels waaraan een tekst moet voldoen, erg formeel en strak zijn vastgelegd. Dat is de reden waarom de handleidingen van verschillende fabrikanten eenzelfde opbouw hebben.
Een dtd zelf is opgebouwd uit elementen. Het eigenaardige van Sgml is dat de elementen (de bouwstenen van de tekststructuur) schier onuitputtelijk kunnen zijn. De dtd-schrijver kan zelf namen geven aan zoveel elementen als hij zelf maar wenst. Elementen bestaan in Sgml trouwens alleen maar in relatie tot de andere elementen die in eenzelfde document gebruikt worden.
Zo is het enige dat over een element ‘blob’ gezegd kan worden, dat het mag voorkomen binnen het element ‘blurb’, en dat het zelf mag optreden als container van ‘blopje’-elementen. Sgml is een metataal waarin de dtd-schrijver zelf zijn alfabet samenstelt.
Het is aan de dtd-ontwerper om intuïtieve of gemakkelijk te onthouden omschrijvingen te verzinnen bij de elementen. Bij sommige dtd’s valt dat geweldig tegen. Kijk maar eens naar de dtd van de Amerikaanse Associatie van Krantenuitgevers. Die dtd bevat voor het merendeel elementen die tweeletter-acroniemen hebben als naam. Als een andere branche die dtd dus voor eigen gebruik zou willen aanpassen, wordt dat verschrikkelijk moeilijk omdat geen enkel acroniem ook maar enige verwijzing bevat naar termen die buiten de associatie bekend zijn.
Elke browser zijn Html
De mogelijkheid om regels te definiëren die aangeven welke elementen in andere genesteld kunnen worden, is een van de belangrijkste eigenschappen van Sgml. Het laat een verregaande verwerking toe door de computer. Een indexeringsprogramma kan bijvoorbeeld de relevante elementen terugzoeken door alleen elementen op te zoeken die in het derde geneste niveau voorkomen, een eenvoudig formatteringsprogramma kan bepaalde elementen bepaalde formatteringen toekennen, lege regels tussen bepaalde elementen inlassen, en ga zo maar door.
Daarmee is Sgml veel krachtiger dan Html, maar ook veel complexer. Bovendien kunnen met Sgml zoveel verschillende functies worden opgeroepen en aangestuurd, dat het voor iets eenvoudigs als het weergeven van wat gehyperlinkte tekst veel te ‘zwaar’ zou zijn. Vandaar de Html-subset, die overigens in onze tijd van Java-applets al lang niet meer voldoet aan de verwachtingen.
Dat leidde indirect tot de browser-oorlog. Elke ontwikkelaar voelde zich verplicht zijn eigen elementen toe te voegen aan de basisset, en liefst elementen die de concurrent niet begreep. Het resulteerde in de huidige chaos van frames en ander fraais dat Explorer net anders interpreteert dan Navigator.
Dat is een slechte zaak, want zo gaat het grootste voordeel van Html verloren: de platform- en machine-onafhankelijkheid. Html ging oorspronkelijk uit van de gedachte dat de formattering van de tekst moest worden overgelaten aan de browser omdat die de voorkeuren van de gebruiker ‘kent’. Precies zoals het een subset van Sgml betaamt.
Overigens zat de Sgml-Workgroup ook niet stil en kunnen Html-auteurs tegenwoordig rekenen op een sterk uitgebreide elementenset die zowel in Explorer als in Navigator bekend is. Dit neemt niet weg dat veel elementen toch anders geïnterpreteerd worden door de twee aartsvijanden. Dat maakt het schrijven van een webpagina een ingewikkelde en vooral tijdrovende zaak.
Die uitbreidingen stellen overigens niet veel voor. Zelfs bij het laatste speeltje, dynamic Html, blijven de ‘verbeteringen’ beperkt tot spielereien die meer met het grafische te maken hebben dan met inhoudelijke en formatteringsgerichte eigenschappen. In dHtml kan bijvoorbeeld in lagen worden gewerkt, waardoor bewegende beelden-knoppen ingedrukt worden, wanneer er op wordt geklikt.
Complex
Omdat de wildgroei van Microsoft- of Netscape-eigen Html-elementen het open karakter aantast van Internet, heeft de Sgml-Workgroup enige tijd geleden beslist om een nieuwe metataal uit te bouwen die voldoet aan de eisen van de moderne Html-schrijver. Extended Markup Language (Xxml) is wederom gebaseerd op Sgml en stelt de gebruiker in staat om zelf zijn markup-systeem samen te stellen. Een voordeel van Xxml ten opzichte van Sgml is dat het eenvoudiger is en dat een dtd niet strikt noodzakelijk is.
Omdat enerzijds voor veel mensen het schrijven van een dtd toch altijd wel een te grote uitdaging zal blijven, en het Web anderzijds niet voorbehouden is aan techneuten, besliste de Sgml-Workgroup dat het mogelijk moest zijn om met labels (tags) à la Html te werken. Door slim om te gaan met de codering van die labels, en onder de absolute voorwaarde dat de Html-schrijver de labels correct uitwerkt (in Xxml-jargon een ‘goed gevormd’ document), kan een Xxml-browser een document toch exact weergeven, zonder dat daarbij een dtd komt kijken. Omdat Xxml is ontworpen met in het achterhoofd elementensets die door de auteur zijn geschreven en niet door de ‘browserbakker’, zullen Microsoft en Netscape verplicht zijn hun browser ‘open’ te houden op straffe van onbruikbaarheid.
Maar Xxml gaat nog een stap verder en maakt ook ‘links’ mogelijk naar bestanden die met metataal niets te maken hebben. Vandaar de relatieve eenvoud om vanuit een Xxml-pagina een applet op te starten. Er zijn geen scripts of andere tovertrucs meer nodig. Hetzelfde geldt trouwens voor het publiceren van databases, iets wat de meeste ondernemingen die e-commerce willen bedrijven nu in strikt programmatische context moeten verwezenlijken. Omdat Xxml sterk aanleunt bij Sgml -veel sterker dan Html dat deed- kan het document in zekere zin de database zelf zijn.
Eén probleem lost Xxml nog steeds niet op. Dat is de weergave van formattering op het scherm. Nu is dat één van de grootste problemen waarmee een Html-schrijver wordt geconfronteerd. Sgml biedt daarvoor ook geen oplossing tenzij in de vorm van een dsssl-stylesheet (Document Style Semantics and Specification Language). Dsssl is echter een ontzettend ingewikkelde programmeertaal die gebaseerd is op Scheme, een Lisp-variant. De Sgml-Workgroup besliste daarom dat een vereenvoudigde versie van dsssl het formatteringswerk zal moeten doen voor een mooie weergave van documenten op het scherm.
Xxml biedt vele voordelen. Zo wordt het opdelen van documenten in voor de computer terugzoekbare brokken veel eenvoudiger. Dat leidt tot veel efficiëntere zoekrobots. Er bestaan nu al Sgml-zoektalen (query languages) die even krachtig zijn als SQL, en de evolutie op dat terrein is nog niet ten einde. Met Xxml kunt u in de nabije toekomst dus wellicht uiterst gericht zoeken naar een term en zeer exacte matches terugkrijgen van Altavista of Infoseek, of welke zoekmachine ook uw voorkeur heeft.
En PDF?
Als we over documenten spreken en platformonafhankelijke weergaven, dan mogen we natuurlijk Acrobat niet vergeten. Adobe’s Acrobat Portable Document Format is evenwel geen metataal om structuren mee te beschrijven. Het is een technologie die een accurate distributie van documenten toelaat zonder dat de gebruiker zich om platforms hoeft te bekommeren. Terwijl Sgml zich niets aantrekt van de layout van een document, is dat voor Acrobat het meest essentiële.
PDF wordt gebruikt om documenten in hun definitieve vorm te verdelen of te archiveren, ongeacht het platform waarop ze werden aangemaakt of het programma waarin dat gebeurde. Eenmaal geconverteerd naar PDF, is het document – op details na – niet meer te wijzigen. Voor het hergebruik van documenten en het uitwisselen ervan is Acrobat dus niet geschikt. Daar is het ook nooit voor bedoeld. Ook voor indexeringsdoeleinden is PDF vrij licht. Er is natuurlijk wel de bookmark-functie en de Catalog-applicatie, maar in vergelijking tot wat met Sgml kan, is dat aan de lichte kant. PDF is overigens nog niet ISO-, maar wel DIN-gecertificeerd.
Xxml versus Html
Wat Xxml wel kan, en Html niet:
Voordelen van Sgml
Investeringen in het aanmaken van documenten worden beschermd. ‘Opgesloten’ raken in de oplossing van een of andere ontwikkelaar is niet mogelijk.
Herbruikbaarheid van gegevens. Door gegevens te taggen met labels die het doel ervan omschrijven, zijn die ook in te passen in andere documenten. Bijvoorbeeld een tekstblok uit een white paper is opnieuw te gebruiken in een brochure.
Alle Sgml-toepassingen werken op ongeveer dezelfde manier. Zo is altijd het beste product te kiezen.
Erik Vlietinck, freelance medewerker Computable