The WG has issued a priority feedback request on the question of whether assertions should be allowed on simple types.

For the record, I think they should.  Here are some use cases:

(a) consider an attribute (perhaps called xsi:schemaLocation) whose value consists of a list of URIs, such that the cardinality of the list must be an even number. There is currently no way to express this constraint.

(b) consider an attribute whose value must be an integer that is a multiple of 10. This can be expressed clumsily using a pattern. But what about an integer that is a multiple of 20? or 7?

(c) consider a date that must be in the past, or in the future.

(d) consider a date that must not be a Saturday or Sunday

Without assertions on simple types, there is a danger that users will attempt to define such assertions on some containing complex type, which is not where they correctly belong; misplacing the constraint in this way will inevitably lead to maintenance difficulties.

I would propose that for assertions on simple types, the context item should be the string value of the element or attribute being validated, and the XPath expression will therefore not have access to any nodes. The examples above could be achieved with:

(a) test="count(tokenize(., '\s+') mod 2 = 0"

(b) test="number(.) mod 10 = 0"

(c) test="xs:date(.) lt current-date()"

(d) (xs:date(.) - xs:date('1901-01-06')) div xs:dayTimeDuration('PT1D') mod 7) gt 2