Bruno's Hooghe-Liedt:

Deze editie

Inhoudsopgave van dit hoofdstuk

Doelstelling

Mijn doelstelling in het maken van deze uitgave was meerledig:

• voor de algemeen geïnteresseerde lezer een toegankelijke editie ter beschikking stellen van Bruno's Hoogliedberijming;
• voor de wetenschappelijk geïnteresseerde lezer inzicht te geven in de verschillen tussen de afzonderlijke drukken van het werk;
• de (technische) bruikbaarheid te onderzoeken van het gebruik van XML voor het markeren van de relevante aspecten van een dergelijk werk;
• de (inhoudelijke) bruikbaarheid van de TEI-Guidelines te onderzoeken voor het markeren van de relevante aspecten van een dergelijk werk;
• de bruikbaarheid van XSLT te onderzoeken voor de weergave van volgens de TEI-Guidelines in XML aangemaakte teksten.

Dit is niet de plaats om de technische begrippen die in bovenstaande beschrijving zijn gebruikt uitgebreid te beschrijven. Ik volsta hier met de volgende uiterst beknopte toelichtingen:

• XML (eXtensible Markup Language) is een syntax die beschrijft hoe met behulp van en bepaald soort codering verschillende structurele en inhoudelijke aspecten van teksten kunnen worden gemarkeerd zodanig dat kennis over de tekst deel gaat uitmaken van de tekst. Hierdoor ontstaan zelf-beschrijvende teksten die tot op zekere hoogte automatisch kunnen worden verwerkt. Een belangrijk uitgangspunt is dat deze markeringen alleen betrekking behoren te hebben op de inhoud van de tekst zelf, en niet op de bedoelde weergave van de tekst in een bepaald medium (op papier, op het web, of nog anders)¹⁶⁸.
• Als XML de syntax van de markeringen is, dan zou je de TEI-Guidelines kunnen vergelijken met het woordenboek. De TEI-Guidelines geven aan welke structurele en inhoudelijke verschijnselen in de tekst gemarkeerd kunnen worden en welke codes ('tags') daarvoor dienen te worden gebruikt¹⁶⁹.
• XSLT (eXtensible Stylesheet Language - Transformations) is een taal voor het transformeren van XML-documenten in nieuwe XML-documenten of, en daarvoor wordt XSLT hier gebruikt, voor het transformeren van XML-documenten in HTML. Zgn. 'XSLT-templates' geven aan hoe de coderingen worden omgezet in leesbare informatie¹⁷⁰.

De lezer die zich niet intereseert voor de technische aspecten van deze uitgave kan de volgende paragrafen over slaan en verder lezen in Inhoudelijke verantwoording

Waarom XML, waarom TEI, waarom XSLT?

Waarom XML?

XML is een dialect van de SGML-familie van markup-talen, en de argumenten voor het gebruik van XML zijn de doelstellingen die met SGML altijd beoogd¹⁷¹ zijn:

• openheid (geen afhankelijkheid van een leveranciersspecifiek formaat);
• uitbreidbaarheid (de syntax voorziet in de mogelijkheid dat voor specifieke toepassingen nieuwe coderingen mogelijk worden gemaakt);
• scheiding van vorm en inhoud (zodat eenzelfde inhoud op meerdere manieren kan worden weergegeven);
• formele definitie (die automatische verwerking mogelijk maakt).

De redenen om voor XML te kiezen in plaats van voor SGML zijn van praktische aard: XML is populair in de wereld van het World Wide Web. Software-leveranciers spannen zich in om hulpmiddelen te bouwen die het mogelijk maken XML-documenten te ontsluiten op het web. Ook hulpmiddelen voor het aanmaken en bewerken van XML-documneten verschijnen in een hoog tempo. Dankzij XML worden de beloften van SGML werkelijkheid¹⁷².

Waarom TEI?

