XML Workflow

Auf dieser Seite wird der XML-Workflow beschrieben, also die Umwandlung eines ​DESpecs-konformen Rohtextes in einen Schema-konformen XML-Text.

Bisher sind 19 schemakonforme Texte bei ECHO, siehe ​mpdl-proto und ​echotest. Bis auf ​Alvarus, ​Benedetti 1585 und ​Song Yingxing sind alle Texte mit den hier beschriebenen Workflow-Skripten erzeugt worden.

Die Arbeitsschritte

Der XML-Workflow besteht aus mehreren Arbeitsschritten. Im ersten Schritt werden alle Vorbereitungen getroffen, um mit dem raw text arbeiten zu können. Im zweiten Schritt wird der raw text annotiert und korrigiert. Im dritten Schritt wird der annotierte raw text in wohlgeformtes XML verwandelt. Im vierten Schritt wird der XML-Text schemakonform gemacht. Der dritte und der vierte Schritt laufen weitgehend automatisch ab.

Die Arbeitsschritte bestehen jeweils aus einer Reihe von Skripten. Einige dieser Skripte sind noch leere Platzhalter, aber die Workflow-Struktur stimmt bereits.

• Im Gegensatz zu den früheren Skripten dürfen die hier beschriebenen Bearbeitungsschritte die Zeilenstruktur verändern, zum Beispiel eine Zeile hinzufügen.
• Beachte, dass Work Orders 1 bis 5 mit den ​DESpecs 1.1.2 und Work Orders 6 bis 9 mit den ​DESpecs 2.0 geschickt wurden. Unterschiede sind zum Beispiel das Format von Figures und von Tabellen.
• Ein Stern * bei einem Filter bedeutet: Wenn man zum raw text zurückkehrt, muss dieses Skript anschließend noch einmal angewendet werden. Alle Skripte mit * laufen automatisch ab; Ausnahme könnte später das <s>-Skript sein. Die automatischen Skripte sollten soweit wie möglich in Meta-Skripten abrufbar sein.
• Namenskonvention bei den Skripten: check als Vorbereitung, test als Nachbereitung. Alle anderen Skripte müssen wiederholt werden, wenn man wieder mit dem raw text anfängt.

1. Vorbereitungen

In diesem Schritt werden alle Vorbereitungen getroffen, um mit dem raw text arbeiten zu können. Insbesondere werden Verzeichnisse angelegt und Dateien kopiert.

• Im Gegensatz zu den weiteren Skripten ist zumindest das Skript in Schritt 1.01 kein Text-Filter, denn man arbeitet hier noch gar nicht mit einem Text-Editor.
• Wenn wir einen transkribierten Text aus China erhalten, muss zuerst geprüft werden, ob die Datei tatsächlich, wie in den DESpecs verlangt, reiner Text in ​UTF-8 ist. Insbesondere akzeptieren wir keine doc-Dateien.
• Es ist noch nicht ganz klar, wo neue Dateien in Zukunft abgelegt werden: Kommen sie wie bisher zuerst nach ​Pythia oder gleich in das wiki-repository? Ich gehe vorläufig davon aus, dass Texte weiterhin zuerst nach Pythia kommen. Die Namenskonvention auf Pythia ist bisher Workorder_Autor_Jahr.

1.01 Von Pythia ins svn-repository

Das Skript Filter_1_01_import_text​ legt die Verzeichnisse im repository an und kopiert den Text von Pythia in das repository.

• Im Texte-Verzeichnis Unterverzeichnisse anlegen (allerdings nerven die raw/xml-Verzeichnisse in der Praxis)
• Datei aus Pythia rüberkopieren
• Kopie erstellen und umbenennen (autor_jahr_identifier), Zeilenenden von CRLF zu LF. Entferne ​BOM-Fragmente (korrekte BOMs sind okay).

(Shell-Skript von Klaus)

1.02 Kommunikation mit Foxridge

Das Skript Filter_1_01_import_metadata​ kommuniziert mit Foxridge. Das Skript setzt voraus, dass der Identifier im Dateinamen steht. (Das Skript wird daher nicht mit Archimedes-legacy-Verzeichnissen funktionieren.)

Erstelle eine lokale Kopie der entsprechenden index.meta-Datei (funktioniert nur innerhalb des Instituts):

