Classic XSLT processing requires the source document to be parsed into a full in-memory DOM before any template can match against it. For documents in the tens or hundreds of megabytes — large EDI imports, statutory filings, aggregated transaction journals — the heap requirement grew with document size and forced operators to over-provision container memory limits against the worst case.
The XSLT processor now operates in XSLT 3.0 streaming mode for transforms where the templates are streamability-compatible. The source document is consumed as a one-pass event stream ; only the nodes the current template actually touches are materialised in memory. A 200 MB XML-to-JSON conversion completes inside a 256 MB heap rather than the multi-gigabyte heap the in-memory DOM would have required.
- Streamability detection. The processor analyses each compiled XSLT and routes to the streaming engine when the template set is streaming-compatible ; non-streamable transforms continue to use the in-memory engine without any application change.
- Right-sized memory. Operators size container heaps for steady-state working set rather than worst-case document size — typical reduction is 4–8× on document-heavy workloads.
- Same XSLT source. Templates written for the in-memory engine that happen to be streamable run on the streaming engine unchanged ; no rewrite required.