Choose an XML storage approach around your documents and the questions you must answer. Start with representative records, update patterns, and operational requirements. Then compare how each option preserves structure, retrieves results, and recovers from failure.
Match storage to the workload
| Approach | Useful fit | Evaluate |
|---|---|---|
| Versioned files | Modest collections processed in batches | Concurrent edits, discovery, access controls, and backup restoration. |
| Relational database with XML facilities | XML accompanies existing relational records | Supported query functions, indexing, update rules, and serialization. |
| Native XML database | Many structure-aware queries across document collections | Query/version support, index behavior, transactions, and administration. |
Some applications need the original bytes, including signatures or exact lexical formatting. Others need an equivalent document tree. Specify that requirement before testing: parsing and reserializing may change prefixes, whitespace, or attribute order even when the application-level meaning survives.
The 2003 Tamino and Panscopic integration reflected a recurring need: reporting directly on hierarchical content. Today's selection should be based on a tested workload. W3C XQuery 3.1 defines a language for querying XML data; product support and storage behavior still require implementation documentation.
Run a report across two documents
The XML labs pack includes north.xml and south.xml. These fictional sites hold A1 with two and one copies respectively; north also holds three copies of B2. Install saxonche and run python query.py from the extracted folder. The helper executes report.xq and writes report.xml.
declare namespace s = "urn:yenra:stock";
let $rows := (doc("north.xml"), doc("south.xml"))/s:site/s:stock
return <report>{
for $id in distinct-values($rows/@book)
order by $id
return <book id="{$id}"
copies="{sum($rows[@book = $id]/@copies ! xs:integer(.))}"/>
}</report>Expect A1 with copies="3" and B2 with copies="3", sorted by identifier. The query combines records, groups by book ID, converts counts to integers, and constructs a report. Changing south's A1 quantity to four should produce six copies of A1. This query-language exercise runs over files. Use separate workload tests to evaluate database server performance.
Make the report's assumptions explicit
The example assumes each site file is current, counts are nonnegative integers, and a book's ID means the same thing at both sites. In production, establish a consistent snapshot or record source timestamps and explain the resulting limits. Adding two individually valid records can double-count a transfer that appears in both systems.
Identify missing fields, duplicate source rows, unknown identifiers, and empty collections before treating a total as complete. A conversion error should lead to a visible rejected record or failed report, according to a documented policy. Silently converting a bad count to zero conceals missing information.
Evaluate the complete service
Create a pilot with the actual document shapes, including long text, repeated children, namespaces, and representative sizes. Record load time, query latency, peak memory, index storage, and update cost on the same hardware and dataset. Include warm and cold runs so caching is visible.
Exercise an interrupted import, a rejected update, a restored backup, and a permissions change. Check that a query returns only the documents its caller may see. Treat submitted XQuery as executable code: resource access and update capabilities belong behind deliberate controls. The bundled helper runs a trusted local query and supplies no sandbox for other people's queries.
A successful pilot should leave a reproducible dataset, query set, expected answers, and recovery record. Choose the smallest system that meets those measured needs and operational constraints.