Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pdaengeli/cd12fe4b2dcabc112c10d018836ef282 to your computer and use it in GitHub Desktop.
Save pdaengeli/cd12fe4b2dcabc112c10d018836ef282 to your computer and use it in GitHub Desktop.
initial version: Tue, Apr 21, 2020 9:36 AM
changes: Tue, Apr 21, 2020 9:50 AM
changes: Sat, May 16, 2020 11:25 PM
initially publised at: https://md.hallernet.org/s/S1WTRV2_L
exported from CodiMD (phase-out imminent): Mon, Apr 8, 2024

Methodenexkurs: ad-hoc-Schematron (explorativ) auf viele Verzeichnisse anwenden

Schematron ist eine regelbasierte Validierungssprache (und zugleich auch ein ISO-Standard). Anders als vergleichbare Sprachen ist Schematron nicht Grammatik-basiert, sondern darauf ausgelegt, Baumstrukturen in Dokumenten auszuwerten. Auf dieser Grundlage kann man nun die Perspektive ein wenig drehen und Schematron nicht als Validierungstool, sondern auch zur Datenexploration nutzen.

Leitfrage: wie viele und welche Dateien sind von einem bestimmten Problem betroffen?

Schematron bietet uns zwei Mechanismen, strukturelle Prüfungen vorzunehmen: wir können sicherstellen, dass ein bestimmter erwünschter Sachverhalt vorliegt – sch:assert – oder wir können eine Warnung erzeugen, wenn ein unerwünschter Sachverhalt vorliegt – sch:report. Unter dem Strich sind beide Ansätze gleichwertig und über eine Negation des Tests lässt sich immer auch der jeweils andere Ansatz nutzen.

Im vorliegenden Fall könnte das heißen: melde alle Dateien, in denen das erste vorkommende sn_16.041.000 nicht auf sn_16.032.000 folgt und das letzte vorkommende sn_16.041.000 nicht von sn_16.033.000 gefolgt wird.

Anwendung der Methode

Eine Schwäche unseres Setups...

In der täglichen Arbeit werden die XML-Dateien über WebDAV ab dem Server geladen. Das funktioniert gut, hat aber auch seine Grenzen, vor allem hinsichtlich Performanz. oXygen XML Editor unterdrückt aus gutem Grund die Anwendung der Validierung/Auswertung ganzer Verzeichnisse oder Verzeichnisbäume über WebDAV und beschränkt den Einsatz auf Einzeldateien.

...die sich durch eine Stärke unseres Setups gut überbrücken lässt

Dadurch, dass unsere Daten in einem versionskontrollierten Repository liegen, haben wir jederzeit guten Zugriff darauf und können leicht Dinge testen, ohne ein Risiko einzugehen. Im vorliegenden Fall können wir eine lokale Kopie aller Personendaten erstellen (mit git clone oder durch Herunterladen einer ZIP-Datei) und diese in oXygen gegen eine Schematron-Datei prüfen.

Schritt-für-Schritt-Anleitung

oXygen-Projekt anlegen und vorbereiten

Die Nutzung von oXygen-Projekten ermöglicht es, Einstellungen und Optionen für ein bestimmtes Projekt zu persistieren. Dieser Schritt ist optional, aber er kann hilfreich sein, um komplexe Workflows (wie wir sie im Projekt haben) zu verwalten.

Ein neues Projekt lässt sich in der Projektansicht anlegen. Es kann mit Dateiendung .xpr in ein beliebiges Verzeichnis gespeichert werden.

Was uns hier besonders interessiert, ist der Zugriff auf das Dateisystem. Über das Kontextmenü lässt sich ein neues Verzeichnis dem Projekt zuweisen (diese Verknüpfung ist ganz lose und kann jederzeit aufgehoben werden).