http://content.mpiwg-berlin.mpg.de/mpiwg/online/permanent/archimedes_repository/large/catan_belli_502_la_1600/index.meta
http://content.mpiwg-berlin.mpg.de/mpiwg/online/permanent/library/2UZM8E2N/index.meta

Extrahiere daraus die Metadaten und schreibe sie unbearbeitet in den metadata-Block (siehe Schritt 2) in den raw text. Die Metadaten werden wörtlich übernommen, das Format wird erst in Schritt 2.01 angepasst. Übernommen werden (jeweils in <resource>/<meta>):

• <author>
• <title>
• <year>
• <lang> (​ISO 639-1, d.h. zweistellig)
• (bisher noch nicht: <publisher>, <city>, <number_of_pages>, <translator>)

Finde den pageimg-Unterordner (default ist pageimg/) und schreibe die JPG-Dateinamen unbearbeitet in den pageimg-Block (siehe Schritt 2) in den raw text.

Änderungen in index.meta:

• index.meta neu formatieren.
• Wenn <texttool> noch nicht vorhanden ist, anlegen.
• Pageimg und figures anlegen, aber unverändert lassen, wenn es sie schon gibt.
• text-url-path anlegen: Sprache aus z.B. <lang>it</lang>.

Das Skript meldet sich nicht bei Foxridge an. Die Änderungen in index.meta werden daher nur in der lokalen Kopie gemacht. Es fehlt also:

• Sicherheitskopie von index.meta anlegen (auch lokal?): Umbenennen von index.meta in index.meta.old, eine ältere Sicherheitskopie mit demselben Namen wird ohne Nachfrage überschrieben.
• Schreibe die neue index.meta

(Die Trennung der Schritte „Vorbereitung“ und „raw text bearbeiten“ wird nicht vollkommen eingehalten, denn dieses Skript schreibt bereits Daten in den raw text. Man könnte die Metadaten und JPG-Dateinamen auch erst in getrennte Dateien schreiben, aber ich wüsste nicht, was dadurch gewonnen wäre.)

2. raw text bearbeiten

In diesem Arbeitsschritt wird der raw text auf die Umwandlung in XML vorbereitet. Die ersten beiden Skripte bearbeiten die Einträge, die Filter_1_01_import_metadata​ im raw text gemacht hat. Alle weiteren Skripte ändern den raw text gar nicht, sondern finden Stellen, die per Hand geändert werden müssen. Diese Änderungen werden soweit möglich am Anfang der Datei gemacht. Nur wenn es nicht anders geht, wird der Text selbst geändert.

Am Anfang der Datei sind folgende Gruppen erlaubt, in beliebiger Reihenfolge, jeweils durch eine Leerzeile getrennt, vor dem ersten <pb> (d.h. vor dem eigentlichen Text):

• metadata: (kopiert aus index.meta in Schritt 1.02, korrigiert in Schrtt 2.01, aufgelöst in Schritt 3.05)
• pageimg: (kopiert aus pageimg/ in Schritt 1.02, aufgelöst bereits in Schritt 2.02)
• unknown: (angelegt in Schritt 2.04, aufgelöst in Schritt 3.01)
• replacements: (angelegt per Hand; könnte man noch aufteilen in forbidden characters aus Schritt 2.03, escape sequences aus Schritt 2.05, special instructions aus Schritt 2.10; aber bringt das mehr Klarheit? Aufgelöst in Schritt 3.02)
• log: (per Hand angelegt, immer wenn es nötig ist. Aufgelöst in Schritt 3.05, wo es in <dcterms:description> umgewandelt wird.)

Jeden Block kann es höchstens einmal geben.

Der Sinn der Aufteilung in Anlegen der Blöcke in Schritt 1 und 2 und Auflösen der Blöcke in Schritt 3 ist, dass man möglichst lange mit dem raw text arbeiten kann. Es soll außerdem möglichst lange nachvollziehbar bleiben, welche Änderungen an der aus China erhaltenen Version gemacht wurden. Erst in Schritt 5 wird die XML-Version des Textes ein Faktum an sich, das nicht mehr jederzeit neu aus dem raw text erzeugt werden kann. Idealerweise fällt das mit dem Beginn des scholarly workflow zusammen.

Es muss möglich sein, bereits im raw text korrektes XML zu verwenden, ohne dass die Skripte darüber stolpern. Beispielsweise muss man <div type="body"> einfügen können. Ein anderes Beispiel: Während der Bearbeitung fällt auf, dass ein Abschnitt auf italienisch ist. Das muss mit <p xlm:lang="it"> markiert werden können.

