I've been doing some experiments with assertions.

It seems to be quite common to define an assertion that constrains some element deep within the document to be consistent with an attribute of the document element (for example, a version attribute). For example one might constrain an XSLT stylesheet to say:

<xs:assert test="if (@version='1.0') then empty(.//xsl:result-document) else true()"/>

The problem about such assertions is that they have to appear on the complexType of the document element (because they apply to the subtree rooted at that node). This makes it almost impossible when the assertion fails to provide diagnostics  saying where in the instance document the problem actually arises.

I'm not proposing that we change the rule that the assertion belongs with the type that defines the subtree within which the constraint applies. But I think there might be a case for allowing the condition to be specified in two parts:

<xs:assert select=".//xsl:result-document" test="empty(ancestor-or-self::xsl:*[@version='1.0'])"/>

(which in this example is actually a more precise expression of the desired constraint, since the version attribute can appear anywhere)

The default for select would be select="." which leaves test with the current meaning. In the presence of the select attribute, the test would be applied to each node selected by the select expression, allowing the diagnostics to refer to the position of that selected node. Furthermore, this allows multiple errors to be reported if more than one selected element is invalid.

I know that some might think this introduces unnecessary complexity. But in its absence, users are going to have to do some complex queries to find out where the errors in their documents actually are.