Die Siemens Mobility GmbH nutzt seit 2020 Schematron in ihrem COSIMA-Redaktionssystem. Obwohl Siemens Mobility bereits zuvor logische Checks zur Qualitätsprüfung ihrer Inhalte verwendet hat, ergaben sich mit Schematron viele neue Möglichkeiten zur Automatisierung und Vereinfachung. In unserem Interview gibt Johannes Meyknecht (Application Manager für COSIMA bei Siemens Mobility) Einblick in die Einführung von Schematron und welche Vorteile die Nutzung mit sich brachte.

DOCUFY: Wie haben Sie die Themen „Datenqualität der XML-Inhalte“ und „Einhaltung des Redaktionsleitfadens“ vor der Schematron-Einführung gehandhabt?

Johannes Meyknecht: Sehr unterschiedlich. Vorgaben konnten bzw. mussten oft nur über das redaktionelle Review geprüft werden, was natürlich sehr zeitintensiv ist. Unter Zeitdruck ist es daher denkbar, dass die Prüfungen nicht auf einem konstant hohen Qualitätsniveau durchgeführt wurden – nicht jeder Tag ist gleich. Einige logische Prüfungen konnten wir über die Jahre sukzessive verbessern. Angefangen mit einfachen XPath-Abfragen, die mittels der Sicht „XML-Details“ (leider nur mit XPath 1.0 Subset) im Rich Client immer wieder manuell abgerufen werden konnten, über die ExtendedValidation, mit der schon automatisierte Abfragen beim Speichern möglich waren und XPath 2.0 verwendet werden konnte.

Welche Vorteile haben Sie jetzt im Gegensatz zum früheren Ansatz?

1. Die Prüfung wird automatisiert durchgeführt (z.B. beim Speichern).
2. Die Regeln sind zentral abgelegt. Früher musste sich jeder User die Abfragen mittels der Sicht „XML-Details“ selbst einrichten oder ein initiales User Setting mit den Abfragen importieren. Das war sehr umständlich.
3. Key User können besser steuern, wann welche Regeln für welche Abteilungen, Objekttypen, Sprachen, etc. (automatisch) angewendet werden.

Warum haben Sie sich für Schematron entschieden?

Überwiegend aus der Anforderung heraus, dass wir in unserem COSIMA-Redaktionssystem mit drei Dokumentationsabteilungen arbeiten, die stellenweise leicht unterschiedliche Regeln und Vorgaben anwenden.
Es ist uns nun mit Schematron möglich, sowohl globale Regeln zu definieren, die für alle drei Abteilungen identisch angewendet werden, als auch abteilungsspezifische Regeln zu hinterlegen, die nur im jeweiligen Department des Redakteurs angewendet werden. Weiterhin war es mit wenig Aufwand verbunden, die bereits existierenden XPath-Filter, ExtendedValidation-Rules und weitere Regeln nach Schematron zu adaptieren.

Wie arbeiten die Redakteure mit Schematron, wie läuft das ab?

Es ist ein weiterer wesentlicher Vorteil, dass die Redakteure von der eigentlichen Prüfung der Dokumentation wenig (im Optimalfall nichts!) mitbekommen. Sie bekommen Schematron nur „zu Gesicht“, wenn ein bearbeitetes Konstrukt nicht den von uns vorgegebenen Regeln entspricht. Aber dies ist dann explizit gewünscht. Die Redakteure können sich darauf verlassen, dass Regeln, die wir ihnen zuvor als eigenständig durchzuführende Prüfungen (sei es durch Review oder manuell anzuwendende XPath-Filter) festgelegt hatten, nun beim Speichern automatisch durchgeführt werden.

Wie hat sich das Arbeiten für die Redakteure konkret geändert?

Unseren Redakteuren fällt es nun leichter, Objekte für das redaktionelle Review an die Reviewer zu übergeben, da ein Großteil der Prüfungen bereits automatisiert erledigt wurde. Den redaktionellen Reviewern wiederum wird Prüfaufwand gespart, weil die Fehler, die durch Schematron-Regeln aufgedeckt werden, bereits von den Redakteuren eliminiert wurden und somit nicht mehr vorhanden sind. Somit ist eine schnellere Qualitätskontrolle möglich.

Wie war die Einführung für Sie? Was hat DOCUFY gemacht? Und was musste auf Seite von Siemens Mobility getan werden?

DOCUFY hat Schematron in COSIMA aktiviert und uns eine kurze Schulung bzw. Einweisung in Schematron gegeben.

Danach mussten unsere Redakteure nur noch die Information verarbeiten, was mittels Schematron geprüft wird, bzw. was nicht geprüft wird und ggf. weiterhin manuell zu prüfen ist. Die Key User einigten sich mit den Project Managern auf die anzulegenden Regeln. Im Anschluss haben sie die Schematron-Regeln erstellt und die bereits existierenden XPath-Filter in Schematron-Regeln übernommen.

