In section 5.2 Expressions, the section describes the Function Conversion Rules as used, for instance, with the as-clause of xsl:variable.

A Note explains the difference between dynamic and static detection of type errors, and uses an example of a string value with 29 Feb, which cannot be xs:date because of its *value*, not its type.

However, a string can never be coerced into an xs:date. Perhaps the intention was a literal xs:untypedAtomic, or the untyped string value of an attribute or node.

The example in the Note is:

"Attempting to convert the string 2003-02-29 to a date is a dynamic error rather than a type error, because the problem is with this particular value, not with its type."

Note that the statement is not entirely false: a processor is not required to detect this statically, but this Note is specifically about statically detectable type errors, which this is (string can be cast to date, though, but that's a different subject).