2.01 Metadaten

Das Skript Filter_2_01_additional_metadata​ bearbeitet die in Schritt 1.02 aus index.meta in den metadata-Block kopierten Metadaten.

Ich verwende für die Metadaten eine Kurzschreibweise. Vielleicht ersetze ich die aber auch wieder durch korrektes XML, sodass die Metadaten in Schritt 3.05 nur noch an die richtige Stelle kopiert werden müssen. Das XML aus index.meta muss allerdings auf alle Fälle an das Schema angepasst werden.

Bei Personen wird, falls bekannt, die GND eingefügt. Beispiel:

metadata:
dcterms:creator (GND:118859676) Benedetti, Giovanni Battista de

Unbekannte Personen werden in die GND-Datei eingetragen. Diese Datei kann mehrere Einträge für dieselbe PErson haben, nämlich einen Eintrag für jede bei uns vorkommende Schreibweise. Eventuell wird auch ein link eingefügt, mit dem man die GND prüfen kann, zum Beispiel ​http://d-nb.info/gnd/118859676 für Benedetti. (Irgendwann könnte das durch ein interaktives tool passieren.)

Außerdem fügt das Skript links zu ECHO ein, beispielsweise

http://echo.mpiwg-berlin.mpg.de/ECHOdocuView/ECHOzogiLib?mode=imagepath&url=/mpiwg/online/permanent/library/163127KK/pageimg
http://mpdl-proto.mpiwg-berlin.mpg.de/mpdl/page-query-result.xql?document=/echo/la/Benedetti_1585.xml
http://echotest.mpiwg-berlin.mpg.de/content/historymechanics/Echo/163127KK

Der erste link ist für die weitere Bearbeitung besonders wichtig, denn die beiden anderen links funktionieren erst, wenn der Text nach der Bearbeitung als XML-Text hochgeladen wird.

Am Ende müssen die Metadaten per Hand geprüft werden.

2.02 pb's synchronisieren

Das Skript Filter_2_02_sync_pb​ schreibt die JPG-Dateinamen im pageimg-Block hinter die <pb> im Text. Die Zuordnung muss dann per Hand geprüft werden. Falls die Zuordnung nicht stimmt, müssen die Dateinamen korrigiert und das Skript wiederholt werden.

Das Skript macht also Änderungen im ganzen Dokument, zum Beispiel:

<pb 25>[0037]

Da die Zurdnung des Textes auf die Seiten Voraussetzung für das Arbeiten mit dem Text ist, wird der pageimg-Block im Gegensatz zu den anderen Blöcken bereits hier aufgelöst.

Entferne außerdem Dateinamen wie zzzz.jpg

2.03 ersetze verbotene Zeichen im Text

Das Skript Filter_2_03_find_forbidden_characters​ erstellt eine Liste verbotener Zeichen und Uncode-Blöcke im Text, bei einzelnen Zeichen mit Korrekturvorschlag. Beispiele:

• ɩ („latin small letter iota“) aus dem Unicode-Block „IPA Extension“ anstelle von „dotless i“. Der ganze Block „IPA Extension“ ist verboten, aber bei den anderen Zeichen gibt es keinen automatischen Korrketurvorschlag.
• ÿ statt ij in kursivem Text (Beispiel für ein sprachabhängiges Zeichen: Zum Beispiel im Französischen kann ÿ ​vorkommen.)
• „substitute“ (U+001A)
• zwei spaces hintereinander
• Zeichen, die in den Skripten intern verwendet werden: ¤, ¥. (Diese Währungszeichen als reservierte Zeichen wurden ausgewählt, weil sie in alten Texten wahrscheinlich nicht vorkommen, aber in vielen modernen Fonts verfügbar sind.)

Soweit wie möglich sollten die Korrekturen im replacements-Block am Anfang des Textes stehen. Einzelfälle können aber auch direkt im Text korrigiert werden. Beispiel: Ein einzelnes Hinɔ wird zu Hinc.

Eventuell wird das Skript noch von einer Blacklist von Unicode-Blöcken auf eine Whitelist umgestellt.

Der replacements:-Block wird in Schritt 3.02 aufgelöst.

2.04 prüfe unknown characters