Dankzij de inspanningen van het Text Encoding Initiative bestaat een apparaat dat gedetailleerde beschrijving en analyse van teksten mogelijk maakt. Alle wetenschappelijke elektronische tekstarchieven zien het belang van TEI in¹⁷³. Het heeft geen zin om voor literair-wetenschappelijke doeleinden een andere DTD¹⁷⁴ te gebruiken.

Waarom XSLT?

Bij het vervaardigen van een electronische editie is het maken van een XML-document alleen een eerste stap. Een XML-document zelf is door de aanwezigheid van de markup niet goed leesbaar. Één of andere vorm van transformatie moet daarom plaats hebben voor het document aan lezers kan worden aangeboden. Er moet daarvoor een aantal keuzes worden gemaakt:

• Wat is het doelplatform voor de weergave van het document: papier, CD-rom, WWW?
• In het geval van publicatie op het WWW: wordt de transformatie eenmalig uitgevoerd of heeft transformatie plaats elke keer dat een browser om het document of een deel daarvan vraagt?
• Wanneer gekozen wordt voor dynamische, 'real-time' transformatie, gebeurt dat dan door de webserver of door de client?
• Welke hulmiddelen worden gekozen voor het uitvoeren van de transformatie?

Ik heb voor deze editie gekozen voor statische (eenmalige) transformatie naar HTML met behulp van XSLT. De redenen daarvoor zijn:

• Het proces is eenvoudig en stelt weinig eisen aan de web server of aan de client browser.
• XSLT is een W3C Recommendation en de transformatieregels behoeven dus niet geschreven te worden volgens leveranciersspecifieke eisen.
• XSLT biedt een mechanisme dat bijna alle denkbare transformaties mogelijk maakt.
• Er bestaan diverse gratis programma's die de transformatieregels van XSLT implementeren.
• Het valt te verwachten dat binen afzienbare tijd browsers in staat zijn om XSLT rechtstreeks te interpreteren (zodat de noodzaak van voorafgaande transformatie vervalt).

Technische invulling

Invulling van alternatieven bij codering volgens de TEI-normen

Bij het gebruik van de TEI Guidelines moeten keuzes gemaakt worden, omdat er vaak verschillende manieren zijn om een zelfde verschijnsel te coderen. Bovendien moet gekozen worden wát precies wordt gecodeerd. In deze paragraaf verantwoord ik welke keuzes ik heb gemaakt.

De gebruikte DTD

De Document Type Definition die ik heb gebruikt heb ik aangemaakt met behulp van de Pizza-chef. De 'Pizza-chef' is een website die DTD's genereert aan de hand van een aantal door de gebruiker gemaakte keuzes (wat voor soort werk wil ik uitgeven, wat voor soort editie wil ik maken, wil ik XML of SGML gebruiken).

Structuur van het document

De TEI Guidelines lijken bij de transcriptie van bestaand werk er van uit te gaan dat commentaar wordt toegevoegd in de noten en misschien in de 'header' van het document. Van de editie die ik vervaardig wordt het hart gevormd door de tekst van Bruno's Hooglied-uitgave van 1656, maar een in omvang zeker zo groot deel wordt gevormd door verschillende vormen van toelichting: over Bruno's leven, over de tekst van zijn berijming, en over het gebruik van de TEI normen (dit hoofdstuk). Ik heb mij afgevraagd waar ik de verschillende delen van de toelichtende tekst moest onderbrengen: horen ze in hetzelfde document thuis? Is het beter alleen de eigenlijke tekst in het XML-document te coderen en de toelichtingen in afzonderlijke (html-?)documenten onder te brengen? Als gekozen wordt voor een enkele, doorlopende XML-tekst, hoe moet dan de toelichting worden onderscheiden van de orginele tekst? En hoe moet worden omgegaan met de (secundaire) tekstfragmenten die worden opgenomen in de toelichtingen (bijvoorbeeld de brieven)?
Ik heb uiteindelijk de volgende keuzen gemaakt: de tekst van de uitgave van 1656 wordt ondergebracht in het 'body'-element van het primaire 'text'-element. Alle toelichtingen (met uitzondering van noten) maken deel uit van de 'front'- of 'back'-elementen van deze primaire 'text'. Andere originele tekstfragmenten worden gecodeerd als 'text'-elementen binnen 'quote'-elementen die in de 'front matter' of 'back matter' zijn opgenomen.

