SGML-Dokumente nach XML migrieren: Ein Praxisleitfaden

SGML ist alt. Ihre Inhalte müssen es nicht sein.

Organisationen begegnen weiterhin SGML-Beständen, deren Bearbeitungs- und Publikationsumgebungen schwer wartbar geworden sind. Die Inhalte selbst können jedoch nach wie vor stark strukturiert und wertvoll sein.

XML wurde als vereinfachte Teilmenge von SGML entworfen. Diese Beziehung eröffnet einen praktischen Migrationspfad, sofern die Quelle als SGML geparst und nicht wie fehlerhaftes XML behandelt wird.

Dieser Artikel beschreibt einen kontrollierten Workflow mit den ursprünglichen DTDs, Katalogen und Entitäten sowie James Clarks SGML-Werkzeugen, wie sie in OpenSP weitergeführt wurden.

Migration im Überblick

Workflow von Legacy-SGML über Parsing, Validierung und Konvertierung zu XML und moderner XML-Verarbeitung — Abbildung 1: Ein praktischer SGML-zu-XML-Migrationsworkflow. Die originalgetreue strukturelle Konvertierung steht vor optionaler Grammatikmodernisierung und semantischem Redesign.

Eine zuverlässige Migration umfasst typischerweise Inventarisierung, SGML-Validierung, parserbasierte Konvertierung, XML-Validierung, Qualitätssicherung und erst danach optionales semantisches Redesign.

In diesem Leitfaden

Warum SGML-Daten weiterhin wertvoll sein können
SGML-zu-XML-Konvertierung mit SX/OpenSP
Konvertierung der DTD
Ein reproduzierbares ausführbares Beispiel
Qualitätssicherung und typische Migrationsrisiken
Migrationsarchitektur für große Bestände

Warum SGML-Daten weiterhin wertvoll sein können

SGML ist eine Legacy-Technologie, aber Legacy-Technologie bedeutet nicht automatisch schlechte Daten.

Ein gereifter SGML-Bestand kann explizite Kapitel, Metadaten, Identifikatoren, Abbildungen, Tabellen, Querverweise und fachliche Semantik enthalten. Das Problem liegt oft in der Umgebung: Editorunterstützung ist verschwunden, Publikationssysteme wurden abgelöst und Spezialwissen ist selten geworden.

Ziel der Migration ist daher häufig, die Struktur zu erhalten und gleichzeitig die veraltete Verarbeitungsumgebung zu ersetzen.

Warum SGML nicht einfach altes XML ist

Reale SGML-Anwendungen können ausgelassene Tags, unquotierte Attribute, Minimierung, Inklusionen, Exklusionen und Entitätsmechanismen verwenden, die XML einschränkt oder nicht unterstützt.

Deshalb lässt sich eine SGML-Datei nicht sicher konvertieren, indem man nur die Dateiendung ändert oder generische Suchen-und-Ersetzen-Regeln ausführt. Die Quelle muss zuerst gemäß ihrer SGML-Grammatik geparst werden.

Ein einfaches Beispiel

<manual>
<title>Maintenance Manual
<chapter id=installation>
<title>Installation
<para>This chapter describes the installation procedure.
</chapter>
</manual>

Mit einer passenden SGML-Deklaration und DTD können ausgelassene End-Tags und ein unquotierter Attributwert gültig sein. Das entsprechende XML muss diese Strukturen explizit machen.

Von SGML zu XML mit SX und OpenSP

James Clarks SP-Software wurde zu einer der bekanntesten SGML-Parserimplementierungen. SX wurde entwickelt, um SGML nach XML zu konvertieren, und OpenSP führt diese Rolle mit dem Befehl osx fort.

OpenSP dokumentiert osx als SGML-zu-XML-Konverter, der die SGML-Quelle parst und validiert, äquivalentes XML auf die Standardausgabe schreibt und vor SGML-Konstrukten warnt, die kein XML-Äquivalent haben.

Warum ein Parser wichtig ist

Ein Parser kann die DTD nutzen, um ausgelassene Tags zu rekonstruieren, Deklarationen zu interpretieren und Entitäten aufzulösen. Dadurch wird implizite SGML-Struktur zu expliziter XML-Struktur.

Beispiele, wie SGML-Syntax zu expliziter XML-Syntax wird, einschließlich quotierter Attribute, expliziter End-Tags und leerer Elemente — Abbildung 2: Typische SGML-zu-XML-Syntaxtransformationen. Das tatsächliche Ergebnis hängt von der SGML-Deklaration und der DTD ab.

Grundbefehl

osx -c catalog sgml/manual.sgm > xml/manual.xml

Die Option -c übergibt einen Katalog für die Auflösung von Identifikatoren und Entitäten. OpenSP dokumentiert UTF-8 als Standardausgabecodierung.

Das herunterladbare Beispiel muss exakt den Befehl verwenden, der mit der installierten OpenSP-Version ausgeführt und geprüft wurde.

Parsing nicht durch reguläre Ausdrücke ersetzen

Suchen-und-Ersetzen kann Zeichen verändern. Es kann Struktur, die von SGML-Deklarationen, Inhaltsmodellen, Tag-Auslassungsregeln oder Entitätsauflösung abhängt, nicht zuverlässig rekonstruieren.

Die SGML-DTD für XML konvertieren

Die Dokumentinstanzen sind nur die Hälfte der Migration. Auch das Ziel-XML benötigt eine Grammatik.

SGML-Minimierungsparameter gehören nicht zur XML-DTD-Syntax. Inklusionen und Exklusionen haben kein direktes XML-DTD-Äquivalent. Entitätsdeklarationen und andere SGML-Konstrukte können ebenfalls ein Redesign erfordern.