Das Skript Filter_2_04_check_unknown_characters​ sammelt die im Text verwendeten Codes der Form <001> und schlägt jeweils passende Ersetzungen vor. Diese Vorschläge müssen per Hand geprüft werden. Beispiel:

unknown:
<002> ꝑ

wird zu

unknown:
<002> ꝑ (p.28: ok)

Eventuell sollte das Skript die codes auch schon in die Datei schreiben, damit man sie nicht rüberkopieren muss. Allerdings würde das Skript dann sowohl Textänderungen machen als auch eine Liste von Problemen anzeigen.

2.05 prüfe escape sequences

Das Skript Filter_2_05_check_escape_sequences​ ruft intern erst Filter_3_01_replace_unknown_characters​ auf und prüft dann, ob danach noch folgende Zeichen im Text sind: { und \

Man muss dann bei jeder Fundstelle entscheiden, ob diese geschweiften Klammern etc. legitimerweise noch im Text sind oder ob das Skript in Schritt 3.01 nicht korrekt arbeitet. Beispiel: Im Text wird die idiosynkratische Notation {ta} für eine Ligatur in kursiver Schrift verwendet.

replacements: 
{ta} ta (vorläufig!)

Einzelne Stellen können auch im Text selbst korrigiert werden.

2.06 prüfe italics

Das Skript Filter_2_06_check_underscores​ prüft, ob es Schwierigkeiten bei der Umwandlung der Kurzschreibweise _ _ für italics geben wird. Die Probleme werden dann von Hand korrigiert. In Schritt 3.04 werden die _ _ dann in <it> verwandelt. Die Umwandlung erfolgt also, bevor die <s> in den Text eingefügt werden. Die Umwandlung von <it> in die endgültige Form <emph style="it"> findet dagegen erst nach dem Einfügen der <s> statt.

Die Korrekturen in diesem Schritt werden wohl immer im Text selbst und nicht in den Blöcken vor dem Text gemacht.

2.07 prüfe tags

Das Skript Filter_2_07_check_tags​ prüft ein paar Fälle, die nicht vorkommen sollten und auf Fehler bei der Transkription hindeuten. Der Sinn dieser Prüfung ist auch, dass sich die weiteren Skripte auf die Einhaltung dieser formalen Dinge verlassen können.

• <h>, <mgl>, <mgr>, <fig> jeweils nicht in allein in einer Zeile, bei <pb> nur noch <rh> erlaubt
• nicht-existente Elemente, wie z.B. in <scG</sc>, oder auch <sup>9</sup> statt <^>9</^> (aber siehe unten)
• verschachtelte <p> (vermutlich ein <p> zuviel), und entsprechend für <h> etc.
• </p> ohne vorhergehendes <p>, und entsprechend für <h> etc.
• zusammengehörende Tags wie <p> und </p> liegen sehr weit auseinander
• zusammengehörende Tags wie <rh> und </rh> sind nicht in der gleichen Zeile

Die letzten Punkte sind noch nicht vollständig umgesetzt, aber das Skript funktioniert in der Praxis schon sehr gut.

Wie bei Schritt 2.03 muss man jeweils entscheiden, ob eine Korrektur im Text selbst gemacht wird oder in den replacements-Block geschrieben wird. Beispiel:

replacements:
<< « (lines 41 to 43)

Bei den Dingen, die in diesem Schritt geprüft werden, kann man unterscheiden in echte Fehler, die das Skript nicht korrigieren kann, und falsche Formatierungen, die das Skript selbst korrigieren könnte. Beispielsweise könnte das Skript selbst ein return einfügen, wenn <tb> nicht auf einer eigenen Zeile steht. Aber zum Beispiel gibt es in den DESpecs die Regel, dass eine heading <h> auf eigener Zeile stehen muss, ein running head <rh> dagegen auf der gleichen Zeile wie das zugehörige <pb>. Wenn dies nicht beachtet wurde, ist meistens nicht klar gewesen, ob eine Textzeile eine Überschrift oder ein running head ist. Aufgrund von solchen Fällen verändert das Skript den Text nicht selbst. (Es könnte allerdings regexes vorschlagen, die der User verwenden kann.)

Das Skript ignoriert alles vor dem ersten <pb>.

Für dieses Skript gibt es einen testparcours​.

2.08 prüfe <s>

Das Skript Filter_2_08_check_s​ soll prüfen, ob beim Einfügen von <s> etwas schiefgehen wird. Wie das genau funktionieren soll, ist noch nicht klar. Kann man hier das s-Skript aufrufen, oder kommt man dann durcheinander, weil so viele Skripte dazwischen den Text verändern? Eventuell kann man hier diese Skript gleich mit aufrufen.

2.09 prüfe tables

Das Skript Filter_2_09_check_tables​ prüft die "syntaktische Korrektheit" und die Plausibilität der tables. Was das genau bedeutet, ist noch nicht ganz klar. (Es wird jedenfalls nicht geprüft, ob die Tabelle das Original korrekt wiedergibt.) Es ist auch noch nicht ganz klar, wie eventuelle Korrekturen in den raw text geschrieben werden, d.h. ob sie in der Syntax der DESpecs hineingeschrieben werden oder schon als xhtml. Wenn als xhtml, muss es von den folgenden Skripten ignoriert werden. In beiden Formen muss es in Schritt 4.02 aus dem Absatz herausgezogen werden.

2.10 Special Instructions

Für einzelne Texte oder Work Orders kann es Skripte der Form Filter_2_10_special_instructions_for_xxxxxxxx geben. Bei manchen Texten mit Special Instructions wird es einfacher sein, die nötigen Anpassungen statt mit einem Skript per Hand zu machen. Beispiel Barrow 1674:

replacements:
--] &lt; (i.e. "--]" becomes "<"; see p.0018 and "DESpecs_special_batch3.pdf"
[-- &gt;

(Schöner wäre es, wenn die entsprechende Zeichen durch Unicode-Mathematik-Zeichen angenähert werden könnten und die modernen Zeichen erst in der MathML-Formel verwendet werden. Leider gibt es diese Zeichen so nicht in Unicode. Der Umgang mit veralteter mathematischer Notation ist noch nicht vollständig geklärt.)

Aber zum Beispiel die Special Instructions für die Tabellen am Ende von Berzelius 1819 könnten mit einem Skript weiterverarbeitet werden.

3. Schritte bis zu wohlgeformtem xml

Diese Skripte in diesem Arbeitsschritt sollten problemlos durchlaufen und können daher in einem Meta-Skript Filter_3_make_wellformed​ zusammengefasst werden. Das Skript Filter_3_test_wellformedness​ prüft anschließend, ob das Ergebnis wohlgeformt ist. Wenn der Text wohlgeformtes XML ist, sollte man ihn mit Dateiendung in xml (im Verzeichnis xml/ statt raw/) abspeichern.

3.01 ersetze unknown characters

Das Skript Filter_3_01_replace_unknown_characters​ ersetzt die Zeichen aus dem unknown-Block.

Das Skript zur Ersetzung der escape sequences (Schritt 3.03) kann sich darauf verlassen, dass die unknown characters bereits geändert wurden. Das ist wichtig für Fälle wie \'<001>.

3.02 ersetze replacements

Das Skript Filter_3_02_replace_replacements​ (unglücklicher Name?) ersetzt die Zeichen aus dem replacements-Block, beispielsweise das

replacements:
<< « (lines 41 to 43)

aus Schritt 2.07. Auch hier kann sich das Skript für die escape sequences drauf verlassen, dass diese Ersetzungen bereits durchgeführt wurden.

Dieser Schritt könnte mit Schritt 3.01 fusioniert werden. Ich sehe allerdings keine unmittelbare Notwendigkeit dafür.

3.03 ersetze escape sequences

Das Skript Filter_3_03_replace_escape_sequences​, das in Schritt 2.05 vorbereitet wurde, löst alle escape sequences auf, sowie einige weitere Schreibweisen aus den DESpecs:

• Sequenzen mit \ wie \'q etc.
• $ wird zu ſ (​long s)
• löse { } auf: {ij} auf zu ij, {ae} zu ę

Anschließend wird der Text in Unicode-Normalform ​NRC gebracht.

Das Skript soll nicht mitdenken, sondern einfach das, was die Chinesen getippt haben, so gut wie möglich mit Unicode-Mitteln ausdrücken:

• \- wird hier zu einem combining macron, weil es so im transkribierten Text steht. Später wird das in den meisten Fällen zu einer Tilde korrigiert, weil das Makron normalerweise eine falsche Transkription einer Tilde ist.
• Genauso ist \,e in den meisten Fällen in Wirklichkeit ę, wird aber hier zu ȩ.
• Zeichen, die wir absichtlich nicht in die Specs aufgenommen haben, zum Beispiel <^>9</^> für ꝰ (modifier letter us, U+A770), werden hier ebenfalls noch nicht umgewandelt. (Wenn aber zum Beispiel in der Transkription subscript und superscript verwechselt wurden und das in Schritt 2 auffällt, kann man dort <_>9</_> ꝰ in den replacements-Block schreiben.)
• {ij} wird zwar hier zu ij, aber in einem späteren Schritt wird ij stillschweigend wieder zu ij (ohne { }).

Beachte außerdem:

• \' (U+0027) kann im Text auch als \’ (U+2019) geschrieben sein (Problem des LaTeX-package shortvrb, das die einfachen ASCII-Zeichen in ihre fancy Versionen geändert hat)

3.04 ersetze italics

Filter_3_04_replace_underscores​

Ersetze _ _ für style="it". Diese Ersetzung ist nicht Teil des emph-Skriptes, weil sie vor <s> passieren sollte und in Schritt 1 bereits vorbereitet wurde.

3.05 Metadaten, root element

Das Skript Filter_3_05_add_basic_xml​ ergänzt <?xml version="1.0" encoding="UTF-8"?>, und fügt das root element <echo> sowie <metadata> und <text type="free"> ein.

auch: log wird zu <dcterms:description>

3.06 wohlgeformtes xml

Filter_3_06_make_tags_wellformed​

• reservierte Zeichen in XML: & wird zu &. Das Skript kann mehrere Male aufgerufen werden, es wird also aus & nicht &.
• Attribute: <... it> wird zu <... style="it">, genauso für fr
• ändere die Element-Namen der DESpecs in ihre Gegenstücke im ECHO Schema. Konzeptionell gibt es mehrere Teile: 1. ergänze „/“ in den ungeschlossenen Elementen wie <pb> und <hd>, 2. korrigiere verbotene Element-Namen wie <^>, 3. benenne die Elemente so, wie sie im Schema heißen.

4. schema-konform machen

wieder: Diese Skripte sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: Filter_4_make_valid​

Außerdem: Filter_4_test_validity​

*

Filter_4_00_Schummelskript​ (solange die Tabellen noch nicht richtig verarbeitet werden)

4.01 <pb>

Filter_4_01_pb​

verwandle <rh> in ein Attribut rhead in <pb>, ignoriere dabei alle Formatierungen wie kursiv, gesperrt, etc.

4.02 floats herausziehen

Filter_4_02_move_floats​

(auch tables!)

auch aus <h>, oder lieber Fehler provozieren?

Floats aus Absätzen herausziehen (vor "<s> bestimmen" !):<anchor>, <div type="float"> nach dem Absatz.

Vorsicht bei anchored marginal notes. Prüfe bei anchors im Text, ob es eine zugehörige note gibt. Akzeptiere kleine Abweichungen der Symbole voneinander, zum Beispiel 3) im Text und 3 in der Fußnote

4.03 <lb>

Das Skript Filter_4_03_insert_lb​ verwandelt Zeilenumbrüche in <lb/>.

4.04 <s>

Das Skript Filter_4_04_insert_s​ fügt <s> ein. Beachte Fälle wie:

• et.a.b.hoc est
• .a.b:c.d:e.f.
• .<lb/>a.b.
• Wort-Abkürzungen (hier wäre es einerseits hilfreich, wenn Wortabkürzungen bereits in <reg> wären; andererseits wird der Punkt am Ende von <reg> zum Beispiel in ex .7. quinti <reg>Eucl.</reg> oft noch als Satzendepunkt gebraucht)
• &c. etc.

(eventuell mit Parameter-Wahl; eventuelle manuelle Korrekturen im raw text!)

4.05 <emph>

Filter_4_05_emph​

Ersetze Fomatierungs-Elemente durch <emph style="...">. Denke an <sub> und <super>. Verschiebe style-Informationen so wie wie möglich nach oben im xml, zum Beispiel
<p><emph style="it">text</emph>.</p> wird zu
<p style="it">text.</p>. Anderes Beispiel:
<mgl>_eine kur-_<lb/>_ze Notiz._</mgl>

mit testparcours​

4.06 tables

Filter_4_06_tables​

wann werden die tables bearbeitet? zwei Schritte: überhaupt syntaktisch korrekt, und dann größtmögliche Annäherung an das Original (erst im scholarly workflow).

beachte DESpecs 1.1.2 versus 2.0

4.07 <div>

Filter_4_07_insert_div​

<div>-Struktur für das Inhaltsverzeichnis erstellen: Erstmal <div> von einer <head>-Gruppe bis zum nächsten. Automatisch erstellte <div> sind alle auf demselben level. n und level werden mit n="0" und level="0" gefüllt. Korrigiere anschließend (automatisch?) bei den <head>, die eigentlich Footer sind.

(Dieser Schritt ist nicht wirklich nötig für einen schemakonformen, aber man bekommt es quasi geschenkt.)

4.08 Formatieren

Wenn der Text schemakonform ist, kann man ihn neu formatieren. Es müssen keine Zeilen umgebrochen werden, sondern nur die Anzahl der Leerzeichen am Anfang normalisiert werden.

5. weitere Schritte

Hier gibt es einen Einschnitt im workflow: Der schemakonforme xml-Text wird bearbeitet. Es ist dann nicht mehr möglich, einfach zum raw text zurückzukehren und alle Bearbeitungsschritte noch einmal zu machen.

Die Nummern dieser Skripte können sich noch ändern. Legt die Hierarchie der inline-Elemente (z.B. <var> in plaintext, <ref> im inline model) eine Verarbeitungsreihenfolge nahe?

5.01 <reg>

Filter_5_01_insert_reg​ (mit Parametern)

Problem der Wort-Abkürzungen mit Kasus. Verwende dort <ref>, falls möglich.

Test: Kein Zeichen, das normalisiert werden soll, darf hinterher noch im Text (außerhalb von <reg>) sein, zum Beispiel kein Zeichen mit Tilde (mit Ausnahmen in manchen Sprachen). Für Latein/Benedetti:

• Zeichen mit Tilde (ã ẽ ĩ õ ũ ñ)
• combining tilde (insbesondere p̃ t̃ q̃ r̃)
• combining acute (insbesondere q́)
• medievalist characters: ꝑ ꝓ ꝗ ꝗ̃ ꝙ ꝰ  ́ ꝯ
• weitere: ę ĺ
• Apostroph: insbesondere wird ꝰ manchmal für ' gehalten (in den Abschnitten in Benedetti mit xml:lang="it" bzw. xml:lang="ita" ist ' dagegen erlaubt)