In zowel de 'front'- en 'back'-elementen als in de 'text' 'body' wordt gebruik gemaakt van ongenummerde (en geneste) 'div'-elementen om de inhoud van de tekst te structureren.

De 'div'-elementen op het hoogste niveau zijn voorzien van 'argument'-elementen die de korte inhoud weergeven. Ze worden gebruikt om de HTML 'description' meta-tag te vullen.

Een aantal onderdelen van de tekst (bijvoorbeeld de noten, het variantenapparaat) wordt met behulp van stylesheets gegenereerd uit andere onderdelen van de tekst. In de tekst zijn daarvoor 'divGen'-elementen opgenomen ('gegenereerde divisies'). Wat ik hier genereer is HTML; van deze tekstdelen bestaat dus geen XML-equivalent.

Namen

Ik heb gebruik gemaakt van 'name'-elementen en niet van de gespecialiseerde elementen voor het coderen van verschillende soorten van persoons- en geografische namen. Namen heb ik onderscheiden in de typen 'person', 'geog' en 'org'. Voor alle namen is een geregulariseerde spelling gecodeerd met behulp van het 'reg'-attribuut. Voor elke naam heb ik steeds dezelfde regularisatie gebruikt, maar ik heb geen vaste regels gebruikt (omdat zulke regels mij niet bekend zijn) om de regularisatie te bepalen.

Voorzien van <name>-tags zijn de namen die voorkomen binnen de 'text' van het XML-document, (dus niet de namen in de TEI-header), m.u.v. de namen die voorkomen in headers en verwijzingen. Waar een naam herhaaldelijk voorkomt heb ik er soms vanaf gezien hem te markeren.

Annotaties