Hier kann nun eine lokale Kopie der aktuellen XML-Daten eingebunden werden (sie lässt sich hier als ZIP-Datei herunterladen oder von https://gitlab.cceh.uni-koeln.de/haller-online/brn/data.hallernet.git klonen).

Schematron-Datei erstellen

Nun folgt das Kernstück der Operation, die Schematron-Datei. Sie lässt sich als XML-Datei in oXygen anlegen (und im neuen Projektverzeichnis abspeichern) und ist sehr einfach aufgebaut:

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2"
    xmlns:sqf="http://www.schematron-quickfix.com/validator/process">
    
    <ns prefix="tei" uri="http://www.tei-c.org/ns/1.0"/>
    
    <pattern id="ad-hoc_position-of-sn_16.113.000">
        
        <rule context="tei:note[@n='sn_16.113.000'][1]">
            
            <assert test="preceding-sibling::*[1][@n='sn_16.032.000']">Caution: tei:note[@n='sn_16.113.000'] does not follow tei:occupation[@n='sn_16.032.000']</assert>
            
        </rule>
        
        <rule context="tei:note[@n='sn_16.113.000'][last()]">
            
            <assert test="following-sibling::*[1][@n='sn_16.041.000']">Caution: tei:note[@n='sn_16.113.000'] is not followed by tei:note[@n='sn_16.041.000']</assert>
            
        </rule>
        
    </pattern>
    
</schema>

Dieser Code formalisiert die oben beschriebene Leitfrage in einer Schematron-Datei. Für zwei Kontexte, das erste und letzte Positions-Element, wird jeweils das erste vorangehende bzw. erste folgende Element geprüft. Wenn die assertion fehlschlägt, wird die entsprechende Meldung ausgegeben.

Ready to rumble

Damit sind alle Vorbereitungen getroffen. Nun kann die Schematron-Datei auf eine Datei, mehrere Dateien, ein Verzeichnis oder mehrere Verzeichnisse angewendet werden. Empfehlenswert ist natürlich zunächst mal ein kleinräumiger Test.

Dazu können z.B. die ersten 10 Dateien markiert werden und über das Kontextmenü die Schema-Validierung initiiert werden.

Im Dialogfenster ist die Schematron-Datei auszuwählen, Schematron als Schematyp sollte automatisch erkannt werden:

Mit OK läuft die Validierung an. Sie wird entweder mit einer Erfolgsmeldung abgeschlossen:

oder als Resultatliste präsentiert:

(Dieser Screenshot bildet übrigens Verzeichnis persons/013 ab und damit u.a. die Fehler, auf die @remo gestossen ist.)

Eine tolle Eigenschaft dieser Resultatliste ist, dass sich die einzelnen Einträge per Doppelklick stellengenau öffnen lassen (Grundlage dafür ist der context der ausschlaggebenden Regel).

So lassen sich Probleme ziemlich direkt korrigieren.

Nota bene: Wir befinden uns in einer lokalen Kopie der Daten. Wenn man direkte Korrekturen vornehmen will, sollte man das Repository klonen (und nicht als ZIP-Datei herunterladen) und dann möglichst umgehend einen Commit erstellen und zum Remote pushen und dieses wiederum auf den Server pullen (dazu ist ein entsprechender Serverzugang notwendig; in der näheren Zukunft kann ich jeweils aushelfen). Je länger dies dauert, desto höher das Risiko für gleichzeitige Bearbeitungen auf dem Server und dadurch konfligierende Versionen.

Potenzial

Mit einer umfangreicheren Schematron-Datei lassen sich auf diese Weise die unterschiedlichsten Anomalien aufspüren.

Über Regex- und Stringfunktionen lassen sich mit solchen Tests auch Textnodes analysieren und bestimmte Dinge ausgeben (z.B. FML-Ausdrücke, die für fix me later oft in die Dateien geschrieben werden).

Validierungsresultate lassen sich auch abspeichern. Die resultierende Datei kann z.B. in einem neuen Issue mitgegeben werden, um den Umfang eines Problems zu dokumentieren. Sie lässt sich aber auch leicht in eine eigene Liste transformieren, mit der jemand dann beispielsweise den Korrekturvorgang angehen kann oder die entsprechenden Fälle per Doppelklick im Frontend öffnen kann.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment