Examples of XSLT 2.0 Patterns

The table below gives some examples of patterns, and explains their meaning:




Matches any element whose name (tag) is PARA


Matches any element


Matches any PARA element whose parent is an APPENDIX


Matches any PARA element that has an ancestor named APPENDIX


Matches any SECTION element that is an immediate child of the outermost element in the document


Matches any element with a NAME attribute


Matches any PARA element that is the first PARA child of a SECTION element


Matches any SECTION element whose first TITLE child element has the value Contents


Matches any TITLE element whose parent is of type A or B or C (Note that this cannot be written (A|B|C)/TITLE, although that is a valid XPath 2.0 path expression.)


Matches any element in a document provided the top-level element in the document is named BOOK


Matches the character content of an A element


Matches any attribute of an A element

In a schema-aware stylesheet, it can be useful to match elements by their schema-defined type, rather than by their name. The following table shows some examples of this.




Matches any element that has been validated against the global element declaration named CHAPTER. More precisely, it matches an element named CHAPTER that has been validated against the type of the global element declaration named CHAPTER, and any element in the substitution group of the CHAPTER element.

element(*, ADDRESS-TYPE)

Matches any element that has been validated against the schema-defined global type definition ADDRESS-TYPE. The "*" indicates that there are no constraints on the element's name.

attribute(*, xs:date)

Matches any attribute that has been validated as an instance of xs:date, including types derived by restriction from xs:date.

XSLT 3.0 introduces a new option on an xsl:mode declaration, typed="strict" or typed="lax", which enables simple name patterns such as match="invoice" to be treated as if they were written match="schema-element(invoice)". This enables the processor to perform stricter type-checking, by checking the content of the template rule against the schema definitions for the invoice element.