1. Probleme und Begriffe

Digitale Editionen werden oftmals im Rahmen von auf zwei bis drei Jahren befristeten drittmittelfinanzierten Projekten realisiert. Vgl. folgende Auswahl digitaler Editionsprojekte, welche mit Beteiligung des ACDH aktuell realisiert wurden bzw. werden, allesamt vom Österreichischen Wissenschaftsfonds FWF finanziert: Edition von Tillichs Vorlesung über Religion und Kultur, Laufzeit: 2024–2026; Edition des Briefwechsels von Paul Tillich (1887–1933), Laufzeit: 2021–2024; Die Korrespondenz Paul Tillichs 1933–1951, Laufzeit: 2024–2027; Die Entstehung des Bundes-Verfassungsgesetzes 1920, Laufzeit: 2023–2026; Die Protokolle des österreichischen Kabinettsrates 1919–1920, Laufzeit 2026–2029; Familiensache. Dynastische Handlungsspielräume von Frauen, Laufzeit: 2021–2025; Briefwechsel Arthur Schnitzlers mit Schriftstellern 3, Laufzeit: 2025–2029; Auden in Österreich Digital, Laufzeit: 2024–2027; Eine analytische Rekonstruktion von Hanslicks Ästhetik, Laufzeit: 2025–2027. Für eine aktuelle Liste von Editionsprojekten, die mit dem realisiert wurden, vgl. Andorfer et al. 2024: Readme.md. Während dieser Zeit werden ausgewählte Texte im TEI-XML-Format kodiert. Die Art der Auszeichnung und der verwendeten TEI-Tags orientiert sich an der jeweiligen Fragestellung und dem zu edierenden Material. Die TEI-XML-Kodierung ist für die Forscher*innen dabei primär Mittel zum Zweck der Veröffentlichung einer digitalen Edition. In der Regel verstehen sie darunter eine Webseite zur Darstellung, Publikation und Durchsuchbarkeit (Volltextsuche, registerbasierte Suche) ihrer edierten Texte. Für die Realisierung dieser Webseite werden Kooperationen mit einschlägigen Institutionen wie etwa dem Austrian Centre for Digital Humanities (ACDH) eingegangen. Von diesen Institutionen wird erwartet, dass sie nach der Entwicklung einer qualitativ hochwertigen und aktuellen Standards Vgl. Sahle 2014. entsprechenden digitalen Edition das stabile und langfristige Hosting der Edition betreiben. Seitens der Projektpartner*innen und Fördergeber*innen stehen für gewöhnlich nach Projektabschluss keine finanziellen Ressourcen mehr zur Verfügung. Vgl. Helling 2024. Was ist nun konkret als Zeitraum für den Bestand einer Edition anzunehmen? Zwei Jahre scheint zu kurz, zehn Jahre scheint lang. Wer weiß schon, wie das Internet in zehn Jahren funktioniert? Am ACDH wird grundsätzlich garantiert, die im Projekt entwickelten Applikationen, worunter auch digitale Editionen fallen, zwei Jahre nach Projektende online zu halten. Nach diesem Zeitraum werden diese weiter automatisch überwacht Dies erfolgt mit der Open-Source-Software Icinga. und technisch notwendige Updates – im Falle von überschaubarem Aufwand und unter Berücksichtigung der personellen Ressourcen – durchgeführt. Als zusätzliche Erschwernis kommt es immer wieder vor, dass Applikationen auf veralteter Technologie basieren und die ursprünglichen Entwickler*innen der Applikation nicht mehr zur Verfügung stehen. Derartige Applikationen müssen nach einer abschließenden technischen Evaluierung und der Sicherung der Daten und des Quellcodes vom Netz genommen werden. Beispiele hier: rest in peace.

Was bedeutet ›langfristig‹ nun im Kontext dieses Beitrages? Langfristig heißt hier, dass eine auf den Prinzipien des Andorfer et al. 2024. basierende digitale Edition so lange online bleiben kann, wie der institutionelle Kontext, in dem die Edition publiziert wurde, nicht strukturell geändert oder aufgelöst wird. Das heißt auch, dass das Überleben der Applikation weder an die Entwicklung einer bestimmten Technologie gekoppelt ist, noch an die Karriere einer einzelnen Person.

Bleibt noch zu klären, was der vorliegende Beitrag unter einer digitalen Edition versteht. Vgl. Driscoll / Pierazzo (Hg.) 2016. Eine digitale Edition beschreibt hier eine Reihe von TEI-XML-Dateien – in der Regel handelt es sich dabei um eine erschließende Wiedergabe historischer DokumenteSahle 2016, S. 23. – die in einer kuratierten Form als HTML-Dateien im Kontext einer Webseite im Internet zugänglich gemacht werden. Eine digitale Edition besteht also neben den Daten auch aus einem spezifisch für diese Daten entwickelten Interface, einer je nach Machart mehr oder weniger individualisierbaren Leseansicht.

2. Statisch, automatisch und ähnlich

Am ACDH versucht man dem Versprechen, digitale Edition langfristig am Leben zu erhalten, mit Hilfe dreier Prinzipien gerecht zu werden. Diese Prinzipien werden von den Schlagworten ›statisch‹, ›automatisch‹ und ›ähnlich‹ skizziert.

›Statisch‹ – im Gegensatz zu ›dynamisch‹ – bezieht sich hier auf ein bestimmtes Konzept von Webseiten, nämlich solche, deren Inhalte bereits als eigenständige (statische) HTML-Dateien vorliegen. Im Unterschied zu vielen komplexeren Webseitenlösungen stellt das sicher, dass eine einzelne Seite nicht bei jeder Abfrage, bei jedem Aufruf neu berechnet werden muss. Vgl. Wikipedia: Statische Webseite. Das reduziert den Anspruch beim Hosting und bei der Maintenance solcher Webseiten deutlich, da weder eine Datenbank benötigt wird noch ein webseiten-spezifischer Code am Server ausgeführt werden muss. Somit fallen gleich zwei Komponenten dynamischer Webseiten weg, die von regelmäßig notwendigen Updates betroffen wären und potentielle Sicherheitslücken beinhalten könnten. Vor allem bedeutet jedes Update, dass an solchen Schnittstellen danach eine Bruchstelle entstehen kann, die die ganze Seite unbrauchbar macht. Bis zum Ausrollen des dse-static-cookiecutters wurden digitale Edition am ACDH als dynamische Webapplikation mittels eXist-db, einer Java basierten, nativen XML-Datenbank publiziert. Dies war insofern eine naheliegende Entscheidung, als neben der Verwaltung von XML-Dateien auch Tools und Funktionen bereitstellt, die es erlauben, dynamische, datengetriebene Webapplikationen zu entwickeln und zu publizieren. Dazu zählen etwa ein integrierter Webserver (Jetty), eine XQuery-basierte Templating-Engine, ein leistungsstarker Suchindex (Lucene), eine integrierte Entwicklungsumgebung (eXide), eine Anbindung an den Oxygen-XML Editor und vor allem auch eine in den digitalen Geisteswissenschaften verankerte Community. Diesen Vorteilen standen die Nachteile solcher dynamischen Lösungen gegenüber, vor allem das regelmäßige Nachziehen von Updates von neuen Versionen als auch der benötigten Java-Umgebung. Unter dem Gesichtspunkt der Langfristigkeit muss außerdem bedacht werden, dass es sich bei einer Software wie um ein vergleichsweise kleines Open-Source-Projekt handelt, welches eng an einige wenige Developer*innen geknüpft ist. Vgl. dazu etwa die Parameter ›Starred‹ und ›Contributors‹ der GitHub-Repositoriums von eXist-db (449 und 80) und des Python-basierten Webframeworks Django (85.000 und 2679). Zahlen vom 15.09.2025.

Das Schlagwort ›automatisch‹ beschreibt die Aktionen, die notwendig sind, um die fertigen HTML-Dateien der statischen Webseite aus den TEI-XML-Dateien der Edition zu generieren und online zu publizieren. Dieser Build-Prozess kann je nach Projekt mehrere Schritte umfassen. Welche Schritte dies sind, welche Umgebung (Betriebssystem, Software, welche Versionen) diese benötigen und in welcher Reihenfolge diese auszuführen sind, ist dabei in einer menschen- wie maschinenlesbaren Datei konfiguriert. Ein solches Setup erlaubt es, die digitale Edition unabhängig von den ursprünglichen Entwickler*innen respektive deren Arbeitsgeräten neu zu bauen und zu publizieren. Im wird ein solcher automatischer Build-Prozess mit Hilfe einer YAML-Datei konfiguriert, welche vom CI/CD-Service GitHub-Actions interpretiert und ausgeführt wird. Alternativ dazu generiert der dse-static-coociecutter auch ein Dockerfile, wodurch das Prinzip ›automatisch‹ auch ohne Rückgriff auf die Infrastruktur von GitHub realisiert ist.

