How to Evaluate Your XSLT Editor

“XSLT (Extensible Stylesheet Language Transformations) remains one of the most capable—and most underestimated—technologies for transforming structured content.” (Vasu Chakkera, 2025).

So it is understandable that XSLT is an important technology in fields such as in publishing and governmental data exchange. Fortunately, it is still getting more and more powerful. Especially the latest version of XSLT (XSLT 3.0) combined with XPath 3.1 is extremely powerful. It overcomes several issues of the earlier versions: you can now also transform Json files, it is far less verbose, you can use text value templates, XPaths can be evaluated dynamically, functions and types are added, the function set is extended with Sequences, Arrays and Maps and finally streaming is supported (for more explanation, I recommend reading: Why You Should Be Using XSLT 3.0).

But all these capabilities come with a cost: XSLT and XPath are not trivial: they have a steep learning curve, and are so extensive, it is practically impossible to know and use all features by heart. Having an editor that helps you write correct XSLT 3.0 and XPath 3.1 quickly can make a significant difference in both productivity and correctness.

Many XSLT editors are available, and you may be using one already for years. Switching is not an easy step: e.g. how do you determine whether a new tool would be worth the learning process? This article outlines criteria you can use to assess whether an editor truly supports modern XSLT development.

I have based the criteria on the W3C specifications for XSLT and XPath —after all, the primary task of an editor is to help you produce code that conforms to those standards.

Next to the general criterion of supporting the latest standards, I distinguish three main use cases your editor should support: viewing, editing, and running. Below I elaborate on the criteria and I provide several test cases you can use to evaluate your tool.

Support for the Latest Standards

The older standards (XSLT 1.0 and 2.0) are no longer maintained and Chromium has even planned to fully remove support for XSLT 1.0 from the Chrome browser. Luckily, XSLT 3.0 and XPath 3.1 are very much alive-and-kicking in the world of publishing, finances and governments. Editors that support XSLT 3.0 and XPath 3.1 are OxygenXML, XMLSpy, XMLBlueprint and VSCode (with the XSLT/XPath extension).

Viewing your XSLT

Even before editing or executing a transformation, an editor has several ways to help you understand your code.

Syntax Coloring

Good syntax coloring improves readability by distinguishing the structural components of XSLT and XPath.

Is the coloring correct according to the XSLT and XPath grammar?
To test correctness, try expressions that mix names and operators:

<xsl:value-of select="and and and and and"/>

Correct coloring should distinguish and as a name from and as a boolean operator (see XPath AndExpr and NameTest). So the correct coloring would be:

<xsl:value-of select="and and and and and”/>

Other examples to test:

• <xsl:value-of select="gt gt gt gt gt gt gt gt gt"/>
• <xsl:value-of select="123 treat as xs:integer + + + 3"/>

Tooltips

Tooltips help you understand XPath expressions quickly by showing inline documentation—ideally with syntax coloring and hyperlinks.

Evaluate:

• Are the tooltips clear and readable?
• Do they include syntax coloring?
• Are there links to documentation?
• Do they appear for all XPath components?

Jump-to-Definition

To save time navigating larger stylesheets and (large) sets of stylesheets, a good editor lets you jump directly to definitions. Check:

• Jumping to functions (including user-defined functions), templates and variables.
• And because these functions, templates and variables can be defined outside the current file, i.e. in a ‘main’ file that includes other files, the editor should also be able to jump to these definitions, thus opening the appropriate file.

Precise XPath Error Locations

Accurate error reporting is crucial—especially for XPath, where small mistakes can be hard to spot.

Check whether the editor:

• Jumps to errors in included/imported stylesheets
• Highlights the exact position of XPath errors

You can test this latest feature with this example file containing XPath errors. These are the exact error locations, underlined in red:

Editing your XSLT

Editing support determines how quickly you can write correct XSLT and XPath. Code completion is central: the editor should present only the valid options at any point.

XSLT Syntax

The basic support for code completion of XSLT 3.0 provides completion for all elements and attributes. An editor can help you by:

• Including the semantics (i.e what it is used for).
• Including code completion for both named and matched templates

XPath Functions

XPath 3.1 has over 200 built in functions for string manipulation, mathematics, arrays, maps, etc. Remembering the correct name and spelling can be hard and the function names can be very long.

State of the art completion for functions, contains:

• Completion for all XPath 3.1 functions, especially the 30 functions added within the latest 3.1 version. Try for instance the math function pi:



• Completion for user-defined XSLT functions, even when declared in included files.

XSLT Variables

The scope of XSLT variables is important for correct interpretation of your code. Editors, however, can easily present either too many options or too few, thus making it unnecessarily difficult to write your code:

• Does the code completion account for the difference in scope of global vs local variables, static vs non-static variables?

Notice that ccc is not presented in the code completion.

• Does it suggest variables declared in included and or imported files?

XPath 3.1 Syntax

XPath is the most powerful part of XSLT—and the most error-prone. Quality XPath completion dramatically improves correctness.

Verify that the editor provides completion for:

• cast as expressions
• arrays ([ ])
• maps (map{…})
• built-in types such as xs:integer
• operators, such as and, or

XPath Expressions vs XPath Patterns

XPath expressions (xsl:template/@match) and XPath patterns (xsl:value/@select) may look alike, but the syntax is actually different.

Examples you can test:

• <xsl:template match="node-name() and node-name()"/>
  and is not allowed here and must not appear in completion.
• <xsl:value-of select="node-name() and node-name()"/>
  Here and is allowed and should appear in completion.

Running your XSLT

Running your stylesheet—executing the transformation—is the end goal of your XSLT. A good editor streamlines this process by being easy to use and supporting specific XSLT features.

Ease of Use

Check whether the editor:

• Runs your XSLT when pressing a shortcut key.
• Runs on unsaved files.
• Is fast, even on large files and file sets
• Does not flicker during transformations.
• Supports using URLs as input sources (besides Windows path)
• Offers multiple output options (in a browser, editor)
• Offers multiple output formats (text, XML, HTML)
• With included files, the editor should be able to run the top most stylesheet.

XSLT Parameters

Your editor should have a way to recognize which parameters are mandatory and easily set these parameters before running a transformation.

Initial Template

XSLT 3.0 allows running a stylesheet without an input document using xsl:initial-template.

So your editor should support this XSLT:

<xsl:template name="xsl:initial-template">

<xsl:value-of select="'HELLO WORLD!'"/>

</xsl:template>

Current XSLT Editors Compared

I hope I have given you a way to test whether your XSLT editor meets your needs—and perhaps I have even shown you features you didn’t know existed.

If you're interested in how the four XSLT 3.0 editors (OxygenXML, XMLSpy, XMLBlueprint, VSCode) perform against the presented criteria, please see the results of my comparison.

Please let me know if you have additional features that would make your XSLT editing faster, easier or more correct.