Würden Sie Schematron wieder einführen? Wenn ja, warum?

Definitiv würden wir Schematron wieder einführen, da mit wenig Einsatz (also, nur die Definition der Regeln) auf Knopfdruck (speichern) so wahnsinnig viel geprüft werden kann.

Haben Sie eine Verbesserung an der Datenqualität seit der Einführung bemerkt?

Nicht direkt im Sinne, dass wir dies überprüft hätten. Das hängt damit zusammen, dass wir deutlich weniger manuell prüfen müssen und dass wir uns auf den Automatismus verlassen können und er schon einen Großteil korrekt prüft. Diese Fehlerquellen müssen nun nicht mehr geprüft werden, weil sie nicht mehr auftreten, bzw., falls sie noch in den Objekten vorhanden wären, für jeden Nutzer sofort sichtbar wären. Von daher ist die Datenqualität in den Fällen verbessert worden, in denen wir vorher keine automatisierte Prüfung hatten und somit einen Fehler im Review hätten übersehen können.

Haben Sie einen Rat an andere DOCUFY-Kunden, die überlegen, Schematron einzuführen?

Aus meiner Sicht gibt es keinen Grund zu zögern, denn es sind für mich überhaupt keine Nachteile erkennbar. Eine Integration von Schematron bringt nur Vorteile und ein Regelwerk ist in relativ kurzer Zeit umsetzbar.
DOCUFY wird mit Sicherheit unterstützen, falls dies nicht eigenständig erfolgen kann.

Vielen Dank für das Gespräch, Herr Meyknecht!

Beispiele für Schematron-Prüfungen, die Siemens Mobility nutzt

Hier erläutert Herr Meyknecht einige Schematron-Beispiele und deren Nutzen für die Abteilung:

Abteilungssspezifisch:
Abteilung 1 erlaubt (oder möglicherweise erzwingt) das Fehlen einer Tabellenunterschrift (TableCaption), wenn die Tabelle Teil einer Handlungsanweisung ist. Abteilung 2 & 3 können dies kontextabhängig anders regeln und explizit für jede Tabelle eine TableCaption erzwingen.

Content:
Innerhalb eines Informationsabschnittes soll die Reihenfolge, bzw. Abstufung der Warnhinweise immer Danger > Warning > Caution > Notice > Environment sein. Die Schematron-Regel prüft ausgehend von jedem Warnhinweis, ob es vorhergehende Geschwisterknoten gibt, deren Warnhinweisstufe geringfügiger sind und erzeugt dann eine Fehlermeldung. (Bsp: Reihenfolge der Warnhinweise: Caution, Warning -> Fehler: muss Warning, Caution sein.)

Besonders hilfreich sind die Schematron-Regeln, mit denen wir prüfen, ob bestimmte Werte in einer Aufzählung/Liste mehrfach existieren. Dies haben wir an mehreren Stellen im Einsatz, z.B. im VIMDocument. Das VIM (Verzeichnis der Instandhaltungsmaßnahmen) generiert sich aus den Maßnahmen der im VIMDocument referenzierten Documents. Das sind in unseren Anwendungsfällen gern mal mehr als 100 Dokumente, so dass man schnell den Überblick verliert.
Hier ist es besonders hilfreich, wenn die Schematron-Regel einen darüber informiert, dass ein oder mehrere Dokumente ggf. mehrfach referenziert sind.

Qualität:
Unsere Bestellnummern besitzen das Schema: Beginnt mit „A2V“ gefolgt von elf Ziffern.
Da sich in Schematron/XPath 2.0 auch reguläre Ausdrücke nutzen lassen, erfolgt für das Element der Siemens-Bestellnummer eine Prüfung, ob sie dem Schema ^A2V[0-9]{11}$ entspricht. Dies verhindert fehlerhafte Eingaben.
Angewendet wird dies für die Bestellnummer für Werkzeug, Material und Ersatzteil-Fragmente. Im Ausgabeformat werden für die Bestellnummern automatisch Links in den Ersatzteilkatalog erstellt, so dass es wichtig ist, dass die Bestellnummern korrekt bedatet wurden.

Logik:
Für die Fragmente, die „Gruppen“ repräsentieren, bei uns z.B. PartGroup, SubstanceGroup, OperationMaterialGroup und ToolGroup findet eine Prüfung statt, wie viele „Kinder“ die Gruppe besitzt. Erst ab Anzahl 2 ist das Kriterium „Gruppe“ erfüllt und das Group-Element lässt sich speichern und einchecken. Diese Logik ließe sich bspw. auch für Listen implementieren, die anschlägt, wenn eine Liste nur ein Item besitzt.