Das dritte Schlagwort ›ähnlich‹ bezieht sich auf den im Build-Prozess ausgeführten Programmcode und dient dazu, die digitalen Editionen noch stärker von ihren Entwickler*innen zu entkoppeln. Statische digitale Editionen, die mit dem realisiert werden, sind hinsichtlich der verwendeten Technologien, der Organisation der TEI-XML-Daten, des Quellcodes sowie des Build-Prozesses ähnlich. Das erleichtert es für Entwickler*innen und Systemadministrator*innen, allfällig notwendige Adaptionen an den Editionen vorzunehmen, sobald sie sich mit der Codebase einer einzelnen Edition vertraut gemacht haben. Hinsichtlich Form und Aufbau der einzelnen XML-Dateien der Editionseinheiten gibt es seitens des allerdings keine technisch sichergestellten Vorgaben wie ein dezidiertes Schema.

3. dse-static-cookiecutter

Der ist ein Static-Site-Generator für TEI-XML-Dateien. Das Ziel ist es, digital (scholarly) editions – abgekürzt DSE – als statische (static) Webseiten zu veröffentlichen. Implementiert ist dies auf Basis der in Python geschriebenen cross-platform command-line utility cookiecutter, womit Name und Funktionalität in aller Kürze beschrieben wären.

Um den für ein neues Projekt einzusetzen, müssen sowohl Python als auch das Python-Package cookiecutter installiert sein. Danach wird mit dem Befehl cookiecutter gh:acdh-oeaw/dse-static-cookiecutter der Initialisierungsprozess einer neuen, auf basierten digitalen Edition gestartet. Nun werden ein Dutzend Fragen gestellt, beispielsweise nach dem Titel der Edition, der zukünftigen URL, dem Speicherort der TEI-XML-Dateien,Empfohlen wird je ein eigenes Repositorium für die Daten und die Webseite. der Standardsprache des User Interfaces bzw. ob InternationalisierungVgl. Wikipedia: Internationalisierung (Softwareentwicklung). implementiert werden soll.

Abb. 1: Screenshot aus dem Initialisierungsprozess eines neuen digitalen Editionsprojektes. [Screenshot: Peter Andorfer 2025]

Alle Fragen verfügen über vorgefertigte Antwortmöglichkeiten. Die meisten Antworten können außerdem nachträglich in einer globalen Konfigurationsdatei (xslt/partials/params.xsl) geändert werden.

Das Ergebnis dieses Initialisierungsprozesses ist ein vom angelegtes Dateiverzeichnis, welches aktuell 38 Ordner und über 2300 Dateien umfasst. Von diesen Dateien entfällt der Großteil auf Open-Source-Drittbibliotheken wie etwa das CSS-Framework Bootstrap, den Image-Viewer OpenSeadragon oder den XSLT-Prozessor Saxon. Zieht man diese ab, bleiben nur noch rund 60 Dateien übrig.

Den eigentlichen Kern des Quellcodes bilden XSLT-Dateien, welche die TEI-XML-Dokumente der Edition nach HTML transformieren. Der Transformationsprozess ist in einer ANT-XML-Datei namens build.xml konfiguriert und wird von dem bereits erwähnten XSLT-Prozessor ausgeführt. Vereinfacht gesagt, definiert man in build.xml, welche Dateien mit welchem Stylesheet konvertiert werden und wohin und unter welchem Namen die erzeugten HTML-Dateien gespeichert werden sollen. Die Konvertierung kann mit dem Kommandozeilenbefehl ant ausgeführt werden, wofür ANT am Rechner installiert sein muss. Alternativ kann die Konvertierung über den XML-Editor Oxygen durchgeführt werden. Dieser gängige XML-Editor wird vom von Haus aus unterstützt, indem bereits während der Initialisierung einer neuen Edition eine Oxygen-Projektdatei angelegt wird, die die Transformationsszenarien zur Konvertierung der TEI-XML-Dateien nach HTML mittels XSLT enthält.