Noten heb ik steeds ingevoegd op de plaats waar ze betrekking op hebben. Ik heb niet geprobeerd om door middel van 'target'- en 'targetEnd'-attributen te markeren welk fragment van de tekst ze becommentariëren. Op sommige plaatsen waar ik noten wilde toevoegen, werd dat door de dtd niet toegestaan. Op die plaatsen (bijvoorbeeld in 'byline'- of 'date'-elementen) heb ik een 'seg'-element ingevoegd om de noot in op te nemen (samen met het becommentarieerde element.

Literatuur, bibliografische verwijzingen

De literatuurlijst is gecodeerd met behulp van 'biblStruct'-elementen. Ze leken me het juiste midden tussen de ongestuctureerde 'bibl'- en de uitputtend gestructureerde 'biblFull'-elementen. Waar van toepassing heb ik gebruik gemaakt van 'analytic'-elementen voor het coderen van artikelgegevens en van 'series'-elementen voor seriegegevens. Voor het 'type'-attribuut van de 'title'-elementen heb ik gebruik gemaakt van de waarden 'main' en 'sub' (voor de hoofd- en ondertitel) en de waarde 'short' voor gebruik in aanhalingen.

Voor verwijzingen naar titels in de literatuurlijst heb ik 'bibl'-elementen gebruikt met als enige subelementen een 'ptr' (pointer) naar de betreffende titel en eventueel een 'biblScope'-element om het bereik van de verwijzing vast te leggen.

Het werd mij uit de Guidelines niet duidelijk hoe een bibliografische verwijzing voor brieven er uit hoort te zien. Ik heb een 'note'-element opgenomen binnen het 'bibl'-element in het omvattende 'cit'-element.

De vertalingen van de brieven heb ik opgenomen in 'cit'-elementen. De naam van de vertaler is opgenomen in het bijbehorende 'bibl'-element.

Citaten

Citaten heb ik steeds opgenomen in 'quote'- of 'cit'-elementen. Waar een bronvermelding wenselijk was, is die steeds opgenomen als een 'bibl'-element direct aansluitend op het 'quote'-element. Beide elementen maken dan deel uit van een overkoepelend 'cit'-element.

Bij citaten uit teksten die deel uitmaken van deze uitgave, is geprobeerd te voorkomen dat de letterlijke tekst nog eens werd herhaald. In citaten van een 'natuurlijke' eenheid (bijvoorbeeld een 'linegroup', 'lg') is dat betrekkelijk eenvoudig. Met het 'copyOf'-attribuut op de aanhalende linegroup wordt verwezen naar het aangehaalde element. Bij het aanhalen van een willekeurig deel van een tekst werkt deze eenvoudige oplossing niet. Het coderen van 'seg'-elementen om de aangehaalde passage te markeren is niet altijd mogelijk, omdat elementgrenzen kunnen worden overschreden. Het verwijzen naar de begin- en de eind-positie van een aangehaalde passage is wel eenvoudig aan te brengen, maar lijkt erg lastig voor de uiteindelijke presentatie. Ik heb hiervoor nog geen goede oplossing.

Varianten

De TEI geeft verschillende mogelijkheden voor het coderen van varianten en het linken van deze varianten met de eigenlijke tekst. Gezien de betrekkelijke schaarsheid van het beschikbare materiaal (drie drukken die weinig verschillen) en de eenvoudige aard van de verschillen tussen de drukken (vrijwel alleen spellings- en interpunctieverschillen) heb ik gekozen voor een eenvoudige inline-weergave van de varianten. De gebruikte methode is de zgn. 'parallel-segmentation'.
Het aangeven van varianten gebeurt hier (bijvoorbeeld) als volgt:

Wiens <app><rdg wit="A1 B1">Voorbeelt</rdg><rdg wit="B1 B2 B3">Voor-beeldt</rdg></app> dat hy was door...

In de lopende tekst worden varianten dus aangegeven door een 'app'-element (voor 'apparatus'), en daarbinnen de afzonderlijke lezingen door 'rdg'-elementen ('readings'). Het 'wit'-attribuut is het sigle. Het verwijst naar een zgn. 'witList', een lijst met 'witnesses', waarin de bronnen worden beschreven. De witList wordt opgenomen in de 'front matter' van het TEI document (zie hier Drukken van het Hooghe-Liedt).

Het gebruik van 'link'-elementen

De tekst van de Statenvertaling heb ik opgenomen in een afzonderlijke 'division' in de 'back matter'. In deze editie heeft die tekst een ondergeschikt doel: de tekst moet getoond kunnen worden aan de lezer die geïnteresseerd is in een vergelijking tussen de tekst van Bruno en die van zijn bron. Het zou betrekkelijk eenvoudig zijn om op basis van de toegekende 'id'-attributen in het stylesheet een link te leggen tussen berijming en bron (de verzen van de Statenvertaling hebben als id bijvoorbeeld 'sv4:5' en het overeenkomstige vers uit Bruno's vertaling heeft als 'id' 'H4:5'). Ik heb dat niet op die manier gedaan omdat dan een essentieel deel van de structuur van de XML-tekst niet in de tekst zelf zou worden verantwoord.
Er zijn verschillende manieren om links tussen tekstdelen te documenteren. Een mogelijkheid is om gebruik te maken van het universele attribuut 'corresp', waarmee een in principe tweezijdige correspondentie tussen parallelle teksten kan worden gedocumenteerd. Het nadeel daarvan is dat de aard van de relatie niet wordt vastgelegd. Dat nadeel gaat nog zwaarder wegen wanneer meerdere parallel-teksten zouden worden opgenomen. In deze editie zou het belangrijk kunnen worden als ik besloot nog andere vertalingen of berijmingen van het Hooglied ter vergelijking op te nemen.
Ik heb uiteindelijk besloten de relatie tussen bron en berijming vast te leggen in 'link'-elementen. Anders dan de HTML-verwijzingen die we gewoonlijk 'links' noemen, zijn TEI-links onafhankelijk van een bepaalde positie in de tekst (ze kunnen op een willekeurige plaats in het document worden vastgelegd). Ze zijn bovendien voorzien van verschillende attributen die de betekenis documenteren: het 'type'-attribuut (legt de betekenis van de link vast; ik heb als de waarde 'source' gebruikt), het 'targFunc'-attribuut (geeft de functie aan van de gelinkte elementen in de link; in dit geval: 'berijming bron'), het 'targType'-attribuut (geeft het type elementen aan dat kan worden gelinkt, in dit geval 'lg l') en tenslotte het 'targOrder'-attribuut (geeft aan of de volgorde van de gelinkte elementen van belang is; in dit geval heeft het de waarde 'Y').
In het document is dus een verzameling 'link'-elementen opgenomen waarin de link tussen de verzen van de berijming en de bron wordt gedocumenteerd. De zojuist genoemde attributen heb ik gecodeerd op het hogere niveau van het 'linkGrp'-element, bedoeld om (soortgelijke) links te groeperen.

Een soortgelijke constructie heb ik gebruikt om de brieven van Bruno te koppelen aan de vertaling van de brieven.

Het gebruik van het 'rend'-attribuut

Het 'rend'-attribuut heb ik gebruikt voor twee doeleinden: in elementen van de oorspronkelijke tekst wordt het gebruikt op de opmaak weer te geven van de oorspronkelijke editie. In elementen van de commentaartekst wordt het soms gebruikt op een opmaak te suggereren voor het stylesheet of de applicatie die de weergave van de tekst bepaalt. De waarden die ik heb gebruikt zijn: 'indent1', 'indent2', 'ital', 'display', 'quoted', 'bold', 'code', 'plain', 'right' en 'sup'.

Talen, writing systems, bijzondere tekens

De TEI-richtlijnen verlangen dat beschreven wordt in welke taal een document of een deel daarvan geschreven is. Op alle elementen is daarvoor het 'lang'-attribuut beschikbaar. De norm ISO639¹⁷⁵ beschrijft de te gebruiken taalcodes. De waarden die in het 'lang'-attribuut worden gebruikt verwijzen bovendien naar 'language'-elementen uit de 'file header' die de taal nader beschrijven door een verwijzing naar een 'writing system declaration' voor de betreffende taal¹⁷⁶.

Bijzondere lettertekens worden in het XML-document weergegeven als character references in bijvoorbeeld de vorm &eacute; of &kappa;. In de DTD worden deze character references vertaald naar decimale unicode weergaves die er bijvoorbeeld zo uitzien: &#233; of &#954;¹⁷⁷.

Ontbrekende passages, toevoegingen

In de brieven zijn door de vertaler een aantal verhelderende woorden toegevoegd. Deze worden zijn gemarkeerd als 'supplied'. De gebruikte 'reason' is 'clarification'. Één passage is niet vertaald, wat gecodeerd is als 'gap' met 'reason' 'irrelevant'. Onleesbare passages in de brieven zijn 'gap's met 'reason' 'illegible'.

Ook in de citaten uit de kanttekeningen heb ik regelmatig het 'gap'-element gebruikt om irrelevant materiaal te kunnen weglaten.

Vergelijking met de brontekst

De plaatsen waar Bruno's tekst afwijkt van de Statenvertaling heb ik gemarkeerd met 'seg'-elementen. Deze 'segmenten' verwijzen met hun 'ana'-attribuut naar 'interp'-elementen. 'interp' staat voor interpretation, en in dit geval leg ik er in vast om wat voor soort afwijking (toevoeging, verwijdering of wijziging) het gaat. De afwijking kan worden verklaard (bijvoorbeeld door een verwijzing naar de Kanttekeningen) in een 'note'-element dat van het genoemde segment deel uitmaakt. Er bestaat echter geen harde koppeling tussen de verklaring in de 'note' en het segment: in het segment kunnen ook noten staan die niets met de afwijking van de Statenvertaling te maken hebben, maar nu eenmaal toevallig bij dat tekstdeel thuishoren.
De overeenkomstige coderingen zijn aangebracht in de tekst van de Statenvertaling zodat zichtbaar kon worden gemaakt (zie Visuele weergave van de verschillen Bruno-Statenvertaling) waar de teksten verschillen. Ik heb niet geprobeerd de coderingen in de tekst van Bruno te 'linken' aan de coderingen in de Statenvertaling.
Een volgende stap zou kunnen zij om van al deze segmenten nog aan te geven (ook in het 'ana'-attribuut) in hoeverre de afwijking betekenisvol is, of misschien zelfs wat de betekenis van de afwijking is. Ik ben niet zo ver gegaan omdat me de tijd daarvoor ontbrak.

De TEI Header

Niet van alle velden in de TEI header was mij duidelijk hoe ze gevuld behoren te worden. Veel gegevens lijken op een aantal plekken te moeten worden ingevoerd. Ik heb mij zoveel mogelijk aan de Guidelines gehouden en waar mogelijk verwezen naar delen van de eigenlijke tekst waar de betreffende informatie al was opgenomen.

Keuzes voor de stylesheets

Een enkel stylesheet of een verzameling stylesheets zal nooit in staat zijn alle mogelijke coderingen van TEI-XML-gecodeerde teksten correct af te handelen. Daarvoor zijn meerdere redenen, wo.: (1) de omvang van de volledige TEI-dtd's, (2) de 'open einden' van de dtd's (bijvoorbeeld de waarden van de 'rend'- ('rendering') en 'type'-attributen die door de codeerders moeten worden gekozen), en (3) de verschillende soorten teksten die kunnen worden gecodeerd.

De stylesheets die ik heb gebruikt zijn gebaseerd op de stylesheets van Sebastian Rahtz¹⁷⁸. Ik heb ze echter vérgaand aangepast. Sommige van die aanpassingen zijn uitbreidingen: ik heb voorzieningen aangebracht voor taggings waar Rahtz geen rekening mee heeft gehouden (<app>'s, <link>'s, <biblStruct>'s, etc). Andere aanpassingen zijn eerder beperkingen: voor mijn situatie was bijvoorbeeld het splitsen van de 'body' van de tekst in meerdere bestanden overbodig en complicerend. Ter wille van de begrijpelijkheid heb ik alle onderdelen waar ik geen behoefte aan had verwijderd.

Het is ondoenlijk om alle beperkingen van de stylesheets zoals ik ze heb gebruikt op te sommen. Ik laat het bij de volgende opmerkingen:

Zoals hierboven vermeld en toegelicht heb ik gekozen voor het genereren van HTML. Alle HTML op deze pagina's (met uitzondering van de menu's) is gegenereerd met behulp van de stylesheets.

De feitelijke generatie van de HTML heb ik uitgevoerd met behulp van Saxon. Saxon is één van de beschikbare hulpmiddelen voor het toepassen van XSLT-stylesheets op XML-bestanden¹⁷⁹. Saxon ondersteunt een aantal extensies¹⁸⁰. De enige extensie die ik heb gebruikt is de extensie die het mogelijk maakt in één procesgang meerdere uitvoerbestanden aan te maken¹⁸¹.

Ik heb geprobeerd de stylesheets te formuleren in algemene termen. Een betrekkelijk groot deel van de codering zou bruikbaar moeten zijn voor alle TEI/XML-documenten. Op veel plaatsen was het echter onvermijdelijk om gebruik te maken van specifieke eigenschappen van dit bestand.

Een evaluatie van de gekozen technieken

De ten behoeve van deze editie gebruikte technieken zijn gedeeltelijk nog betrekkelijk nieuw. Aan de richtlijnen van het TEI wordt gewerkt sinds 1988, maar de gebruikte XML recommendation dateert van 1998 en de XSLT recommendation van 1999. Het is daarom zinvol om kort in te gaan hun bruikbaarheid voor een editie als deze.

Met betrekking tot de mogelijkheid van automatische verwerking:

• Automatische verwerking wordt tot op zekere hoogte inderdaad mogelijk gemaakt door het gebruik van XML met een gestandaardiseerde DTD. Vanwege de vrijheid die de TEI Guidelines op veel plaatsen toestaan (die waarschijnlijk ook weer onvermijdelijk is vanwege de mogelijke verschillen tussen uit te geven teksten) lijkt blindelingse geautomatiseerde verwerking van volgens de TEI gecodeerde teksten niet goed haalbaar. Een voorbeeld daarvan is de verwerking van de tekst door de stylesheets die ik heb gebruikt: veel van de ideeën die ik heb aangetroffen in de oorspronkelijk gevonden stylesheets zijn gehandhaafd, maar uiteindelijk is bijna geen regel intact gebleven.
• Een voorbeeld van de voordelen van automatische verwerking is het volgende: alle varianten zijn gecodeerd in de tekst. Nadat deze coderingen waren aangebracht was het heel eenvoudig geworden om de aantallen verschillen tussen de verschillende drukken te bepalen, en aan de hand daarvan konden conclusies getrokken worden over de waarschijnlijke drukgeschiedenis. Bovendien konden eenvoudig automatische controles worden uitgevoerd om te verifiëren of voor de varianten alle exemplaren waren ingebracht.
• Ook bleken al tijdens het werk aan de editie bepaalde coderingen heel bruikbaar te zijn, vanwege de manier waarop de gegevens konden worden getoond. Bijvoorbeeld de presentatie naast elkaar van Bruno's tekst en die van de Statenvertaling maakte het mogelijk snel de verschillen te inventariseren; daarbij was het dan ook weer handig te kunnen doorklikken naar de codering van de varianten. Zonder enigerlei vorm van 'tagging' zouden deze doorklik-mogelijkheden alleen met heel veel inspanning gerealiseerd kunnen worden (en erger: ze zouden bijna ononderhoudbaar zijn).
• Hierbij geldt wel dat verdere invulling van de TEI-normen wenselijk is op een aantal vlakken. Ik zou graag gebruik hebben gemaakt van normen voor een geregulariseerde schrijfwijze van namen van personen en plaatsen, normen voor verwijzingen naar bijbelplaatsen, normen of een aantal meer uitgewerkte alternatieven voor de diverse 'type'- en 'value'-attributen, en een standaard voor het 'rend'-attribuut.

Voor wat betreft de bruikbaarheid in breder opzicht geldt:

• Één van de fundamentele uitgangspunten van XML is de scheiding tussen inhoud en opmaak. Maar bij een DTD zoals de TEI zijn er vaak vele min of meer equivalente manieren om eenzelfde verschijnsel in de tekst te coderen. Bovendien heeft de codeerder de keuze welke verschijnselen in de tekst hij wil markeren. Het lijkt onvermijdelijk dat de codeerder in zijn keuzes zich mede zal laten laten leiden door de (on)mogelijkheden van weergave van de aangebrachte coderingen.
  Deze editie is in dit opzicht enigszins hybride. De opmaak wordt bepaald door de stylesheets en staat dus los van de inhoud van het XML-bestand. Maar in het XML-bestand wordt deze opmaak wel besproken, en wanneer dus een andere opmaak gekozen wordt, klopt een deel van de tekst dit niet meer (dat geldt overigens alleen voor de kritische delen van de tekst, niet voor de 17e-eeuwse tekstdelen).
• Een andere belangrijke overweging m.b.t. de bruikbaarheid van deze technieken is het soort expertise dat nodig is om ze te gebruiken. De TEI richtlijnen zijn een formulering in SGML/XML-termen van kennis die een editeur altijd nodig zal hebben; je mag verwachten dat iemand die een tekstuitgave maakt deze kennis bezit en zich de formulering in TEI-termen kan eigen maken. Bij de toepassing van de richtlijnen is enige automatiseringskennis wel erg handig, zo niet onmisbaar: de meeste 'taggings' heb ik bijvoorbeeld aangebracht met behulp van macro's in Word. Wie daarvoor terugschrikt moet veel werk met de hand doen. Ook bij het schrijven van de stylesheets heb ik veel baat gehad van eerder opgedane programmeerervaring.
• Voor wat betreft de inspanning die het maken van een editie als deze vergt: het is duidelijk dat het aanbrengen van de taggings die de tekst 'intelligent' maken in eerste instantie veel werk is. Mijn indruk is dat tijdwinst in een later stadium deze investering lonend maakt. Dat voordeel gaat nog zwaarder wegen wanneer de tekst in de toekomst door volgende onderzoekers opnieuw kan worden gebruikt.
• Dat neemt niet weg dat ik een paar keer een deel van de tekst eerst in een gewone tekstverwerker geschreven heb, en hem pas daarna voorzien van de benodigde tagging. Voor de concentratie op de inhoud van de tekst is soms het rommelige uiterlijk van de tekst zoals een XML-editor die presenteert niet behulpzaam.

Samenvattend meen ik dat de gebruikte technieken (TEI, XML, XSLT) goed bruikbaar zijn gebleken voor een editie als deze.

Inhoudelijke verantwoording

Voor deze editie heb ik gekozen voor een weergave van de eerste druk van Bruno's Hoogliedberijming, inclusief de opdracht en de lofdichten maar zonder de in hetzelfde boek opgenomen Klaagliederen. De tekst is na transcriptie door twee personen onafhankelijk gecontroleerd. De tekst zoals die wordt gepresenteerd is een tekst met een klein aantal verbeteringen. In de weergave van de uitgave zijn ze gemarkeerd met een rood sterretje dat linkt naar de verantwoording van de verbeteringen. Het zou overigens mogelijk zijn uit het XML bronbestand een tekst te genereren zonder deze verbeteringen.

Alle mij bekende exemplaren heb ik onderzocht op afwijkingen van de druk van 1656. Hierbij heb ik alleen aandacht besteed aan de tekst van de Hoogliedberijming zelf en niet aan de lofdichten, de opdracht of de koppen¹⁸².

De typografische bijzonderheden worden in deze weergave grotendeels genegeerd:

• De druk van 1656 bevat op een aantal plaatsen cursieve hoofdletters waarvan de betekenis mij onduidelijk is. Ze worden hier niet gereproduceerd en zijn niet opgenomen in het variantenapparaat.
• Het eerste vers van elk hoofdstuk opent met een letter in groot kapitaal, gevolgd door een hoofdletter van normale grootte. De tweede hoofdletter wordt hier genegeerd, de eerste hoofdletter wordt op normale groote afgedrukt.
• De editie van 1657 heeft vaak een extra spatie voor een leesteken (komma, dubbele punt). Ik heb geen poging gedaan om dit weer te geven.

Voor wat betreft de annotering van de tekst ben ik er van uitgegaan dat dit geen Hooglieduitgave is maar een uitgave van een Hoogliedberijming. Onduidelijkheden in de tekst die niet voortkomen uit het 17e eeuws taalgebruik maar uit wat nu eenmaal de inhoud van het Hooglied is heb ik vaak gelaten voor wat ze zijn. Bij de annotaties die wel zijn aangebracht ligt de nadruk op toelichting van het 17e eeuws taalgebruik en verklaring van de herkomst van elementen die niet in de tekst van van de Statenvertaling voorkomen. In de toelichtingen heb ik zo veel mogelijk geciteerd uit de kanttekeningen bij de Statenvertaling, omdat de kanttekeningen weergeven hoe het Hooglied in Bruno's tijd gelezen werd. Ik heb in het algemeen afgezien van een toelichting wanneer de gebruikte tekst van de Statenvertaling duidelijk maakt wat de bedoelde betekenis van een passage is.