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(...) -
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)].
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.