mit testparcours​

5.02 <var>

Filter_5_02_insert_var​ (mit Parametern)

Ziel: verberge den Inhalt vor der morphologischen Analyse

Entferne <emph> in Variablen.

mit testparcours​

5.03 <num>

Filter_5_03_insert_num​

Ziel wieder: verberge den Inhalt vor der morphologischen Analyse

Filter_roman_numbers (nicht im repository): <num value="..."> für römische Zahlen, wird eventuell Teil des num-Skriptes.

5.04 Formeln

Filter_5_04_formulae​

?

5.05 <foreign>

Filter_5_05_insert_foreign

Füge <foreign> zumindest für griechischen Text (erkennbar an den verwendeten Zeichen) ein, und xml:lang.

5.06 div-Attribute

Filter_5_06_number_divs​

Es muss möglich sein, bereits im raw text korrektes XML zu verwenden, ohne dass die Skripte darüber stolpern. Beispielsweise muss man <div type="body"> einfügen können (beachte: dann sollte auch der type in <text> geändert werden). Braucht man dazu ein tool, oder geht das so? Was ist die Verbindung zum <div>-Skript? Braucht man ein tool zur manuellen Nachbearbeitung der automatisch erstellten <div>?

Abgleich mit Donatus

• Einfügen fehlender Bindestriche
• Korrektur von fehlenden/überflüssigen Spaces
• korrigiere Standardfehler wie fumptis, fint, bumanitate in kursiv

allgemeines Test-Skript

Allgemeines Test-Skript? z.B. gibt es nach Anwenden des Skript zwei Spaces hintereinander? Das muss kein Fehler des Skriptes sein, aber es deutet auf ein Problem hin.

Gesamt-Test: Keine Punkte mehr im Text, die nicht

• Satzende-Punkte sind (<s>Bla bla bla. </s>)
• in einem Tag verschwinden (<ref>ex .7. quinti Eucl.</ref>)
• zu einer Zahl gehören (.11.)

scholarly workflow

• ersetze <wrong/> durch <sic/> oder entferne es; löse <unsure/> auf
• weitere <reg>, Korrekturen von bestehenden <reg>
• <ref>
• weitere <foreign>
• entferne library stamps
• „old-style numerals typed as letters“, zum Beispiel ex .II. statt ex .11., aber auch andersherum: 10. BENEDETTI statt IO. BENEDETTI
• Wörter mit einzelne griechischen oder einzelnen lateinischen Buchstaben (automatisierbar?)
• Wörter mit einzelnen Großbuchstaben mitten im Wort (ClaZomenius). Häufig ist die Ursache ein fehlendes Space vor dem Großbuchstaben.

Reste

Filter_template​

Figures nachbearbeiten; beachte DESpecs 1.1.2 versus 2.0

