xslt 1.6.7

dotnet tool install --global xslt --version 1.6.7
                    
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.7
                    
This package contains a .NET tool you can call from the shell/command line.
#tool dotnet:?package=xslt&version=1.6.7
                    
nuke :add-package xslt --version 1.6.7
                    

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.7 46 8/24/2026
1.6.6 55 8/23/2026
1.6.5 53 8/22/2026
1.6.4 82 8/16/2026
1.6.3 66 8/14/2026
1.6.2 57 8/13/2026
1.6.1 71 8/4/2026
1.6.0 73 7/31/2026
1.5.0 74 7/27/2026
1.4.25 77 7/17/2026
1.4.24 72 7/14/2026
1.4.23 90 7/12/2026
1.4.22 83 7/10/2026
1.4.21 75 7/9/2026
1.4.20 65 7/9/2026
1.4.19 80 7/9/2026
1.4.18 71 7/8/2026
1.4.17 77 7/7/2026
1.4.16 83 6/30/2026
1.4.15 87 6/25/2026
Loading failed

Four engine fixes, two of them reported by Martin Honnen, plus a large correction to what
the conformance suite actually measures.

### `xsl:array` honours its `select` attribute

   <xsl:array select="1 to 5"/>     gave [], must give [1,2,3,4,5]

The parser read only child content, and that element has none. `xsl:array-member` fifteen
lines below it had always honoured `select`; only `xsl:array` never did. `composite` is now
read too — no by default, so each item becomes its own member — and XTSE3185 is raised when
`select` and a sequence constructor are both present.

A second fault in the same instruction, which the reported case would not have shown: the
finished array was handed on as a SEQUENCE of its members. That still printed
`[1,2,3,4,5]` — the right answer — and broke only at the edges, where a one-member array
collapsed to its member and `composite="yes"` became indistinguishable from `"no"`.

### The `xslt` tool reads files in the encoding they declare

`File.ReadAllText` assumes UTF-8, so a stylesheet or source declaring another encoding —
the W3C corpus has many in ISO-8859-1 — decoded to U+FFFD and then failed to parse with a
message about its own mangling:

   Error: Name cannot begin with the '<U+FFFD>' character, hexadecimal value 0xFFFD.

The conformance harness had always decoded correctly, which is exactly why the corpus ran
and the shipped tool did not.

### Unicode normalization applies to character data, not to names

With `normalization-form="NFD"` an attribute written `üss="üß"` came out as
`u&#x308;ss="u&#776;ß"` — the NAME decomposed as well as the value. A name is an identity
compared by code point, so normalizing it silently renames the attribute.

### `&#xD;` in an XPath string literal survives

   string-to-codepoints('&#x9;&#xa;&#xd;')   gave 9 10 10, must be 9 10 13

An XPath expression in a stylesheet has already been through an XML parser, where `&#xD;`
is data that XML 1.0 §2.11 exempts from line-ending normalization. The XQuery parser then
applied its query-SOURCE rule (§A.2.1) a second time and could not tell that CR from a line
break. Needed `PhoenixmlDb.XQuery` 1.6.7, which this release pins.

### Conformance measurement

Not shipped in the engine, but it changes what the numbers mean. The XSLT test runner ended
its assertion switch with `_ => true`, so every assertion kind it did not implement was
reported as a PASS — including `<assert>`, the single most common assertion in the suite at
11024 occurrences. Seven kinds were missing, ~12800 occurrences in all.

With them implemented the honest figure is **96.3%**, against a previously published 98.5%
computed with assertions that could not fail. 176 real defects became visible; two are
fixed in this release.

The XQuery-side runner had the opposite defect — unimplemented assertions returned false —
which had been deflating QT3. Fixing that and seven other harness faults took QT3 from
76.56% to **95.11%**, clearing its 95% gate for the first time.

### Notes

Pins Core 1.6.7 and XQuery 1.6.7. Both were verified against the PUBLISHED packages before
this was tagged, not against sibling source — that combination is otherwise untested until
release day.