xslt 1.6.12
See the version list below for details.
dotnet tool install --global xslt --version 1.6.12
dotnet new tool-manifest
dotnet tool install --local xslt --version 1.6.12
#tool dotnet:?package=xslt&version=1.6.12
nuke :add-package xslt --version 1.6.12
xslt
Command-line XSLT 3.0/4.0 processor for .NET. Transform XML documents from the terminal using the PhoenixmlDb XSLT engine.
Installation
dotnet tool install -g xslt
Usage
# Transform XML with a stylesheet
xslt stylesheet.xsl input.xml
# Write output to a file
xslt -o result.html report.xsl data.xml
# Start from a named template (no source needed)
xslt -it main generate.xsl
# Pass parameters
xslt -p year=2026 -p title="Report" style.xsl data.xml
# Read source from stdin
cat data.xml | xslt transform.xsl
# Show timing breakdown
xslt --timing style.xsl large-input.xml
# Validate a stylesheet without running
xslt --dry-run style.xsl
# Stream large files (lower memory)
xslt --stream style.xsl large-input.xml
Features
- XSLT 3.0/4.0 — packages, streaming, maps/arrays, higher-order functions, JSON output
- Multiple output methods — XML, HTML, XHTML, text, JSON, adaptive
- Streaming — process large files without loading into memory
- xsl:result-document — generate multiple output files in one transform
- Parameters — pass values from the command line
- Timing — built-in performance profiling
- Tracing — log template matching, function calls, and built-in rules
Documentation
Full documentation at phoenixml.dev
License
Apache-2.0
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
This package has no dependencies.
| Version | Downloads | Last Updated |
|---|---|---|
| 1.6.13 | 51 | 9/2/2026 |
| 1.6.12 | 59 | 8/30/2026 |
| 1.6.11 | 55 | 8/29/2026 |
| 1.6.10 | 60 | 8/27/2026 |
| 1.6.9 | 220 | 8/26/2026 |
| 1.6.8 | 53 | 8/26/2026 |
| 1.6.7 | 63 | 8/24/2026 |
| 1.6.6 | 68 | 8/23/2026 |
| 1.6.5 | 62 | 8/22/2026 |
| 1.6.4 | 89 | 8/16/2026 |
| 1.6.3 | 69 | 8/14/2026 |
| 1.6.2 | 64 | 8/13/2026 |
| 1.6.1 | 72 | 8/4/2026 |
| 1.6.0 | 74 | 7/31/2026 |
| 1.5.0 | 78 | 7/27/2026 |
| 1.4.25 | 80 | 7/17/2026 |
| 1.4.24 | 74 | 7/14/2026 |
| 1.4.23 | 93 | 7/12/2026 |
| 1.4.22 | 83 | 7/10/2026 |
| 1.4.21 | 75 | 7/9/2026 |
### A global variable nobody reads could fail the whole transform
Found while working through the XSpec suites, following the thread Martin Honnen started.
The engine primed a stylesheet by initializing every global variable eagerly, before running
anything. If a global's initializer needed a context item and there wasn't one, that error was
fatal. It stayed fatal even when nothing in the stylesheet ever read the variable.
The shape that bites in practice is a stylesheet invoked through a named template with no source
document, importing a module that happens to declare something like:
<xsl:variable name="initial-document" as="document-node()" select="/"/>
The importing stylesheet never touches that variable. Priming does, and the transform dies
before doing any work. That is exactly what XSpec generates, since its test stylesheet imports
the stylesheet under test and runs it through `x:main`.
XSLT 3.0 §2.3.2 addresses this case directly:
> It is implementation-defined whether this error occurs during priming of the stylesheet or
> subsequently when the variable is referenced; and it is implementation-defined whether the
> error occurs at all if the variable or parameter is never referenced.
So the old behaviour was a legal reading of the specification. It was not the reading Saxon
takes, and real stylesheets are written against that one. We now defer: a failing initializer is
captured rather than propagated, and the error is re-raised only if something actually reads the
variable.
Deferral covers dynamic errors only. Static errors and circularity still surface at priming,
where they belong.
Two smaller things fell out of the same work. The variable fallback used to rewrite a deferred
error into "variable not bound", which named the wrong problem entirely and sent you looking in
the wrong place. And a deferred global could reach the XQuery layer as an internal wrapper
rather than a value, surfacing as "context item is not a node". That leak was already latent in
the abstract-variable path.
Across the 284 XSpec suites, the number reaching completion went from 62 to 66, and the
`XPDY0002` bucket dropped from 6 suites to 1.
### The `xslt` tool could hang forever instead of doing anything
Two `xslt` processes were found alive at 0% CPU having produced no output at all. One had been
running for 21 hours, the other for three days and nineteen hours.
A managed stack showed both parked in a console read. When a named template is invoked with
`-it` and no source document is supplied, the tool still tried to read a source from standard
input. Under a terminal that looks like a freeze. Under a script, a CI job, or an agent harness
where standard input is an inherited pipe that never reaches end-of-file, it waits forever.
When `-it` names a template the transform starts from that template and needs no source, so
there was never anything to wait for. The tool no longer reads standard input in that case.
Piping a document to an invocation without `-it` works exactly as before.
If you have ever had the tool appear to hang in automation, this was why.