IDs einfügen (es könnte ein Modul geben, in dem das id-Attribut gefordet wird, und das mit der Zwiebelstruktur in diesem Stadium in Aktion tritt. Dann müssen wir nicht in den usage guide schreiben: Es ist zwar formal optional, aber es sollte verwendet werden.)

GIS: <person>, <place>, <time>, <event>

Filter_punctuation (nicht im repository): Das Skript zur Normalisierung der Interpunktion habe ich vorläufig weggelassen, weil es vermutlich merkwürdige Nebenwirkungen hat. Zum Beispiel spaces vor „:“ weg. (Hier ist die Frage, ob wir Information verlieren, die wir gerne konservieren würden. Beispiel „EPISTOL AE“). Ziel ist wieder, dass sich die folgenden Skripte auf ein einheitliches Format verlassen können. Beispielsweise müsste das reg-Skript, das unter anderem q; durch que ersetzt, nicht noch prüfen, ob es q ; gibt.

Filter_Archimedes_to_ECHO (nicht im repository): Dieses Skript habe ich für die Umwandlung von Song Yingxing verwendet. Für europäische Texte müsste es überarbeitet werden.

Filter_4_04a_test_s ??

Besonderheiten bei chinesischen Texten

Version 2.0.1 der chinesischen DESpecs ist ​hier.