Beispiel: Minimierungsparameter

<!ELEMENT chapter - - (title, para+)>

Eine XML-DTD verwendet diese Minimierungsindikatoren nicht:

<!ELEMENT chapter (title, para+)>

Strukturelle Grammatik von Kontextregeln trennen

Strukturelle Grammatik  -> XML-DTD, XSD oder RELAX NG
Kontextuelle Regeln     -> Schematron

Das kann klarer und wartbarer sein, als jede historische SGML-Regel wörtlich nachzubilden.

Entitäten und Codierungen

Erstellen Sie ein Entitätsinventar und entscheiden Sie ausdrücklich, ob jede Entität expandiert, beibehalten, nach Unicode konvertiert, als Ressourcenreferenz dargestellt oder durch einen anderen Inklusionsmechanismus behandelt wird.

Legacy-Zeichencodierungen sollten gezielt getestet werden. UTF-8-Ausgabe beweist für sich allein nicht, dass jedes Quellzeichen korrekt interpretiert wurde.

Ein reproduzierbares SGML-zu-XML-Migrationsbeispiel

Das Beispiel zu diesem Artikel enthält Quell-SGML, das gültiges SGML, aber noch kein wohlgeformtes XML ist, zusammen mit DTD, Katalog, Entitäten, Konvertierungsskripten, Validierungsskripten und erwarteter XML-Ausgabe.

Paketstruktur

sgml-to-xml-example/
├── README.md
├── catalog
├── dtd/
├── entities/
├── sgml/manual.sgm
├── xml/expected.xml
├── scripts/
└── reports/

Was getestet wird

SGML-Parsing und -Validierung
Katalog- und Entitätsauflösung
SGML-zu-XML-Konvertierung mit OpenSP osx
XML-Wohlgeformtheit
Validierung gegen die Zielgrammatik, sofern anwendbar
Vergleich mit dem erwarteten Ergebnis
Fehlerbehandlung und Exit-Codes

Beispiel ausführen

./run.sh

Unter Windows verwenden Sie run.cmd oder .\run.ps1.

Das Konvertierungsskript validiert die SGML-Quelle mit onsgmls -c catalog -s sgml/manual.sgm und führt anschließend osx -c catalog sgml/manual.sgm > xml/manual.xml aus. Das Validierungsskript prüft XML-Wohlgeformtheit, validiert das erzeugte XML gegen dtd/manual-xml.dtd und vergleicht das Ergebnis nach XML-Kanonisierung mit xml/expected.xml.

Vollständiges Beispiel herunterladen

sgml-to-xml-example.zip

Qualitätssicherung für die SGML-zu-XML-Migration

Validierung ist notwendig, aber nicht ausreichend.

Ein Dokument kann gültiges XML sein und dennoch falsche Referenzen, fehlende Abbildungen oder veränderte Semantik enthalten. Eine professionelle Migration kombiniert daher Parservalidierung mit Qualitätssicherung auf Repository-Ebene.

Architektur mit SGML-Quelle, Grammatik- und Entitätsbehandlung, Konvertierung, XML-Validierung und nachgelagerter Verarbeitung — Abbildung 3: Konvertierung, Validierung und Qualitätssicherung sollten getrennte Stufen sein, damit Fehler nachvollziehbar bleiben.

Empfohlene Prüfungen

Anzahl der Quell- und Zieldokumente
Anzahl von Kapiteln, Abbildungen und Tabellen
eindeutige IDs
auflösbare Referenzen
vorhandene externe Ressourcen
Testfälle für Zeichencodierungen
anwendungsspezifische Schematron-Regeln

Typische Risiken

fehlende DTD-Module oder Entitätsdateien
veraltete Public Identifier oder Kataloge
ungültiges Quell-SGML
Zeichencodierungsprobleme
SGML-Inklusionen oder -Exklusionen, die eine neue Validierungsstrategie erfordern
proprietäre Processing Instructions oder Anwendungskonventionen

Klassifizieren Sie diese Probleme, statt sie stillschweigend zu reparieren.

Große SGML-Bestände im Maßstab migrieren

Große Repositories sollten als wiederholbare Pipelines mit expliziten Logs und messbaren Quality Gates verarbeitet werden.

SGML-Repository
      |
      v
Inventarisierung
      |
      v
SGML-Validierung
      |
      v
OpenSP-Konvertierung
      |
      v
XML-Validierung
      |
      v
Automatisierte QS
      |
      v
Optionales XSLT
      |
      v
Ziel-XML

Technische Konvertierung von semantischem Redesign trennen

Erstellen Sie zuerst strukturell äquivalentes XML. Verwenden Sie anschließend XSLT oder eine andere kontrollierte Transformation, um das Zwischen-XML in die neue Zielvokabularstruktur zu überführen.

So lässt sich leichter erkennen, ob ein Fehler beim SGML-Parsing oder während einer späteren semantischen Transformation entstanden ist.

Was nach der Migration möglich wird

XSLT-basiertes Publizieren
XPath und XQuery
XSD-, RELAX-NG- und Schematron-Validierung
HTML-, PDF- und EPUB-Ausgabe
Suche, APIs und Content-Repositories
strukturierte Eingaben für RAG- und KI-Workflows

Fazit

SGML ist alt. Strukturierte Inhalte sind es nicht. Bewahren Sie DTDs, Kataloge und Entitäten, parsen Sie die Quelle als SGML, validieren Sie das Ergebnis und fahren Sie erst dann mit der XML-Modernisierung fort.

<< zurück

vor >>