Field Guide
SGML to S1000D: How Legacy Conversion Actually Works
The Good News First
Structure In, Structure Out
If your legacy manuals live in SGML, start grateful: the content was validated against a DTD from birth, so its structure is declared rather than implied. That makes the mapping to S1000D largely mechanical — and testable, which matters more. The syntax layer (SGML's minimization and quirks into clean XML) is genuinely solved tooling. The real work is the mapping above it: legacy elements into S1000D structures, monolithic documents split into modules with real data module codes, everything conformant to the project's business rules. Tools execute that mapping. They cannot decide it — “convert to XML” was never the requirement.
The Method
Sample First, Then Production-Line It
Every conversion we run starts the same way: a representative sample— worst tables, oldest files, the math, the graphics callouts — through the real pipeline. The sample yields the three numbers that make an estimate honest: the automation rate, the exception catalog (SGML's cluster predictably in entities, processing instructions, tables, and graphics references), and the per-module effort for what remains. Then, before volume starts, the governance decisions: target issue and BREX, the coding scheme and SNS the content maps into, the re-author-versus-convert line, and illustration handling — including whether CGM libraries keep their hotspots. Settled once, conversion runs as a production line; unsettled, every module becomes a meeting.
The strategic frame is our standard convert-or-ingest split: convert the living document families, ingest the settled tail as-is — and if a government CSDB is the destination, the conformance bar is set by the repository, not by taste. What the whole discipline buys you is the thing legacy programs rarely have: a cost you can defend, derived from evidence instead of optimism.
FAQ
Questions We Hear
Is there a tool that just converts SGML to XML?
For the mechanical layer, yes — SGML-to-XML syntax conversion is well-trodden, and pipelines built on transformation tooling handle the bulk reliably. But 'to XML' is rarely the actual requirement; 'to S1000D data modules under our business rules' is. That's a mapping problem, not a syntax problem: your legacy DTD's elements must land in S1000D structures, content must split into modules with real data module codes, and project rules must be satisfied. A tool executes that mapping; it cannot decide it. Anyone quoting tool-only conversion for a contractual deliverable is quoting the easy third of the work.
Why do SGML libraries convert better than Word or PDF?
Because the structure is real. An SGML library was validated against a DTD from birth — headings, steps, warnings, and tables are declared, not implied by formatting — so the mapping to S1000D is largely mechanical and, crucially, testable. Word libraries carry twenty years of formatting drift; PDFs carry no structure at all. SGML's exceptions cluster in known places (custom entities, processing instructions, tables, graphics references, minimization quirks) rather than being uniformly distributed through every file.
What is the sample-first method?
Before quoting or committing, convert a genuinely representative sample: not the cleanest manual, but a slice spanning document types, the worst tables, the math, the graphics callouts, and the oldest files. The sample tells you the automation rate (how much converts untouched), the exception catalog (what breaks, and whether it breaks consistently), and the per-module effort for the remainder. Estimates made from the sample hold; estimates made from file counts don't. We refuse to quote conversions any other way, and you should be suspicious of vendors who will.
What decisions matter more than the tooling?
The governance ones, made before volume conversion starts: the target baseline (which S1000D issue, which business rules — the BREX you'll validate against), the data module code scheme and SNS the content maps into, what qualifies for re-authoring instead of conversion, how illustrations are handled (converted, redrawn, or ingested with hotspots preserved), and who owns exception decisions when the pipeline surfaces them. Programs that settle these first run conversion as a production line. Programs that don't, relitigate them per module — at production-line prices.
Get In Touch
Sample First. Always.
Send us a representative slice of your SGML library and we'll return the three numbers that make your conversion estimate real — automation rate, exception catalog, honest effort.