Die XSLT-Dateien sind modular aufgebaut. Sogenannte partials sind für Teile des zu generierenden HTML-Codes zuständig und können von anderen XSLT-Dokumenten eingebunden werden. Beispiele dafür wären etwa: partials/html_footer.xsl, partials/html_navbar.xsl oder partials/html_head.xsl. Damit wird die Duplizierung von Code reduziert und Elemente, die auf allen generierten HTML-Seiten anzutreffen sind, wie etwa ein Navigationsmenü oder eine Fußzeile, lassen sich in nur einer einzigen Datei ändern.

Spezialseiten wie eine Startseite (index.html), das Impressum (imprint.html) oder eine 404-Seite (404.html) werden mit entsprechenden XSLT-Dateien (index.xsl, imprint.xsl, 404.xsl) generiert.

Die eigentlichen TEI-XML-kodierten Editionsdateien werden vom in dem Verzeichnis data/editions erwartet. TEI-XML-kodierte Paratexte (z.B. ›Über das Projekt‹, ›Editionsrichtlinien‹, ›Team‹, …) in data/meta. Vom werden gleichnamige XSLT-Dateien (editions.xsl und meta.xsl) zur Verfügung gestellt, welche sämtliche in den genannten Verzeichnissen abgelegten Dateien nach HTML konvertieren.

Die HTML-Standarddarstellung der einzelnen Editionseinheiten ist bewusst einfach gehalten, was der großen Heterogenität von Editionsprojekten, den zu edierenden Dokumenten und der jeweiligen TEI-Kodierung geschuldet ist. Für häufig anzutreffende Kodierungsmuster stellt der mit dem Stylesheet partials/shared.xsl aber einige XSL-Templates bereit, etwa für TEI-kodierte Tabellen (tei:table, tei:row, tei:cell) und Listen (tei:list, tei:item), für Absätze (tei:p) und Zeilenumbrüche (tei:lb) oder für Verweise (tei:ref), Anmerkungen (tei:note), unklare Lesarten (tei:unclear), Streichungen (tei:del).

Ein eigenes Stylesheet toc.xsl iteriert über alle Dateien in data/editions, liest die Informationen aus dem TEI-Header aus und erstellt daraus ein Inhaltsverzeichnis der editierten Dokumente (toc.html). Dieses Inhaltsverzeichnis wird als Tabelle dargestellt. Dank der JavaScript-Bibliothek tabulator.info können Nutzer*innen die Sortierung der Tabelle ändern, die einzelnen Spalten durchsuchen, Spalten ein- und ausblenden und die Tabelle exportieren (HTML, JSON, CSV). Jede Zeile der Tabelle verlinkt auf die HTML-Seite des entsprechenden edierten Dokumentes. Da im Falle des dse-static-cookiecutters als die Datengrundlage für eine HTML-Tabelle (html:table) verwendet wird (möglich wäre auch eine JSON-Repräsentation der Daten), bleibt die Basisfunktion dieses Inhaltsverzeichnisses – Überblick zu den Inhalten der Editionseinheiten und Verlinkung zu diesen – aufrecht, selbst wenn zukünftige Browsergenerationen die verwendete -Version nicht mehr unterstützen sollten.

Als Registerdaten werden standardmäßig unterstützt: Personen-, Orts-, Organisations- und Werkregister. Dafür ist das Verzeichnis data/indices vorgesehen. XSLT-Dateien (listperson.xsl, listplace.xsl, listorg.xsl, listbibl.xsl) sind für deren Konvertierung verantwortlich, wobei diese Dateien eine spezifische TEI-Kodierung der Registereinträge erwarten (tei:listPerson, tei:listPlace, tei:listOrg, tei:listBibl). Für Registereinträge werden tabellarische Listenansichten generiert, welche ebenfalls mit Hilfe von interaktiv sind. Das Ortsregister wird außerdem durch eine Kartenansicht ergänzt (implementiert mittels Leaflet), sofern die dafür notwendigen Geodaten von den Editor*innen erhoben wurden.

