Match patterns

The syntax of match patterns is extended to make it easier to match maps and arrays. As with the XPath syntax extensions, these extensions are available only if explicitly enabled.

In particular the syntax ma-type predicate* is allowed in a pattern, where ma-type is any of:

type(...)
atomic(...) (deprecated)
union(...)
record(...)
map(...)
array(...)

For example if a type alias has been declared:

<xsl:item-type name="cx:complex" type="record(r as xs:double, i as xs:double)"/>

Then it can be used in a match pattern to match instances of the type, with or without predicates:

<xsl:template match="type(cx:complex)[?i=0]">{?r}</xsl:template><xsl:template match="type(cx:complex)">{?r}{if (?i ge 0) then '+' else ''}{?i}i</xsl:template>

The construct type(T) at the start of a pattern can be regarded as an abbreviation for .[. instance of type(T)].

Note that from 12.2 the syntax for type patterns changes so that match="type(T)" may specify any item type as T (including, for example, an atomic type name: match="type(xs:integer)"). The syntax match="atomic(T)" has now been dropped from the draft specification, and match="type(T)" should be used instead. For now Saxon still allows match="atomic(T)" but will produce a warning; it will be removed in a future Saxon release.

Patterns for record types are particularly useful when JSON is processed using XSLT template rules. For example, a JSON object such as the following:

{ "firstName": "John", "lastName": "Doe", "email": "john.doe@example.com", "age": 45, "weight": 67 }

can be matched with a pattern such as match="record(firstName, lastName, email, *)". Naming a few of the properties that characterize the object is sufficient (but remember to make the record type extensible by including ", * at the end). There's generally no need to include all the properties, or to give their data types, because a test like this is generally sufficient to be unambiguous. The order of properties, of course, is immaterial.

Predicates can be added as with any other pattern, for example match="record(firstName, lastName, *)[?department='sales']".

The rules for calculating the default priority of these patterns are not yet stable; explicit priorities should be used if there is any risk of ambiguity.