Konfigurationen für Verarbeitung und Visualisierung
Um editorische Arbeitsdateien für die verschiedenen Arten der Visualisierung aufzubereiten, werden sie in ›heiEDITIONS‹ durch XProc-Verarbeitungspipelines geleitet. Solche Pipelines können mit bestimmten Parametern und begleitet durch Konfigurationsdateien aufgerufen werden, um spezifische Informationen festzulegen, entweder pauschal für ein ganzes Editionsprojekt oder einzeln pro Editionstext.
Konfigurationsdateien sollen in ›heiEDITIONS‹ innerhalb des GitLab-Repositoriums eines Editionsprojekts im Verzeichnis configurations vorgehalten werden.
Konfiguration einer virtuellen Textgliederung
Editionstexte können in einem TEI-Dokument innerhalb des Elements <text> mithilfe von <front>, <body> und <back> sowie weiter mit einer beliebig tiefen Hierarchie von <div>-Elementen gegliedert werden. Eine solche Gliederung kann sich auf visuelle Signale einer historischen Quelle stützen oder rein editorisch sein.
Gliederung stand-off Es mag mindestens zwei Gründe geben, die Gliederung eines Editionstextes der eigentlichen Arbeitsdatei mit dem Text fernzuhalten und sie separat (stand-off) zu beschreiben:
- Bei langen Texten, die über eine sehr flache Struktur verfügen (z. B. mittelalterliche Versromane mit vielen Tausenden von Versen ohne eine Kapitelstruktur) kann es für eine sinnvolle Navigation und effiziente Anzeige in der Leseansicht sinnvoll sein, eine künstliche Gliederung allein für die Anzeigezwecke festzulegen. So kann ein langer Text in nicht allzu lange Abschnitte für die Anzeige aufgeteilt werden, ohne dass dem Text in der Arbeitsdatei selbst eine eigentlich fremde und verfremdende Struktur ›aufgezwungen‹ werden müsste.
- Über eine externe Gliederungsbeschreibung wäre es auch möglich, eine alternative Gliederung festzulegen, selbst wenn in der Arbeitsdatei schon eine Gliederung vorliegt. So könnte z. B. neben der Gliederung, die sich an visuellen Merkmalen einer Quelle orientiert, parallel noch eine editorisch veränderte Gliederung erstellt werden, die zur Visualisierung in der Leseansicht herangezogen wird.
Für die stand-off-Beschreibung einer Gliederung bedarf es jeweils pro Text einer eigenen Konfigurationsdatei (eine pauschale Gliederungskonfiguration für mehrere Texte gleichzeitig ist nicht möglich). Der Name einer solchen Datei soll sich aus structure_ und dem Namen derjenigen Editionsdatei zusammensetzen, auf deren Text sich die Gliederung bezieht. Die Konfigurationsdatei ist eine XML-Datei mit dem Suffix .xml. So würde hypothetisch zu einer Editionsdatei texts/WelscherGast_A.xml eine Strukturkonfigurationsdatei configurations/structure_WelscherGast_A.xml existieren.
Die Strukturkonfigurationsdatei hat das Wurzelelement <TEI> und verwendet auch sonst Elemente des TEI-Namensraums http://www.tei-c.org/ns/1.0, sie folgt aber dem ›heiEDITIONS‹-eigenen speziellen Schema ↪ https://digi.ub.uni-heidelberg.de/schema/tei/heiEDITIONS/structure_configuration_schema.rng , das auf dem ODD-Dokument ↪ structure_configuration_schema.odd basiert. Die Angabe des Schemas für Validierungszwecke kann der Musterdatei ↪ structure_xy.xml entnommen werden.
Das erste Kindelement der Datei ist die Präfixdeklaration <listPrefixDef>, in der erstens – wie auch sonst immer in ›heiEDITIONS‹ – das Präfix hc für den URI der Ontologie ›heiEDITIONS Concepts‹ und zweitens das Präfix wit als Stellvertreter für den relativen Pfad zur entsprechenden Editionsdatei deklariert werden. Das Präfix wit fungiert also im Weiteren als Abkürzung des Pfades und des Dateinamens der Datei, in der der Text enthalten ist, auf den die virtuelle Struktur angewandt werden soll. Im folgenden Beispiel steht wit für eine Datei, die im Projektrepositorium der Edition unter texts/tagebuch.xml zu finden wäre; der relative Pfad geht davon aus, dass die Strukturkonfigurationsdatei im Projektrepositorium im Verzeichnis configurations liegt – deswegen gibt der Pfad zunächst einen Schritt ›nach oben‹ ins Elternverzeichnis an.
Das zweite Kind des Wurzelelements <TEI> (es muss immer genau zwei Kindelemente geben) definiert das Element in der Editionsdatei, auf dessen Inhalt die virtuelle Struktur angewandt werden soll. Das kann entweder <text> oder <body> sein. <text> ist zu verwenden, wenn sich die virtuelle Struktur nicht nur auf den Inhalt des <body> im Editionsdokument beziehen soll, sondern wenn neben <body> auch noch <front> oder <back> (oder beides) für die virtuelle Struktur zur Anwendung kommen sollen. Je nach dem, ob hier <text> oder <body> angegeben ist, wird in der Verarbeitung entweder die ggf. vorgefundene Gliederung (<front>, <body>, <back>, <div> auf beliebiger Ebene) im gesamten <text> entfernt und durch die virtuelle Struktur ersetzt oder nur ggf. vorgefundene <div>-Elemente innerhalb von <body>. Das Element <text> oder <body> bleibt dabei selbst (ggf. mit seinen Attributen) in der Editionsdatei jeweils unangetastet, nur dessen Inhalt wird verarbeitet.
Der Inhalt von <text> oder <body> in der Konfigurationsdatei bildet dann den gewünschten Gliederungsbaum ab, dessen wesentliche Struktur entweder aus <front>, <body>,<back> und darin befindlichen <div>-Strukturen besteht (wenn in der Konfigurationsdatei das zweite Kindelement von <TEI> <text> ist) oder aus <div>-Strukturen (wenn in der Konfigurationsdatei das zweite Kindelement von <TEI> <body> ist).
In einem so deklarierten Baum übernehmen dann jeweils in den kleinsten Gliederungseinheiten (die selbst keine weitere tiefer gelegene Gliederungseinheit enthalten) die <ptr>-Elemente die Funktion der Platzhalter für jene Dateibereiche, die mit den virtuellen Einheiten umschlossen werden sollen.
Betrachten wir als einfaches Beispiel ein <body>, das in der Editionsdatei eine ›flache‹ Abfolge von neun Absätzen enthält:
Auf dieses <body> soll eine virtuelle Gliederung angewandt werden, die jeweils drei Absätze in einem <div> zusammenfasst. Dafür sähe das zweite Kindelement der Strukturkonfigurationsdatei so aus:
Die Bereiche der Editionsdatei, die innerhalb des dort befindlichen <body> mit <div>-Elementen umschlossen werden sollen, werden in @target der <ptr>-Elemente als ›von–bis‹-Verweise auf die @xml:id des jeweils ersten und letzten Elements eines Bereichs angegeben, und zwar mithilfe von der TEI definierten range-Pointer-Syntax 1) mit dem vorangestellten Präfix wit, das den Pfad zur Editionsdatei repräsentiert. Die durch ein Komma getrennten beiden Werte innerhalb der Klammern von range() sind die @xml:id-Werte des ersten und letzten Elements eines Abschnitts. Bevor also eine solche Konfiguration sinnvoll geschrieben werden kann, müssen im Editionsdokument zumindest an den betroffenen jeweils ersten und letzten Elementen eines virtuellen Abschnitts die Attribute @xml:id vorliegen – sonst wären die ›Grenzen‹ der virtuellen Abschnitte nicht fassbar.
Es wird empfohlen, ist aber nicht zwingend notwendig, dass die virtuellen <div>-Elemente das Attribut @ana tragen. Wenn keine andere ›heiEDITIONS‹-Klasse besser zutrifft, kann dabei als Wert das generische › hc:Section ‹ gewählt werden. Das Attribut @xml:id wird ebenfalls benötigt, wird aber – falls es fehlen sollte – in der Verarbeitungspipeline ergänzt. Mit dem Attribut @n kann eine sinnvolle Nummerierung angegeben werden, was für eine übersichtliche Navigation im Inhaltsverzeichnis hilfreich ist.
Neben den genannten Attributen @ana, @xml:id und @n kann an <div> ebenfalls das Attribut @rendition mit den möglichen Werten › hc:DisplayDivision ‹ oder › hc:SuppressInTOC ‹ angegeben werden (dazu s. weiter unten Konfiguration der Textaufteilung und der Anzeige im Inhaltsverzeichnis).
Sinnvollerweise sollten die virtuell deklarierten Gliederungseinheiten mit editorischen Überschriften versehen werden, um die Abschnitte verständlicher und in einem Inhaltsverzeichnis greifbarer zu machen. Dafür kann am Anfang jedes <div> ein Element <head> (oder für mehrsprachige Überschriften auch mehrfaches <head>, jeweils mit einem unterschiedlichen @xml:lang versehen) platziert werden, das an @ana mit der Klasse › hc:EditorialContent ‹ versehen ist, um deutlich zu machen, dass der Text der Überschrift weder genuiner noch rekonstruierter Bestandteil des Primärtextes ist.
Das obige Beispiel mit den Dreiergruppen von Absätzen könnte also – weiter angereichert – etwa so aussehen:
Wenn sinnvoll, kann eine virtuelle Gliederung auch mehrere <div>-Ebenen umfassen. Das folgende Beispiel zeigt, wie die ursprünglich flache Beispielstruktur mit neun Absätzen in eine neue Struktur überführt wird, in der Absatz 1 in einem eigenen <div> auf oberster Ebene steht, die folgenden sieben Absätze in einem größeren Abschnitt zusammengefasst sind, der seinerseits Unterabschnitte mit den Absätzen 2–3, 4–5 sowie 6–8 enthält und der letzte Absatz 9 wiederum in einem eigenen <div> auf oberster Ebene steht:
Die <ptr>-Elemente als Stellvertreter für die zu umschließenden Textbereiche dürfen jeweils nur auf der untersten <div>-Ebene stehen, d. h. eine Gliederungseinheit darf nicht gleichzeitig <ptr> und <div> als Geschwisterelemente enthalten.
Wenn für die im vorangehenden Beispiel gezeigte Gliederung statt einer zweistufigen <div>-Hierarchie eine Kombination von <front>, <body> und <back> mit drei <div>-Abschnitten innerhalb von <body> zum Einsatz kommen sollte, ist das zweite Kindelement der Konfigurationsdatei <text> statt <body>. Ansonsten bleibt das Prinzip gleich (mit dem Unterschied, dass <front>, <body> und <back> keine Attribute @ana tragen, weil sie als Elemente durch ihre Semantik in ihrer Gliederungsfunktion ausreichend beschrieben sind):
Konfiguration der Textaufteilung und der Anzeige im Inhaltsverzeichnis
Aus den innerhalb von <text> verwendeten Gliederungseinheiten (besonders <div>, aber auch <front>, <body> und <back>) wird für die Leseansicht im ›heiVIEWER‹ ein Inhaltsverzeichnis erzeugt, das sowohl für die Navigation innerhalb eines gerade angezeigten Textes als auch zum Wechsel in einen gerade nicht angezeigten Abschnitt genutzt werden kann. Letzteres ist relevant, wenn der Text angrund seiner Länge nicht gleichzeitig ganz angezeigt wird, sondern wenn er für die Anzeige in kleinere sinnvolle Abschnitte eingeteilt wird.
Aufteilung für Anzeige Wenn es gewünscht ist, einen Text für die Anzeige in der Leseansicht in kleinere Abschnitte einzuteilen, wird an den Elementen dieser gewählten Abschnitte (<front>, <body>, <back>, <div>) während der Verarbeitung am Attribut @rendition der Wert hc:DisplayDivision erzeugt (s. › hc:DisplayDivision ‹). Bei der Festlegung, welche Elemente als solche Anzeigeabschnitte markiert werden, ist darauf zu achten, dass keine Lücken verbleiben, durch die bestimmte Inhalte von der Anzeige ganz ausgeschlossen würden (es sei denn, gerade dies wäre editorische Absicht).
Die Markierung von Gliederungseinheiten als › hc:DisplayDivision ‹ ist allein für die Visualisierung vorgesehen und sollte nicht bereits in den Arbeitsdateien erfolgen. Stattdessen sehen wir vor, die Kennzeichnung mit › hc:DisplayDivision ‹ in separaten Dateien zu konfigurieren, die während der Verarbeitung eingelesen werden (s. u.).
Wie schon angesprochen, ist bei der Zuweisung der Klasse › hc:DisplayDivision ‹ an Gliederungseinheiten des Textes dafür Sorge zu tragen, dass innerhalb von <text> keine textuellen Inhalte übrig bleiben, die von keiner › hc:DisplayDivision ‹ abgedeckt wären. Allenfalls übergeordnete Gliederungseinheiten ohne eigentlichen Inhalt können als Ausnahme gelten, da diese – ggf. mit ihren als <head> kodierten Überschriften – zumindest im Inhaltsverzeichnis sichtbar wären. Das folgende Codebeispiel soll dies verdeutlichen (wobei das Attribut @rendition so nicht in einer Arbeitsdatei stünde, sondern als Ergebnis einer entsprechenden Konfiguration in die Datei maschinell geschrieben würde):
Im vorangehenden Beispiel ist es in Ordnung, dass das Element <div> mit dem Identifikator abschnitt_1 keine Kennzeichnung als › hc:DisplayDivision ‹ erfährt. Zwar wird diese Gliederungseinheit als Ganzes nie im Hauptfenster der Leseansicht angezeigt, aber der Abschnitt ist als Gliederungseinheit mit seiner Überschrift zumindest im Inhaltsverzeichnis sichtbar. Der vollen Anzeige zugeführt werden stattdessen seine zwei untergeordneten Abschnitte abschnitt_1_1 und abschnitt_1_2. Wenn ein Nutzer im Inhaltsverzeichnis den Eintrag für abschnitt_1 anklickt, wird im Hauptfenster der Leseansicht das erste als Anzeigeabschnitt konfigurierte Element angezeigt, also abschnitt_1_1.
Dass hingegen abschnitt_3 nicht als › hc:DisplayDivision ‹ gekennzeichnet ist, wird dazu führen, dass die Anzeige dieses Abschnitts im Hauptfenster der Leseansicht unterbunden wird. Es gilt also: Wenn auch nur ein Gliederungselement in einer Datei als › hc:DisplayDivision ‹ gekennzeichnet ist, wird im ›heiVIEWER‹ davon ausgegangen, dass keine Anzeige des gesamten Dokuments in der Leseansicht erwartet wird. Gliederungselemente, die weder selbst als › hc:DisplayDivision ‹ gekennzeichnet sind noch solche Elemente als ancestor ›über sich‹ haben, können mit ihrem textuellen Inhalt in der Leseansicht nicht angezeigt werden (das gilt natürlich nur, wenn die Auswertung von › hc:DisplayDivision ‹ für einen Editionstext grundsätzlich aktiviert wurde, also wenn für einen Editionstext von einer Teilanzeige ausgegangen wird). Allerdings verhindert das Fehlen der Kennzeichnung als › hc:DisplayDivision ‹ bei abschnitt_3 im vorliegenden Beispiel nicht die Anzeige der Gliederungseinheit im Inhaltsverzeichnis; das Anklicken dieses Eintrags im Inhaltsverzeichnis würde zu einem Fehler führen oder zum ersten tatsächlich darstellbaren Abschnitt des Textes weiterleiten. (Um die Anzeige im Inhaltsverzeichnis zu unterdrücken, müsste der Abschnitt als › hc:SuppressInTOC ‹ markiert werden – s. u.)
In besonderen Fällen ist es jedoch möglich, mehrere ineinander geschachtelte Gliederungselemente gleichzeitig als › hc:DisplayDivision ‹ zu kennzeichnen. Das folgende Beispiel soll dies verdeutlichen:
In diesem besonderen Fall sind sowohl das <div> mit dem Identifikator di_1 als auch seine beiden untergeordneten Abschnitte di_1_1 und di_1_2 als › hc:DisplayDivision ‹ gekennzeichnet. Diese Lösung kann sinnvoll sein, wenn di_1_1 und di_1_2 von einer Länge sind, die ihre Anzeige als jeweils separate Abschnitte in der Leseansicht erfordert, und wenn sich gleichzeitig innerhalb von di_1 mit den beiden <p>-Elementen Inhalte befinden, die außerhalb von di_1_1 und di_1_2 stehen. Durch eine solche Kennzeichnung können sowohl der unmittelbare Inhalt von di_1 (also die beiden <p>-Elemente und Platzhalter für di_1_1 und di_1_2) als auch jeweils separat die Abschnitte di_1_1 und di_1_2 im Inhaltsverzeichnis ausgewählt und im Hauptfenster der Leseansicht zur Anzeige gebracht werden.
Ausblenden im Inhaltsverzeichnis Unabhängig davon, ob ein Text für die Anzeige in der Leseansicht aufgeteilt wird (also ob › hc:DisplayDivision ‹ verwendet wird oder nicht), kann die Anzeige bestimmter Gliederungseinheiten im Inhaltsverzeichnis unterdrückt werden. Das können z. B. tiefer geschachtelte Untergliederungen (etwa <div>-Elemente, denen schon zwei Ebenen von <div>-Elementen übergeordnet sind) oder irrelevante Abschnitte am Anfang oder Ende eines Textes sein (etwa die Titelei oder eine Widmung am Anfang oder Anhänge am Ende). Solche Gliederungselemente werden während der Verarbeitung an @rendition mit dem Wert hc:SuppressInTOC markiert (s. › hc:SuppressInTOC ‹). Auch diese Kennzeichnung soll nicht direkt in Arbeitsdateien erfolgen, sondern kann entsprechend konfiguriert werden (s. u.).
Grundsätzlich gilt, dass jedes <div> (und auch <front> und <back>, ja auch <body>, wenn es über eine eigene Überschrift verfügt) egal welcher Schachtelungsstufe im Inhaltsverzeichnis angezeigt wird.2) Durch die Konfiguration der Zuweisung von › hc:SuppressInTOC ‹ ist es möglich, bestimmte Gliederungselemente im Inhaltsverzeichnis auszublenden. Wenn in der Leseansicht jeweils der ganze Editionstext angezeigt wird, wird ein solcher Abschnitt dennoch als Teil des Textes angezeigt und kann durch händisches Scrollen erreicht werden; wenn hingegen der Text abschnittsweise präsentiert wird (per Konfiguration von › hc:DisplayDivision ‹), wird ein Abschnitt nie eingeblendet werden können, wenn er als › hc:SuppressInTOC ‹ gekennzeichnet ist und kein sein ancestor-Element als › hc:DisplayDivision ‹ markiert ist (die gleichzeitige Markierung eines Elements als › hc:DisplayDivision ‹ und › hc:SuppressInTOC ‹ ist nicht möglich). Sehr wohl möglich und geradezu vorgesehen ist aber die Möglichkeit, Unterabschnitte von der Anzeige im Inhaltsverzeichnis auszuschließen, aber ein ihnen übergeordnetes Element als › hc:DisplayDivision ‹ zu deklarieren. Dann werden die Unterabschnitte mit ihren Inhalten in der Leseansicht angezeigt und sind durch Scrollen erreichbar, sie können aber nicht indiviuell aus dem Inhaltsverzeichnis heraus angesprungen werden. Ein solches Szenario ist besonders dafür geeignet, das Inhaltsverzeichnis von der Einblendung kleiner Gliederungsabschnitte in feinkörnig gegliederten Editionstexten zu entlasten.
Die eigentliche Konfiguration der Zuweisung von › hc:DisplayDivision ‹ und › hc:SuppressInTOC ‹ kann grundsätzlich auf zweifache Weise erfolgen:
Wenn Editionstexte für die Leseansicht ohnehin durch Strukturkonfigurationsdateien (s. o. Konfiguration einer virtuellen Textgliederung) aufgeteilt werden, können die Werte hc:DisplayDivision bzw. hc:SuppressInTOC bereits in diesen Dateien an @rendition von <div> (bzw. auch <front>, <body> und <back>) angegeben werden. Das Attribut @rendition wird mit den virtuellen Gliederungselementen in die zu verarbeitenden Dateien übernommen.
Die andere Möglichkeit (wenn keine Strukturkonfigurationsdateien vorliegen oder zusätzlich zu solchen) besteht darin, Konfigurationsangaben zu › hc:DisplayDivision ‹ und › hc:SuppressInTOC ‹ in separaten Anzeigekonfigurationsdateien vorzunehmen.
Anzeigekonfigurationsdateien können neben › hc:DisplayDivision ‹ und › hc:SuppressInTOC ‹ noch anderen Zwecken dienen (s. u.). Sie können global pro Editionsprojekt oder spezifisch für einzelne Editionstexte angelegt werden. Es ist auch möglich, z. B. die Konfiguration von › hc:DisplayDivision ‹ und › hc:SuppressInTOC ‹ global in einer zentralen Anzeigekonfigurationsdatei vorzunehmen und andere Dinge textspezifisch in Einzeldateien zu konfigurieren.
Anzeigekonfigurationsdateien sollten – wie auch andere Konfigurationen – innerhalb des GitLab-Repositoriums eines Editionsprojekts im Verzeichnis configurations vorgehalten werden. Für die Benennung einer Anzeigekonfigurationsdatei Datei soll gelten: Der Name einer solchen Datei soll sich aus display_ und dem Namen derjenigen Editionsdatei zusammensetzen, auf deren Text sich die Gliederung bezieht. Die Konfigurationsdatei ist eine XML-Datei mit dem Suffix .xml. So könnte hypothetisch zu einer Editionsdatei texts/WelscherGast_A.xml eine Anzeigekonfigurationsdatei configurations/display_WelscherGast_A.xml existieren. Wenn es sich um eine globale Konfigurationsdatei handeln würde, die für alle Texte des Editionsprojekts gelten soll, soll sie display_all.xml heißen.
Eine Anzeigekonfigurationsdatei hat das Wurzelelement <configuration> im Namensraum https://digi.ub.uni-heidelberg.de/schema/tei/heiEDITIONS und folgt dem ›heiEDITIONS‹-eigenen speziellen Schema ↪ https://digi.ub.uni-heidelberg.de/schema/tei/heiEDITIONS/display_configuration_schema.rng , das auf dem ODD-Dokument ↪ display_configuration_schema.odd basiert. Die Angabe des Schemas für Validierungszwecke kann der Musterdatei ↪ display_xy.xml entnommen werden.
Die Konfiguration der Zuweisung von › hc:DisplayDivision ‹ erfolgt innerhalb des Wurzelelements <configurations> mit dessen Kindelement <displayDivision>. Die Konfiguration kann auf dreifache Weise erfolgen: Für einzelne Elemente durch die Nennung ihrer @xml:id, gruppenweise über die Angabe einer ›heiEDITIONS‹-Klasse (die am gewünschten Zielelement an @ana angegeben wäre) oder schließlich gruppenweise durch die Deklaration eines XPath-Ausdrucks, der Elemente über einen mit XPath definierten Pfad adressiert. (Die dritte Möglichkeit ist sicherlich am flexibelsten, ist aber momentan aus technischen Gründen noch nicht nutzbar.) Grundsätzlich können alle drei Möglichkeiten auch miteinander kombiniert werden. Die Elemente und erwarteten Elementinhalte für die gennanten drei Konfigurationsmöglichkeiten sind:
- <ID>: enthält als Textknoten die @xml:id eines einzelnen Elements
- <class>: enthält als Textknoten die an @ana angegebene ›heiEDITIONS‹-Klasse eines Elements oder einer Elementgruppe (ohne das Präfix hc)
- <XPath>: enthält als Textknoten einen XPath-Ausdruck, bezogen auf das Wurzelelement <TEI> und unter impliziter Annahme des TEI-Namensraums
Jedes der genannten Konfigurationselemente kann sich beliebig oft wiederholen. Beispiel:
Diese beispielhafte Belegung von <displayDivision> würde die Verarbeitung veranlassen, an den beiden über ihre @xml:id addressierten Elementen <front> und <back>, an allen Elementen mit der Angabe hc:Chapter am Attribut @ana sowie an allen <div>-Elementen auf direkter Kindebene von <body> den Wert hc:DisplayDivision am Attribut @rendition einzutragen.
Die Zuweisung von › hc:SuppressInTOC ‹ funktioniert auf gleiche Weise in einem Element <suppressInTOC>, z. B.:
Konfiguration der Übernahme visueller Informationen
Editionsdateien, die den Text einer historischen Quelle (z. B. einer Handschrift oder eines alten Drucks) dokumentieren und wiedergeben, enthalten in ›heiEDITIONS‹ in der Regel auch zahlreiche Informationen über visuelle Eigenschaften der Quelle. Dazu gehören Angaben über Layout sowie verschiedene Informationen über die visuelle Beschaffenheit von Textsegmenten, etwa über verschiedene Arten der Auszeichnung oder die äußere Art von Eingriffen oder Schäden.
Für die Leseansicht von ›heiEDITIONS‹ wird primär davon ausgegangen, dass dort solche visuellen Informationen irrelevant sind. Dennoch kann es in bestimmten Situation wichtig sein, ausgewählte Informationen dieser Art für die Leseansicht zu bewahren, etwa die Angabe über Hoch- oder Tiefstellung einzelner Buchstaben. Daneben ist auch die Möglichkeit nicht völlig ausgeschlossen, alle visuellen Informationen der Arbeitsdatei in die Leseansicht-Kodierung zu übernehmen, wenn das aus spezifischen Gründen erforderlich wäre.
Für die Fälle, in denen visuelle Informationen für die Leseansicht weder pauschal getilgt noch komplett übernommen werden sollen, gibt es die Möglichkeit einer Konfiguration. Eine solche Konfiguration erfolgt in einer globalen oder textspezifischen Konfigurationsdatei, deren Name auf display_ anfängt, wie schon oben in Konfiguration der Textaufteilung und der Anzeige im Inhaltsverzeichnis beschrieben. Sie kann (und soll) in derselben Datei wie die Konfiguration der Aufteilung der Textanzeige und der Anzeige im Inhaltsverzeichnis erfolgen, um die Anzahl der Konfigurationsdateien nicht ohne Not wachsen zu lassen. Für den Speicherort, die Dateibenennung, das Schema, den Namensraum und das Wurzelelement gilt dasselbe, was schon oben in Konfiguration der Textaufteilung und der Anzeige im Inhaltsverzeichnis ausgeführt ist.
Aktuell ist nur für die differenzierte Behandlung der ›heiEDITIONS‹-Klassen im Attribut @rendition eine Konfiguration vorgesehen. Dafür wird auf der Kindebene des Wurzelelements <configuration> das Element <renditionFilter> angelegt. <renditionFilter> verfügt seinerseits über zwei mögliche Kindelemente, die aber nicht beide gleichzeitig vorhanden sein dürfen:
- <include>: gibt in positiver Weise ›heiEDITIONS‹-Klassen an, die für die Leseansicht bewahrt werden sollen, ggf. auch nur an einem spezifischen Element
- <exclude>: gibt in negativer Weise ›heiEDITIONS‹-Klassen an, die für die Leseansicht ausgeschlossen werden sollen, ggf. auch nur an einem spezifischen Element
Die Konfiguration funktioniert also entweder als ›Positivliste‹ oder als ›Negativliste‹, eine Kombination der beiden Möglichkeiten ist global oder für einen bestimmten Editionstext nicht möglich.
Die Elemente <include> und <exclude> sehen als ihren Inhalt die Kindelemente <class> vor, in denen jeweils als Textknoten eine ›heiEDITIONS‹-Klasse (ohne das Präfix hc) angegeben wird, z. B.:
Durch diese Konfiguration werden die Klassenangaben hc:Superscript, hc:Subscript und hc:Centered, wenn sie an beliebigen Elementen im Attribut @rendition vorkommen würden, für die Leseansicht bewahrt; alle anderen ggf. in @rendition vorkommenden Klassen werden entfernt. Wenn die Konfiguration nicht für alle, sondern nur ausgewählte Elemente gelten soll, kann diese Einschränkung an <class> mit dem Attribut @onElement vorgenommen werden. Im Attribut @onElement können – in der sogenannten Clark-Syntax3) und bei Mehrfachangaben durch Leerzeichen getrennt – Elemente aufgelistet werden, auf die die Konfiguration eingeschränkt werden soll, z. B.:
Durch diese Konfiguration werden nur an den explizit gelisteten Elementen <seg> und <hi> bzw. <p> die Klassen › hc:Superscript ‹ und › hc:Subscript ‹ bzw. › hc:Centered ‹ übernommen, an allen anderen Elementen werden diese und alle anderen @rendition-Werte entfernt.
Das alternativ zu <include> zur Verfügung stehende Element <exclude> funktioniert entsprechend ähnlich, nur eben mit umgekehrter Wirkung: Es werden alle Angaben an @rendition für die Leseansicht übernommen, außer denen, die in <exclude> explizit angegeben sind, z. B.:
Durch eine solche Konfiguration werden nur die Klassen › hc:RubbedOff ‹, › hc:CutOff ‹ sowie › hc:TornOff ‹ aus der Kodierung für die Leseansicht entfernt, an allen Elementen, an denen sie in @rendition vorkommen würden. Mit einer Einschränkung auf bestimmte Elemente könnte die Konfiguration so aussehen:
Auf diese Weise würden die angeführten drei Klassen jeweils nur vom Element <del> entfernt, beispielsweise an <gap> blieben sie weiterhin erhalten.4)
Für das ›heiEDITIONS‹-eigene Attribut @hei:color gibt es keine differenzierte Konfigurationsmöglichkeit für einzelne Farben, in einer Verarbeitungspipeline kann aber festgelegt werden, ob dieses Attribut als solches für die Leseansicht übernommen oder entfernt wird.
