Changes between Version 10 and Version 11 of workflow

Timestamp:

May 23, 2010, 10:43:31 AM (14 years ago)

Author:

Wolfgang Schmidle

Comment:

--

workflow

@@ -7 +7 @@
 und
 [http://echotest.mpiwg-berlin.mpg.de/content/historymechanics/Echo echotest].
-Der automatische XML-Workflow besteht aus einer Reihe von [source:trunk/schema/scripts/workflow Skripten]. Einige dieser Skripte sind noch reine Platzhalter, aber die Struktur stimmt bereits.
+Der automatische XML-Workflow besteht aus einer Reihe von [source:trunk/schema/scripts/workflow Skripten]. Einige dieser Skripte sind noch leere Platzhalter, aber die Struktur stimmt bereits.
 
 
 == Die Arbeitsschritte ==
 
-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 Skript-Ketten abrufbar sein.
+Im ersten Arbeitsschritt werden alle Vorbereitungen getroffen, um mit dem raw text zu arbeiten. Im zweiten Schritt wird der raw text korrigiert und annotiert. Im dritten Schritt wird der annotierte raw text in wohlgeformtes XML verwandelt. Im vierten Schritt wird der XML-Text schemakonform gemacht.
+
+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.
@@ -22 +28 @@
 
 ==== Von Pythia ins svn-repository ====
+
+Es ist noch nicht ganz klar, wie neue Dateien in Zukunft verarbeitet werden: Kommen sie zuerst nach Pythia oder gleich in das wiki-repository? Jedenfalls muss geprüft werden, dass es die Datei reiner Text in utf-8 ist.
 
 im [source:trunk/texts Texte-Verzeichnis] im repository:
@@ -27 +35 @@
   * Verzeichnisse anlegen (allerdings nerven die raw/xml-Verzeichnisse in der Praxis)
   * Datei aus Pythia rüberkopieren
-  * Kopie erstellen und umbenennen, mit identifier, neue line ends
+  * Kopie erstellen und umbenennen (autor_jahr_identifier), Zeilenenden von CRLF zu LF. Entferne BOM-Fragmente (korrekte BMs sind okay).
 
 Skript: Datei umbenennen? oder ist das jetzt wirklich etwas, was einfacher per Hand geht?
-
-Skript von Klaus?
+(Skript von Klaus?)
 
 
@@ -70 +77 @@
 2. Umbenennen der alten index.meta (eventuell wird eine ältere Sicherheitskopie ohne Nachfrage überschrieben), Schreiben der neuen.
 
+(Die Trennung von Vorbereitung und raw text bearbeiten kann man eventuell nicht klar aufrechterhalten, weil es wohl nur ein Skript gibt, das mit dem Server kommuniziert und dort gleichzeitig <texttool> einträgt, Metadaten abgreift, die pageimg importiert. Andererseits können das genausogut drei getrennte Skripte sein. Dann kommuniziert man halt dreimal mit dem Server. Oder einfacher: ein Skript holt sich eine lokale Kopie von index.meta und legt eine getrennte Datei der pageimg an, und die nächsten Skripte müssen dann gar nicht mehr auf dem Server anfragen.)
+
 
 === raw text bearbeiten ===
 
-Die Trennung von Vorbereitung und raw text bearbeiten kann man eventuell nicht klar aufrechterhalten, weil es wohl nur ein Skript gibt, das mit dem Server kommuniziert und dort gleichzeitig <texttool> einträgt, Metadaten abgreift, die pageimg importiert. Andererseits können das genausogut drei getrennte Skripte sein. Dann kommuniziert man halt dreimal mit dem Server. ODer einfacher: ein Skript holt sich eine lokale Kopie von index.meta und legt eine getrennte Datei der pageimg an, und die nächsten Skripte müssen dann gar nicht mehr auf dem Server anfragen.
-
-Folgende Gruppen sind erlaubt, in beliebiger Reihenfolge, jeweils durch eine Leerzeile getrennt, vor dem ersten {{{<pb>}}}:
+In diesem Arbeitsschritt wird der raw text auf die Umwandlung in XML vorbereitet. Ä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:}}}
-  * {{{pageimg:}}} (wird aber gleich wieder verarbeitet) bzw. getrennte Datei, siehe oben
+  * {{{pageimg:}}} (wird aber gleich wieder verarbeitet)
   * {{{unknown:}}}
   * {{{replacements:}}} (per Hand; könnte man noch aufteilen in forbidden, escape sequences, special instructions; aber bringt das mehr Klarheit?)
   * {{{log:}}} (per Hand)
 