Abb. 2: Ortsregister mit Kartenansicht aus dem Editionsprojekt . Angezeigt werden hier nur die in der Tabelle gefilterten Absendeorte. [Screenshot: Peter Andorfer 2025]

Die Kartenansicht ist mit der Ortstabelle verknüpft, das heißt, nur die in der Tabelle angezeigten Einträge werden auf der Karte dargestellt, so dass sich der Kartenausschnitt ändert, wenn Filter in der Ortstabelle angewandt werden. Zusätzlich wird für jeden Registereintrag, also für jede Person, jeden Ort, jedes Werk eine eigene HTML-Seite generiert. Diese präsentiert neben den im Registereintrag verzeichneten Informationen wie etwa dem Namen der Person, Lebensdaten, Normdaten (z.B. GND, Wikidata) auch eine Auflistung sämtlicher Editionseinheiten, in welchen besagte Entität erwähnt wird. Entitäten von Editionsprojekten sind somit eindeutig über ihre projektspezifischen URLs referenzierbar, wodurch andere Projekte auf diese verlinken können. Die Datei beacon.xsl verwendet diese URLs, um eine GND-Beacon-Datei Vgl. Wikipedia: BEACON. zu erstellen.

4. Lösungsansätze für Einschränkungen statischer Webseiten

5. Abschluss und Ausblick

Die vom implementierten Prinzipien ›statisch‹, ›automatisch‹ und ›ähnlich‹ sind weder neu noch originell. Static-Site-Generatoren gibt es schon lange – die erste Version (v1.0.0) von Jekyll wurde am 14. Juni 2013 veröffentlicht – und neue Frameworks zum Bau statischer Webseiten, wie beispielsweise eleventy oder Astro – werden laufend entwickelt. Am ACDH wurde seit etwa 2024 damit begonnen, bestehende Wordpress-Instanzen, die vornehmlich als Projekt- oder Konferenzwebseiten verwendet wurden, durch Astro-Webseiten zu ersetzen. Das Ziel ist, den Maintenance-Aufwand stark zu reduzieren. Statische Seiten finden auch in den digitalen Geisteswissenschaften ihre Verwendung, häufig im Kontext des Begriffs minimal computing, wie in: Minimal computing is static site generation. Risam / Gil 2022, S. 1. So handelt es sich beim Webauftritt von DHQ: Digital Humanities Quarterly um eine mittels XSLT und ANT generierte statische Seite, welche mit Hilfe von GitHub-Actions gebaut und veröffentlicht wird (und ihre Volltextsuche mit staticSearch implementiert). Vgl. Cummings 2023. Ähnlich funktioniert auch der Webauftritt von The Programming Historian, der auf basiert. Vgl. Lincoln et al. 2022. Und auch digitale Editionen werden abseits dse-static-cookiecutter-basierter Projekte in Form von statischen Seiten realisiert. Vgl. etwa Akademie der Wissenschaften und der Literatur Mainz (Hg.) 2025; Trautmann / Schrade (Hg.) 2018; Grallert (Hg.) 2022; Dumont (Hg.) 2025. Es bestehen auch Pläne, bestehende dynamische Editionen im Sinne einer besseren Langlebigkeit in statische Seiten zu konvertieren. Vgl. Jüngerkes / Kruse 2024.

Dass sich Projekte effizienter realisieren und warten lassen, wenn sie auf einen gemeinsamen respektive einen ähnlichen Quellcode zugreifen und den gleichen Technologie-Stack verwenden, dürfte offensichtlich sein. Dies trifft auch auf digitale Editionen zu. Dafür gibt es eine Reihe von Tools, welche sich zum Ziel gesetzt haben, die Erstellung und Publikation von TEI-XML-basierten digitalen Editionen zu unterstützen. Solche Tools reichen von generischen XSLT-Stylesheets zur Konvertierung von TEI-XML-Dateien nach HTML Vgl. TEI-Boilerplate oder TEIC/Stylesheets bzw. den entsprechenden Webservice teigarage. oder der JavaScript-Bibliothek CETEIcean für die Darstellung TEI-XML-Dateien im Webbrowser über out-of-the-box Lösungen für spezifische Editionstypen wie dem EVT-Viewer oder dem Edition-Crafter bis hin zu vielfach verwendeten Komplettlösungen wie etwa dem TEI Publisher. Vgl. Sutor / Mertgens 2024. Bei letzterem handelt es sich zwar um eine auf basierte, dynamische Applikation, allerdings wurde daran gearbeitet, statische Lösungen zu implementieren. Vgl. Meier 2022. Hinzu kommen die vielen Frameworks, Setups und Systeme, die an spezialisierten Institutionen wie Bibliotheken, Universitäten oder Akademien gepflegt werden. Vgl. Andorfer et al. 2017. Eine aktuelle Übersicht wäre sicherlich sehr gewinnbringend. Vgl. dazu etwa die Sondergausgaben von RIDE zu Tools and Environments.

