Home → Migration → From SGML
Migrating from SGML sources
SGML content — MIL-STD-40051-B era manuals, older logistics data, legacy commodity TMs — carries structural intent that maps cleanly to XML. Ironmark converts on ingest and lands the result in a standard project so downstream authoring, review, and publish behave the same as native-authored content.
What auto-conversion handles
Structural
- SGML → conformant XML — declaration, DOCTYPE, entity references
- Tag-case normalization (SGML permissive → XML strict)
- Attribute quoting + minimization expansion
- Empty-element normalization
- Namespace injection where the target schema requires it
Content
- 40051-B → 40051-C element remapping via the tag map
- Optional 40051 → S1000D conversion path (see Legacy Conversion)
- Character-entity resolution against the source DTD
- Graphics reference rewriting to project-local ICNs
- DTD folder retained if the source manual has a customer variant
What needs a hand
Auto-conversion is a starting line, not a finish line. Two categories consistently need human review:
- Semantically ambiguous constructs — SGML tolerates shapes that XML doesn't, and the tolerated shape can encode meaning that isn't obvious from tags alone (e.g. inferred paragraph breaks, implied structure from indent). The converter flags these; a human decides.
- Legacy-specific element usage — programs that extended their SGML DTD with local elements need a tag-map entry for each local element. Unmapped elements get a passthrough so the content is preserved, but they won't validate against the target schema until mapped.
Path through the tool
1. Create a project on the target SDM
Pick the SDM the converted content should land in (40051-C, S1000D 4.2 / 5.0 / 6.0, 63029). This becomes the validation target.
2. Ingest the SGML source
Upload as a source archive. Ironmark converts each source file, records disposition (converted / passed-through / rejected), and produces a report of unmapped elements and structural warnings.
3. Review the conversion report
The report lists every non-clean disposition with the source line reference. Unmapped elements aggregate to show which local extensions need tag-map entries. Structural warnings link to the source location.
4. Fix + re-ingest, or commit
For unmapped elements, extend the project's tag map and re-run ingest against the same source archive — Ironmark idempotently overwrites the prior conversion. For content-level fixes, commit and edit in the structured editor.
5. Baseline the pre-edit state
Before beginning content edits, cut a baseline. That gives you a rollback anchor if the auto-conversion result turns out to need re-work, and a provenance point for auditors who want to see "the manual as it came in from the legacy source."
Auto-conversion should never silently drop content. Ironmark's default is passthrough for unrecognized elements — the source content survives even if it can't validate yet. That way the human review pass is looking at "what needs remapping" rather than "what got lost."
Related
← All migration guides