-Alle in getrennte Dateien? Oder ist das dann auch wieder übertrieben?
-
-Getrennte Datei doof für Skripte, weil sie die Datei dann finden müssen? Also doch gleich in den raw text?
+(Alle in getrennte Dateien? Oder ist das dann auch wieder übertrieben? Getrennte Datei doof für Skripte, weil sie die Datei dann finden müssen? Also doch gleich in den raw text?)
+
+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. 
+
 
 ==== Metadaten ====
 
+Skript zur Korrektur der Metadaten aus index.meta:
 [source:trunk/schema/scripts/workflow/Filter_2_01_additional_metadata.pl Filter_2_01_additional_metadata]
         
 „metadata:“
-Skript zur Korrektur der Metadaten aus index.meta
 
 ergänze dann den Rest per Hand
@@ -121 +131 @@
 ==== ersetze verbotene Zeichen im Text ====
 
+Das Skript 
 [source:trunk/schema/scripts/workflow/Filter_2_03_find_forbidden_characters.pl Filter_2_03_find_forbidden_characters]
-
-⟶ im ganzen Dokument: {{{Hinɔ wird Hinc}}} (Einzelfälle)
-
-entweder direkt im Text, oder mit Zwischenstuf als replacements am Anfang
+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
+  * „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 Texte 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: {{{Hinɔ}}} wird {{{Hinc}}}
+
+Eventuell wird das Skript noch von einer Blacklist von Unicode-Blöcken auf eine Whitelist umgestellt.
 
 
@@ -139 +157 @@
 ==== prüfe escape sequences ====
 