• beachte die in echo-chinese-text definierten Attribute
• lateinische Zeichen können durch ihre full-width-Version ersetzt sein, zum Beispiel „?“ durch „？“
• verarbeite character variants automatisiert
• verarbeite character variants im scholarly workflow so gut wie möglich. Beispielsweise würde \国 durch die Unicode-Zeichenfolge ⿴口玉 angenähert werden.
• Wort- und Satzgrenzen markieren (bzw. andersrum: invisible spaces innerhalb von Wörtern entfernen)

Wie der automatisierte Workflow für chinesische Texte aussehen wird, ist noch nicht völlig klar. Wenn zum Beispiel im Text <獘V> getippt wurde, kann man das automatisiert nur zu <reg norm="獘" type="V">獘</reg> mit vorläufigem Typ "V" machen, wo also das getippte Zeichen einfach wiederholt wird. Die Variante im Text kann dann nur eine studentische Hilfskraft anhand der von ZhongYi erstellten Excel-Tabellen "herstellen". Ziel ist eine Zeichenfolge, die das Zeichen im Text beschreibt. Hier: ⿱敝大. Und dann:

<reg norm="獘" type="simple"><image xlink:href="symbols/chinese/⿱敝大.svg"/></reg>

Wenn das Zeichen V₁ im Original eine Variante des Standardzeichens S ist, es aber in Unicode eine weitere Zeichenvariante V₂ von S gibt, die optisch näher an V₁ dran ist als S an V₁, so sollen die Chinesen die Variante V₂ mit < V> tippen. Ein Beispiel ist <兾V> statt <冀V> in den ​chinesischen DESpecs 2.0.1, p.10/11. Ziel ist dann:

<reg norm="兾" type="simple"><image xlink:href="symbols/chinese/⿱𠂉異.svg"/></reg>

Das Herunterkochen von 兾 (V₂) zu 冀 (S) sollte dann "von alleine" passieren. Allgemein: Was ist das Ziel, wenn die Chinesen eine Zeichenvariante (ohne < V>) getippt haben, die es in Unicode gibt? Soll die dann auch ein <reg> bekommen? Wer erkennt überhaupt, dass es sich um eine Variante handelt? Zumindest in der Theorie muss man das nicht regularisieren, und die Suche funktioniert von alleine richtig.

Sollen wir umsteigen auf ein System, wo die Chinesen <001> tippen, und dann im Anhang eine IDS-Sequenz?