mirror of
https://github.com/alexandrev/xslt-lab.git
synced 2026-09-22 13:43:14 +00:00
alexandrev-tibco
a333d175f4
- Update index.html title, description, keywords to include xslt 3.0, validator, saxon - Update JSON-LD schema with full feature list and XSLT 3.0 - Change footer link from "News" to "Blog & Tutorials", update URL to blog.xsltplayground.com - New articles: online editor guide, validator guide, string functions, xsl:for-each-group Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
79 lines
4.1 KiB
Markdown
79 lines
4.1 KiB
Markdown
---
|
|
title: "XSLT validator online: catch errors before running your transform"
|
|
description: "How to validate XSLT stylesheets online. Catch syntax errors, undefined variables, and namespace issues before they hit production."
|
|
date: 2025-03-22T00:00:00Z
|
|
tags: ["xslt", "validation", "debugging", "tools"]
|
|
---
|
|
|
|
A broken XSLT stylesheet can fail in several ways: a syntax error stops the processor immediately, a namespace mismatch silently produces empty output, or an undefined variable causes a runtime error that only appears with specific inputs. Catching these issues early, before the stylesheet reaches a test environment, saves significant debugging time.
|
|
|
|
## What XSLT validation actually checks
|
|
|
|
XSLT validation happens at two levels:
|
|
|
|
**Compile-time checks** happen when the processor parses the stylesheet. These catch:
|
|
- Malformed XML in the stylesheet itself
|
|
- References to undefined named templates or functions
|
|
- Type errors in static expressions
|
|
- Invalid XSLT element usage (wrong attributes, missing required children)
|
|
|
|
**Runtime errors** only appear when the stylesheet runs against actual input:
|
|
- Missing nodes that are assumed to exist
|
|
- Type errors in dynamic expressions
|
|
- Namespace mismatches between the stylesheet and the input document
|
|
|
|
A good validator runs both levels.
|
|
|
|
## Using XSLT Playground as a validator
|
|
|
|
[XSLT Playground](https://xsltplayground.com) runs Saxon, which is one of the most thorough XSLT processors available. When you paste a stylesheet and click Run, Saxon compiles it first and reports compile errors with exact line numbers before attempting execution.
|
|
|
|
For runtime errors, the trace mode shows you exactly which template fired, which node was being processed, and where the failure occurred. This is more useful than a bare error message because it gives you the execution context.
|
|
|
|
To validate a stylesheet quickly:
|
|
1. Paste the stylesheet into the editor
|
|
2. Provide a minimal XML input — even an empty `<root/>` catches most compile errors
|
|
3. Run with trace enabled
|
|
4. Check the error panel for compile-time issues and the trace panel for runtime behaviour
|
|
|
|
## Common XSLT errors and how to spot them
|
|
|
|
**Namespace mismatch**
|
|
Your input uses `xmlns="http://example.com/ns"` but your stylesheet matches `element-name` without the namespace. The match never fires, output is empty.
|
|
|
|
Fix: declare the namespace in the stylesheet and use the prefix in match patterns:
|
|
```xml
|
|
<xsl:stylesheet version="2.0"
|
|
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
|
|
xmlns:ex="http://example.com/ns"
|
|
xpath-default-namespace="http://example.com/ns">
|
|
```
|
|
|
|
Using `xpath-default-namespace` (XSLT 2.0+) avoids having to prefix every element name in your XPath expressions.
|
|
|
|
**Undefined variable**
|
|
You reference `$config` but it is only defined inside a conditional branch that did not execute for this input. Saxon reports: *Variable $config has not been assigned a value*.
|
|
|
|
Fix: move variable declarations to the template root or provide a default:
|
|
```xml
|
|
<xsl:variable name="config" select="if (config) then config else 'default'"/>
|
|
```
|
|
|
|
**Wrong output method**
|
|
You are generating HTML but the processor serialises as XML, adding self-closing tags that browsers reject. Declare the output method explicitly:
|
|
```xml
|
|
<xsl:output method="html" version="5" encoding="UTF-8" indent="yes"/>
|
|
```
|
|
|
|
**Template priority conflict**
|
|
Two templates match the same node with equal priority. Saxon signals an error rather than silently picking one. Assign explicit `priority` attributes to resolve the conflict:
|
|
```xml
|
|
<xsl:template match="item[@type='special']" priority="1">
|
|
```
|
|
|
|
## Validating before deploying to production
|
|
|
|
If you run XSLT as part of an integration pipeline (MuleSoft, Tibco, IBM DataPower, or a custom backend), test the stylesheet in [XSLT Playground](https://xsltplayground.com) against representative inputs before deploying. Saxon in the playground uses the same processor your backend may be running, so errors caught here are errors caught before production.
|
|
|
|
Export the workspace as JSON and keep it as a regression test artifact. If a future change breaks the transform, you have the original inputs and expected output to compare against.
|