-[source:trunk/schema/scripts/workflow/Filter_2_05_check_escape_sequences.pl Filter_2_05_check_escape_sequences]
-
-
-bei replacements: zum Beispiel {{{{ta} ta (vorläufig!)}}}
-        
+Das Skript [source:trunk/schema/scripts/workflow/Filter_2_05_check_escape_sequences.pl Filter_2_05_check_escape_sequences]
+ruft intern erst [source:trunk/schema/scripts/workflow/Filter_3_01_replace_unknown_characters.pl Filter_3_01_replace_unknown_characters]
+auf und prüft dann, wo danach noch folgende Zeichen im Text sind: { \
+
+Man muss dann jeweils entscheiden, ob diese geschweiften Klammern etc. in Ordnung sind oder nicht.
+
+Beispiel: Im Text wird die idiosynkratische Notation {ta} für eine Ligatur in kursiver Schrift verwendet. Im {{{replacements}}}-Block: {{{{ta} ta (vorläufig!)}}}
+
+
 ==== prüfe italics ====
 
@@ -150 +172 @@
 {{{_ _}}} werden erst später in <it> verwandelt, aber hier wird bereits geprüft, ob es Probleme geben wird (bzw. die Fehler werden per Hand korrigiert)
 
-        
 
 ==== prüfe tags ====
@@ -177 +198 @@
 wie wird das in den raw text geschrieben? schon mit korrektem xhtml ist vielleicht etwas viel Aufwand. noch eine Zwischensprache, oder was ist da überhaupt zu tun?
 
+
 ==== Special Instructions ====
 
-[source:trunk/schema/scripts/workflow/Filter_2_10_special_instructions_for_... .pl Filter_2_10_special_instructions_for_... ]
+[source:trunk/schema/scripts/workflow/Filter_2_10_special_instructions_for_xxxxxxxx Filter_2_10_special_instructions_for_xxxxxxxx]
 
 (bei manchen Texten wird es einfacher sein, es statt mit einem Skript per Hand zu machen)
@@ -190 +212 @@
 === Schritte bis zu wohlgeformtem xml === 
 
-Diese Skripte sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden:
-[source:trunk/schema/scripts/workflow/Filter_3_make_wellformed.pl Filter_3_make_wellformed]
-
-Außerdem: [source:trunk/schema/scripts/workflow/Filter_3_test_wellformedness.pl Filter_3_test_wellformedness]
-
-
+Diese Skripte in diesem Arbeitsschritt sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden:
+[source:trunk/schema/scripts/workflow/Filter_3_make_wellformed.pl Filter_3_make_wellformed]. Das Skript [source:trunk/schema/scripts/workflow/Filter_3_test_wellformedness.pl Filter_3_test_wellformedness]
+prüft anschließend, ob das Ergebnis wohlgeformt ist.
 
 
@@ -202 +221 @@
 [source:trunk/schema/scripts/workflow/Filter_3_01_replace_unknown_characters.pl Filter_3_01_replace_unknown_characters]
 
-
 (vor escape sequences als garantierte Reihenfolge, bevor die escape sequences umgewandelt werden)
 
@@ -216 +234 @@
 ==== ersetze escape sequences ====
 
-[source:trunk/schema/scripts/workflow/Filter_3_03_replace_escape_sequences.pl Filter_3_03_replace_escape_sequences]
+Das Skript [source:trunk/schema/scripts/workflow/Filter_3_03_replace_escape_sequences.pl Filter_3_03_replace_escape_sequences]
+löst alle escape sequences auf, sowie einige weitere Schreibweisen aus den DESpecs. 
+
+  * escape sequences: Beachte, dass {{{\'}}} (U+0027) im Text auch als {{{\’}}} (U+2019) geschrieben sein kann. 
+  * Beachte auch: {{{\-}}} 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 {{{ȩ}}}.
+  * Löse {{{$}}} auf
+  * Zeichen, die wir absichtlich nicht in die Specs aufgenommen haben, zum Beispiel {{{<^>9</^>}}} für ꝰ (modifier letter us, U+A770)
+  * löse {{{{ }}}} auf: {{{{ij}}}} auf zu {{{ij}}} (später stillschweigend zu {{{ij}}}), {{{{ae}}}} zu {{{ę}}}
+  * zum Schluss: Unicode-Normalform [http://unicode.org/reports/tr15/ NRC]
 
 
@@ -223 +249 @@
 [source:trunk/schema/scripts/workflow/Filter_3_04_replace_underscores.pl Filter_3_04_replace_underscores]
 
+
 ==== Metadaten, root element ====
 
@@ -228 +255 @@
 
 auch: log !
+
 
 ==== wohlgeformtes xml ====
@@ -246 +274 @@
 [source:trunk/schema/scripts/workflow/Filter_4_00_Schummelskript.pl Filter_4_00_Schummelskript] (solange die Tabellen noch nicht richtig verarbeitet werden)
 
+
 ==== <pb> ====
 
 [source:trunk/schema/scripts/workflow/Filter_4_01_pb.pl Filter_4_01_pb]
 
+
 ==== floats herausziehen ====
 
@@ -258 +288 @@
 auch aus <h>, oder lieber Fehler provozieren?
 
+
 ==== <lb> ====
 
 [source:trunk/schema/scripts/workflow/Filter_4_03_insert_lb.pl Filter_4_03_insert_lb]
 
+
 ==== <s> ====
 
@@ -268 +300 @@
 [source:trunk/schema/scripts/workflow/Filter_4_04a_test_s.pl Filter_4_04a_test_s] ??
 
+
 ==== <emph> ====
 
 [source:trunk/schema/scripts/workflow/Filter_4_05_emph.pl Filter_4_05_emph]
 
+
 ==== tables ====
 
@@ -277 +311 @@
 
 wann werden die tables bearbeitet? zwei Schritte: überhaupt syntaktisch korrekt, und dann größtmögliche Annäherung an das Original (erst im scholarly workflow). 
+
+
 ==== <div> ====
 
 [source:trunk/schema/scripts/workflow/Filter_4_07_insert_div.pl Filter_4_07_insert_div] (nicht wirklich nötig für Schema-konform, aber bekommt man quasi geschenkt)
 
+
 === weitere Schritte ===
 
+Legt die Hierarchie der inline-Elemente (z.B. <var> in plaintext, <ref> im inline model) eine Verarbeitungsreihenfolge nahe?
+
+
 ==== <reg> ====
 
 [source:trunk/schema/scripts/workflow/Filter_5_01_insert_reg.pl Filter_5_01_insert_reg] (mit Parametern)
 
+
 ==== <var> ====
 
 [source:trunk/schema/scripts/workflow/Filter_5_02_insert_var.pl Filter_5_02_insert_var] (mit Parametern)
 
+
 ==== Formeln ====
 
@@ -297 +339 @@
 ?
 
+
 ==== div-Attribute ====
 
@@ -312 +355 @@
 
 [source:trunk/schema/scripts/workflow/Filter_roman_numbers.pl Filter_roman_numbers]
+