In de beschrijvingen van de SGML-produkten zijn begrippen en termen gebruikt die de beschrijvingen kort en overzichtelijk houden, maar die op het eerste gezicht niet echt duidelijk zijn voor niet-ingewijden. Deze paragraaf is bedoeld ter verduidelijking en om uit te leggen waarom juist deze begrippen gekozen zijn om de software mee te beoordelen.
Hoewel SGML al sinds 1986 een internationale standaard is (ISO 8879), is er eigenlijk pas de laatste paar jaar duidelijk interesse voor. Blijkbaar is SGML een idee waarvoor de tijd rijp is. De stormachtige ontwikkeling van het World-Wide Web (WWW) sinds 1993 heeft daaraan in niet geringe mate bijgedragen. Het valt te verwachten dat `het Web' ook de komende jaren de voornaamste motor achter SGML zal zijn.
Wat zijn die eigenschappen van SGML (en van het WWW) die nu plotseling zo belangrijk worden gevonden? Ten eerste is dat de portabiliteit: omdat SGML een internationale standaard is en omdat SGML-documenten gewone tekstfiles zijn, is een SGML-file op elke computer te gebruiken, en ook nog steeds over 20 of 30 jaar. Die overdraagbaarheid is pas echt belangrijk geworden toen iedereen een netwerk kreeg.
Overigens is SGML niet de hele oplossing voor het probleem van de portabiliteit. Een belangrijk aspect waarvoor pas onlangs een oplossing is bedacht is het weergeven en transporteren van niet-westerse schriften. Geen van de onderzochte programma's kan er nog mee overweg, maar vanaf 1996 zal waarschijnlijk de nieuwe standaard ISO 10646 (beter bekend als Unicode) een grote vlucht gaan nemen. Overigens is het ook op dit moment wel mogelijk vreemde tekens op te nemen, m.b.v. entities, maar dat is omslachtig: é wordt é, Griekse tekst wordt &agr;&bgr;&ggr; (alfa, beta, gamma). Sommige produkten kunnen aparte fonts aan dergelijke entities koppelen.
Een tweede aspect van SGML is de scheiding van inhoud, structuur en presentatie. SGML dient in principe alleen voor de eerste twee. Vóór de tijd van de computer was er geen mogelijkheid de presentatie te scheiden. Je kon natuurlijk een boek wel op twee verschillende manieren drukken, maar gebruikelijk was dat niet. Misschien dat er in het hoofd van schrijver of lezer wel een abstract soort informatie bestond die zonder presentatie kon, maar overdraagbaar was die niet.
De computer kan wel met vormeloze data overweg; mòèt dat ook wel, want met beelden hij niets. Hij kan wel printen, maar hij kan niet lezen wat hij heeft geprint. Een database is het duidelijkste voorbeeld: de gegevens kunnen op vele manieren worden getoond, maar intern hebben ze geen vorm. SGML wordt daarom wel eens vergeleken met een database voor tekst. Er is echter wel een probleem: de makers van SGML hebben het ontwerpen van de presentatie-component destijds uitgesteld, tot 1995 zoals we inmiddels weten. Dat betekent dat je nu de inhoud en structuur van documenten kunt opslaan, maar als je ook wilt vastleggen hoe je wilt dat het er voor mensen uitziet, ben je aangewezen op niet-gestandaardiseerde, proprietary methoden.
Dit is het probleem dat wordt aangeduid met de term style-sheets. Een style-sheet is een abstracte beschrijving van een layout. Wanneer een style-sheet wordt gecombineerd met en document (`toegepast op'), ontstaat een geformatteerde tekst, een tekst dus die voor mensen leesbaar is.
Zoals gezegd is er in 1995 een ISO-standaard voor style-sheets gekomen, onder de naam DSSSL (Document Style Semantics and Specification Language, ISO 10179). DSSSL zal de komende jaren wel gebruikt gaan worden door verschillende software-fabrikanten, maar er is een probleem: terwijl SGML uitstekend met het Web is te combineren, lukt dat met DSSSL veel minder. Verschillende mensen zijn daarom op zoek naar een oplossing voor real-time, on-screen style-sheets, daaronder het WWW Consortium (W3C). Eind 1995 moet duidelijk zijn wat de belangrijkste style-talen op het WWW zullen zijn.
Een derde aspect van SGML is z'n flexibiliteit. SGML is eigenlijk geen formaat, maar een recept om formaten te maken. En hoewel we voor het gemak spreken van een `SGML-file', is dat strikt genomen een file in een formaat dat m.b.v. SGML is gedefiniëerd. HTML (HyperText Markup Language) is zo'n formaat. Het is het meestgebruikte formaat op het Web, omdat het simpel is en bovendien hypertext (zie onder) ondersteund.
Natuurlijk wil je niet voor elk document een nieuwe structuur bedenken. Er zijn een aantal veelgebruikte formaten (officieel: Document Type Definitions, of DTD's). Behalve HTML zijn dat bijvoorbeeld Text Encoding Initiative (TEI) en TEI-Lite, CALS (Continuous Acquisition and Lifecycle Support), Docbook en ISO 12083.
CALS is van het Amerikaanse ministerie van defensie (DoD). Het is complex en omvangrijk en als je niet voor het DoD werkt geen aanrader. Eén onderdeel van CALS zorgt momenteel (zomer 1995) voor veel discussie en dat is het formaat voor tabellen. Dat komt omdat het W3C binnenkort een formaat voor tabellen aan HTML wil toevoegen en de mensen die al grote bestanden in CALS-formaat hebben willen de CALS-tabellen graag handhaven. Hopelijk gaat dat niet door, want het is een onmogelijk formaat, dat nog stamt uit de tijd dat de makers ervan niet wisten wat style-sheets zijn of hoe elektronisch publiceren in z'n werk gaat.
Een groter contrast dan tussen CALS en TEI is nauwelijks denkbaar. TEI is ook omvangrijk, maar allesbehalve complex. TEI (Text Encoding Initiative) was de naam van een groep onderzoekers uit de taal- en literatuurwetenschap. In 1994 heeft ze zichzelf opgeheven, na het voltooien van de TEI DTD, aangeduid als TEI-P3, ter onderscheiding van eerdere versies P1 en P2. De TEI DTD bestaat uit verschillende modules, die met elkaar zo'n beetje elk soort tekst kunnen coderen die een alfa-wetenschapper ooit onder handen krijgt, van eenvoudige memo's tot tekstkritische edities, corpora voor grammatica-onderzoek en zelfs hypertext.
TEI wint snel aan populariteit en wordt ook buiten de wetenschappelijke wereld gezien als het voorbeeld van een goede DTD. Als SGML-formaat is TEI automatisch compatible met de meeste SGML-software, maar verscheidene fabrikanten hebben ook speciale voorzieningen ingebouwd. Bijvoorbeeld de hypertext-mogelijkheden van TEI zijn daardoor ook in andere DTD's te gebruiken.
Docbook is speciaal gemaakt voor computer-manuals, is daarvoor zeer geschikt, maar niet erg van belang voor wie zich met andersoortige teksten bezig houdt. ISO 12083 is ontwikkeld door Amerikaanse uitgevers, maar wordt ook buiten Amerika gebruikt. Het is een tamelijk neutraal formaat, geschikt voor boeken, tijdschriften en artikelen. Het formaat is weinig gedetailleerd, omdat het uiteindelijk bedoeld is voor drukwerk, niet voor analyse of on-line raadpleging.
Hypertext is al even genoemd. Ook dat is zo'n idee waarvoor de tijd rijp is. Opmerkelijk genoeg is het een idee dat al bestond vóór de boekdrukkunst, maar dat door de technische beperkingen van het boek vergeten is geraakt. Encyclopedieën lijken er nog wel op, met hun vele verwijzingen. De computer heeft hypertext niet alleen teruggebracht, maar ook aanzienlijk verbeterd: niet alleen zijn verwijzingen naar van alles en nog wat eenvoudig te maken en te onderhouden, de computer maakt ook het vervelende heen en weer bladeren overbodig.
De makers van SGML hebben ook voor hypertext een standaard gemaakt, genaamd HyTime (Hypermedia/Time-based language, ISO 10744, 1992). Ook die is niet vrij van problemen, al zijn delen ervan wel bruikbaar. Er zijn twee belangrijke concurrenten: de ene is de al genoemde TEI, met name TEI's extended pointer (xptr), de ander is de methode van het WWW. Die laatste heet Uniform Resource Locator (URL) en is verreweg de populairste, vooral omdat hij zo'n groot bereik heeft. Zo'n beetje alles wat zich op het Internet bevindt kan via met URL worden aangeduid. Daar staat tegenover dat URL's niet zo nauwkeurig zijn, want je kunt wel naar een document wijzen, maar meestal niet naar een onderdeel ervan. TEI's xptr kan dat wel. Helaas zijn URL's en xptr's niet compatibel met HyTime, tenminste nog niet, want er is een wijziging van HyTime beloofd voor 1996. De toevoeging van een nieuw element aan HyTime moet ervoor zorgen dat een HyTime-applicatie URL's en xptr's als zodanig kan herkennen.
Voor een SGML-systeem zijn heel wat files nodig, dus een goed filebeheerssysteem is essentieel. Behalve de documenten zelf zijn er de verschillende DTD's, gemeenschappelijke files met entities (meestal bijzondere symbolen), style-sheets en vaak nog meer.
Wegens de portabiliteit hebben veel van de files een (formal) public identifier (FPI), een naam die niet afhangt van de toevallige computer waarop de file zich bevindt. Dat betekent wel dat de software de FPI moet vertalen naar een concrete file-naam. Gelukkig gebruiken steeds meer programma's daarvoor dezelfde methode: een catalog-file volgens de conventies die zijn opgesteld door SGML-Open, een organisatie van software-fabrikanten. De meeste gebruikers zullen op den duur immers verscheidene SGML-programma's bezitten en het is prettig als die elkaars files kunnen gebruiken.
Het gebruik van FPI's maakt het verspreiden van SGML-files makkelijker. Als een file wordt aangeduid met een FPI kan de applicatie die file halen van de meest geschikte plaats, soms is dat een lokale disk, soms het netwerk. Elke kopie is immers gelijk, onafhankelijk van de plaats waar hij is opgeslagen.
Op de PC (DOS en Windows) is die situatie nog niet bereikt. Dat platform heeft te kampen met een traditie van proprietary formaten, ingegeven door beperkte geheugens en langzame computers. Er zijn nog veel kleine PC's in gebruik en de traditie verdwijnt slechts langzaam.
Een deel van de software zijn overgangsprodukten, bedoeld om documenten in oude formaten (zie onder) om te zetten naar SGML. Veel van de oude formaten zijn nooit bedoeld geweest voor elektronisch publiceren en het kost veel moeite om uit de visuele informatie (vet, cursief, lettergrootte, enz.) de structurele te distilleren. Naarmate SGML door meer fabrikanten en gebruikers wordt geaccepteerd zal de noodzaak voor deze conversie-software afnemen.
Helemaal verdwijnen zal die noodzaak niet en de term `overgangsprodukt' is dan ook te beperkt. Bijvoorbeeld boeken die gescand worden zullen altijd op grond van visuele informatie moeten worden geconverteerd, er is immers geen andere informatie.
Uit het aanbod van SGML-produkten is een selectie gemaakt, op grond van de bekendheid van het produkt en eerdere ervaringen. Enkele ervan konden niet op tijd worden geleverd. Dit is de lijst, geordend naar categorie:
Er is uitgegaan van twee soorten gebruikers (die in de wetenschappelijke wereld trouwens vaak samenvallen): lezers en schrijvers. In beide gevallen gaat het om eindgebruikers. Op de geschiktheid van de software voor uitgevers wordt niet ingegaan.
Oorspronkelijk zou ook software voor documentbeheer (bijvoorbeeld t.b.v. bibliotheken of computercentra) worden bekeken, uitgaande van een client-server oplossing, bij voorkeur het WWW. Twee veelbelovende produkten, DynaWeb en OpenText (vroeger: PAT) konden helaas niet op tijd worden geleverd, tenminste niet voor een tijdelijke licentie dan wel voor een redelijke prijs. Pogingen om alsnog beide systemen te testen zijn nog aan de gang.
MDI (Multiple Document Interface) is de naam die door Microsoft is verzonnen voor een kenmerkend aspect van veel programma's onder MS-Windows, namelijk dat windows binnen andere windows kunnen verschijnen. In andere window-systemen komt het verschijnsel niet voor, en dat is maar goed ook.
Stel dat een programma twee (of meer) schermen met informatie wil tonen. Er zijn dan drie mogelijkheden: (1) er wordt één scherm getoond en de gebruiker krijgt de mogelijkheid de inhoud van het scherm te wisselen; (2) er worden twee windows geopend; (3) één window wordt in twee vakken verdeeld. De keuze hangt af van verschillende inschattingen: is de informatie vaak nodig? gelijktijdig? is de gebruiker ervaren (een ervaren gebruiker zal de gelijktijdige presentatie waarderen zonder in de war gebracht te worden)? is er een sterke relatie tussen de schermen (in dat geval is een gedeeld scherm beter)?
Microsoft voegt daar nog een vierde mogelijkheid aan toe: open drie windows, eentje om de andere twee heen. Dit heeft maar één (klein) voordeel, namelijk dat er maar één menubalk nodig is. De nadelen zijn legio. De gebruiker wordt geconfronteerd met een extra window. De twee inwendige windows lijken op gewone windows maar kunnen niet willekeurig verplaatst worden, want ze moeten binnen de eerste window bl ven. Om die reden wil je de buitenste zo groot mogelijk maken, maar alle loze ruimte in die window beneemt dan weer het zicht op andere programma's.
De verschillen zijn goed te zien aan de drie programma's DynaText, Explorer and Panorama. Alle drie dienen ze om hypertext te bekijken. DynaText neemt een middenpositie in. Het gebruikt weliswaar MDI als het twee onafhankelijke documenten laat zien, maar het gebruikt een window met twee vakken voor sterk gerelateerde schermen. Het aantal soorten windows, afgezien van popups, blijft daardoor beperkt: er zijn `collecties' en `boeken' en vaak heb je voldoende aan één van elk.
Explorer heeft het slechtste interface van de drie. Het maakt uitsluitend gebruik van MDI en bijna elke actie van de gebruiker resulteert in weer een nieuwe window. De meeste ervan hebben een sterke relatie met minstens één van de andere, maar er is geen visuele link. Bovendien zijn er veel verschillende typen gegevens, die moeilijk van elkaar te onderscheiden zijn, zoals documenten, inhoudsopgaven, lijsten van figuren en voetnoten.
Panorama is van dezelfde fabrikant als Explorer, maar is veel recenter. Het heeft een veel eenvoudiger interface zonder dat de mogelijkheden minder zijn. (Integendeel, Panorama kan méér.) Panorama gebruikt helemaal geen MDI. Er is altijd maar één window, die in twee vakken verdeeld kan worden.
Elk produkt moet natuurlijk groeien en uit allerlei dingen, niet alleen het interface, blijkt dat de makers van Panorama veel geleerd hebben van ervaringen met Explorer en DynaText en ook van andere programma's. Toch zou het goed zijn als software-ontwerpers niet klakkeloos MDI zouden gebruiken, alleen omdat het bestaat en een officieel klinkende naam heeft.
Oude documenten (`legacy docs') zijn alle documenten in andere dan SGML-formaten die men waardevol genoeg acht om ook binnen een SGML-systeem te gebruiken. Men wil bijvoorbeeld oude artikelen in WP of LaTeX opnemen in een bestand van artikelen in HTML formaat.
Er zijn verschillende manieren om dat aan te pakken. De eerste oplossing is om de documenten te laten zoals ze zijn en hopen dat iedereen de software heeft om ze te bekijken. Bij de meeste formaten van tekstverwerkers is dat een slechte oplossing, want behalve de tekstverwerkers zelf zijn er geen andere programma's die de files kunnen lezen, omdat het nooit de bedoeling is geweest dat de files in elektronische vorm werden verspreid.
De tweede oplossing is ze met de hand te converteren. Met behulp van de oorspronkelijke tekstverwerker worden de layout-codes vervangen door SGML-elementen, waarna het document wordt bewaard in tekstformaat. Dat niemand hier zin in heeft ligt voor de hand. De oorspronkelijke auteurs zijn al lang weer met andere artikelen bezig en de beheerder van de documenten heeft de resources niet. Alleen in uitzonderingsgevallen is deze oplossing mogelijk.
De derde oplossing is een conversieprogramma te gebruiken, dat automatisch en in batch, grote aantallen files kan converteren. Helaas bevatten de meeste tekstverwerker-formaten te weinig informatie om dit helemaal correct te laten gebeuren. De documenten bevatten alleen layout, nergens staat wat de functie van die layout is: is de cursieve tekst een tussenkopje, of een belangrijk woord? Is de tab alleen om de eerste regel van de alinea in te springen, of dient hij om een tabel uit te lijnen? Afhankelijk van het originele formaat en van de manier van werken van de oorspronkelijke auteur, moet het conversieprogramma meer of minder bijgestuurd worden.
Er zijn conversieprogramma's die half-automatisch werken, in een interactieve omgeving waar een gebruiker kan (en moet) ingrijpen als het programma niet verder kan. WordPerfects IntelliTag is een voorbeeld hiervan. Andere werken met een configuratiefile, waarin de specifieke eigenschappen van de te converteren tekst kunnen worden vastgelegd (een soort omgekeerde stijl-file). Er zijn enkele public-domain-programma's voor conversie naar HTML die zo werken. Weer andere bestaan uit een complete programmeertaal, waarin alle karakteristieken van de te converteren tekst in programmacode moeten worden vastgelegd. OmniMark is hiervan waarschijnlijk de bekendste.
De vierde mogelijkheid is de oorspronkelijke documenten te houden, maar de database de conversie in real-time te laten uitvoeren. Dat betekent dat er een conversie plaatsvindt elke keer dat een document wordt opgevraagd. Die conversie gebeurt wederom aan de hand van een (omgekeerde) style-sheet.
Voordeel van deze laatste methode is dat er maar één kopie van het document bestaat, zodat er nooit verschillen kunnen optreden en er ook minder ruimte nodig is. Nadeel is de extra resources (met name tijd) die nodig zijn bij het opvragen van een document.
Tenslotte is er natuurlijk nog de mogelijkheid helemaal af te zien van gebruik binnen een SGML-systeem, en de documenten alleen aan te bieden als een plaatje. Mensen kunnen de documenten dan nog steeds lezen, maar voor hergebruik of analyse is het document niet meer geschikt. Een formaat dat hiervoor kan dienen is PDF.