From an email thread at https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Jan/0003.html (member-only):

On 4 Dec 2014, at 16:34, Abel Braaksma <abel.braaksma@xs4all.nl> wrote:

> Action item is a follow-up to https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Oct/0061.html, which discusses vague error conditions for xsl:context-item when the as-clause does not validate, or has a wrong / non-existing type.

MK responded:

Firstly, let's see what we currently say:

<xsl:context-item
  as? = sequence-type
  use? = "required" | "optional" | "absent" />

If the as attribute is present then its value must be an ItemTypeXP30. If the attribute is omitted this is equivalent to specifying as="item()".

So the syntax requires a SequenceType, and the prose then restricts this to an ItemType.

This seems a little clumsy; it would be better to use ItemType in the proforma, and add this to the list of attribute types enumerated in section 2.2 Notation.

The error handling should be very similar to other attributes that expect a SequenceType, for example xsl:variable/@as

The rules for validity of a SequenceType include

(a) basic grammatical correctness
(b) QName validity (prefixes in scope)
(c) type names are present in the in-scope schema definitions
(d) certain constructs make no sense unless the processor is schema-aware.

For (a) I would expect
[ERR XTSE0020] It is a static error if an attribute (other than an attribute written using curly brackets in a position where an attribute value template is permitted) contains a value that is not one of the permitted values for that attribute

For (b) I would use
[ERR XTSE0280] In the case of a prefixed lexical QName used as the value (or as part of the value) of an attribute in the stylesheet, or appearing within an XPath expression in the stylesheet, it is a static error if the defining element has no namespace node whose name matches the prefix of the lexical QName.

For (c), I don't think there are special rules for other SequenceType-valued attributes, so I would use XTSE0020.

For (d), the rules in 26.2 possibly need extending. I note, for example, that there appears to be no error condition allowing a non-schema-aware processor to reject <xsl:mode typed="yes">. I would be inclined to extend XTSE1660 as follows:

[ERR XTSE1660] A non-schema-aware processor must signal a static error if a package includes an [xsl:]type attribute; or an [xsl:]validation or [xsl:]default-validation attribute with a value other than strip, preserve, or lax; or an xsl:mode element with @typed equal to "yes" or "strict"; or an "as" attribute whose value is a SequenceType that can only match nodes with a type annotation other than xs:untyped or xs:untypedAtomic (for example, as="element(*, xs:integer)").

The WG accepted MK's proposed solution.