Der versucht den Spagat zwischen einem spezifisch auf die Bedürfnisse des ACDH zugeschnitten Werkzeug und einem allgemein zugänglichen Tool zum Entwickeln und Publizieren von digitalen Editionen. Der spezifische Gebrauch am ACDH zeigt sich etwa in der im Initialisierungsprozess einer neuen Instanz gestellten Frage nach einer ›Redmine-ID‹ (welche anschließend benötigt wird, um eine aktuelle Impressum-Seite zu generieren) oder in der fehlenden Unterstützung von . Andererseits werden technologische und konzeptionelle Entscheidungen immer mit Blick darauf getroffen, einen technologisch möglichst niederschwelligen Einstieg zu ermöglichen. Während die bereits erwähnten Alternativen zum sehr stark auf JavaScript setzen, baut der primär auf XSLT-Transformationen zur Generierung der HTML-Seiten. Grundkenntnisse in X-Technologien sind in den digital affinen Geisteswissenschaften häufig vorhanden.Vgl. etwa den im Rahmen der TEI-Konferenz 2025 angebotenen Workshop: ›Navigating and Processing Data from the TEI with XPath and XSLT‹ oder die im Curriculum für das Masterstudium Digitale Geisteswissenschaften der Universität Graz vorgesehenen Kurse ›X-Technologien I und II‹ (Universität Graz (Hg.) 2021). Dies trifft auch auf die starke Integration des dse-static-cookiecutters mit GitHub und vor allem GitHub-Pages zu. Das ACDH hätte zwar eigene Ressourcen und Infrastruktur, womit sich der Build- und Deploy-Prozess individueller und flexibler gestalten ließe, Gedacht ist hier etwa an die Möglichkeit, sogenannte Feature-Branches zu deployen, oder an bessere Konfigurationsmöglichkeiten des Webservers. setzt aber bewusst auf GitHub und GitHub Pages, um auch jene Projekte zu unterstützen, die nicht auf eine vergleichbare Infrastruktur zurückgreifen können. Das Nicht-Unterstützen aktueller JavaScript-Tools wie etwa eines Package-Managers Ein Beispiel hierfür wäre NPM. zur Installierung der verwendeten Bibliotheken oder eines Build-Tool wie Vite für die Entwicklung und Implementierung projektspezifischer interaktiver Elemente ist ebenfalls eine bewusst getroffene Entscheidung mit dem Zweck, den Zugang zum einfach zu gestalten.

Ob Editionen, die mit dem realisiert wurden und werden, das eingangs gegebene Versprechen der Langfristigkeit einlösen können, wird die Zukunft zeigen. Die bisherigen Erfahrungen stimmen allerdings positiv. Was die weitere Entwicklung des dse-static-cookiecutters betrifft, so stehen aktuell die Bereiche Schnittstellen und Zitierbarkeit im Vordergrund. Darüber hinaus wird am ACDH gerade an einem zentralen Triplestore unter anderem für Entitäten aus digitalen Editionen Dies findet im Rahmen des Projekts PFP – Prosopographische Forschungsplattform Österreich, Laufzeit: 2024–2026, statt. und an einem linguistischen Suchservice Austrian Center for Digital Humanities (Hg.) 2025. zu automatisch linguistisch annotierten Volltexten digitaler Editionen gearbeitet, die grundsätzlich auch für Projekte außerhalb des ACDH offenstehen sollen.