Useful XML conversion starts with the receiving system’s document model. Decide what headings, paragraphs, tables, images, and references mean in that model. Then build a mapping and verify the result against both the destination contract and the approved source.
Define the destination first
Ask the recipient for a schema, a valid example, and its rules for asset locations, identifiers, and required fields. An archive, publishing system, and database importer may need different representations of the same source. Record which features must survive and which transformations are acceptable.
A modern .docx is an Open XML package containing multiple parts. Microsoft’s WordprocessingML structure guide explains document, body, paragraph, run, and text elements. Extracting document XML exposes Word’s model; producing a publishing vocabulary requires another mapping step. Legacy .doc files need a compatible reader or prior conversion.
Keep an untouched source. Inventory styles, tables, drawings, notes, tracked changes, and embedded objects. Resolve proposed revisions with the owner before turning them into published content.
Review a mapping before automating it
| Source | Example destination | Verification |
|---|---|---|
| Heading 1 style | section/title | Count and hierarchy match the approved outline. |
| Body paragraph | p | Text, emphasis, and significant spaces survive. |
| Table | table with headers and rows | Merged cells, units, and reading order are accounted for. |
| Picture and caption | figure with asset reference | Asset exists; orientation and text alternative are reviewed. |
| Cross-reference | link to stable identifier | The destination exists after conversion. |
This is a fictional mapping, not a standard vocabulary. A heading recognized only by font size needs review: an oversized quotation can resemble a section title. Prefer explicit styles and structure, then flag exceptions.
Maintain an asset manifest linking source objects to output filenames. Rasterizing a drawing changes editability and may change usable resolution. OCR introduces a separate recognition step; compare names, quantities, and table alignment against the scan.
Work through a small example
Suppose a source has a heading “Packing a desk kit,” a paragraph, and a captioned picture. An agreed destination might be:
<guide id="desk-kit">
<title>Packing a desk kit</title>
<section id="contents">
<title>Contents</title>
<p>Include a notebook and a desk lamp.</p>
<figure src="kit.png">
<caption>Completed kit</caption>
</figure>
</section>
</guide>The destination schema must define these elements and their order. The picture remains a separate asset. A filename inside XML does not deliver its bytes. Add required alt text, dimensions, or media identifiers to the contract before the full run.
Use an XML serializer to escape text. A title containing an ampersand should recover the same characters after serialization and parsing. Regular-expression replacement of arbitrary Word markup cannot reliably account for document structure.
Reconcile a pilot conversion
Select a representative pilot including difficult tables, revisions, and figures. Convert into a separate output folder and record source hashes, converter version, mapping version, and warnings. Parse and validate each output, then inspect identifier uniqueness and asset references.
Compare the rendered result beside the approved source. A reconciliation record could say: 12 headings → 12 titles; 4 pictures → 4 references and 4 delivered files; 1 tracked deletion → omitted by an approved rule. Counts expose omissions but cannot prove text fidelity. Have a second reviewer inspect difficult cases and agree acceptance criteria before scaling up.
Practice validation with the XML practice pack; its README explains valid and invalid inputs. This is a validation exercise, not a general Word converter. If a pilot produces unexplained missing blocks, refine the mapping and rerun that pilot before processing the collection.