xslt 1.6.3

There is a newer version of this package available.
See the version list below for details.
dotnet tool install --global xslt --version 1.6.3
                    
This package contains a .NET tool you can call from the shell/command line.
dotnet new tool-manifest
                    
if you are setting up this repo
dotnet tool install --local xslt --version 1.6.3
                    
This package contains a .NET tool you can call from the shell/command line.
#tool dotnet:?package=xslt&version=1.6.3
                    
nuke :add-package xslt --version 1.6.3
                    

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 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. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

This package has no dependencies.

Version Downloads Last Updated
1.6.4 44 8/16/2026
1.6.3 52 8/14/2026
1.6.2 46 8/13/2026
1.6.1 70 8/4/2026
1.6.0 72 7/31/2026
1.5.0 73 7/27/2026
1.4.25 75 7/17/2026
1.4.24 70 7/14/2026
1.4.23 88 7/12/2026
1.4.22 82 7/10/2026
1.4.21 74 7/9/2026
1.4.20 64 7/9/2026
1.4.19 77 7/9/2026
1.4.18 70 7/8/2026
1.4.17 76 7/7/2026
1.4.16 82 6/30/2026
1.4.15 84 6/25/2026
1.4.14 90 6/22/2026
1.4.13 86 6/21/2026
1.4.12 85 6/19/2026
Loading failed

### Fixes

- **A nested `xsl:copy` inside a typed (`as=`) template no longer vanishes from the output, taking a spurious `XTTE0505` with it.** A typed template installs a sequence accumulator, which routes `xsl:copy` of an element down its serialize-then-reparse path: the copy is written to the output buffer, sliced back out, and reparsed into an XDM node inside a synthetic wrapper element. That serialized fragment carries only the namespace declarations it needed *at its position* — any an ancestor already declares are suppressed as redundant — so a **nested** copy reparsed on its own had an undeclared prefix and threw, and the handler had already truncated the buffer: the element was destroyed outright. Validating the declared cardinality against the resulting empty capture then reported `XTTE0505: … expected exactly one item, got 0`. The synthetic wrapper now declares the in-scope namespaces so the fragment stands alone, and the parse-failure fallback restores the markup it truncated instead of dropping it. The failure required all three of a declared `as=` type, nesting, and an `xsl:copy` parent — a literal result element parent uses a different construction path and was unaffected. Reported by Martin Honnen against XSpec 4.0.3 `src/compiler/base/resolve-import/gather/gather-specs.xsl`, which this unblocks: the resolve-import stage sits on the critical path for running XSpec suites at all.