This requirement arises because there are various functions in XSLT, such as key() and format-number(), which take a lexical QName as an argument, and we have been considering how to allow them to take a value of type xs:QName instead. We want to do this for a number of reasons, one of which is the introduction of an xsl:evaluate instruction to allow dynamic construction of XPath expressions: it is desirable that such expressions should have no dependencies on the in-scope namespace prefixes. We discussed this in the XSL WG on 2009-10-08 and I am raising the requirement here as a result of an action from that meeting.

We could change these functions to declare the argument as xs:anyAtomicType, but that reduces type safety unnecessarily. The prefered solution is to declare the type as a union of xs:string and xs:QName.

This is of course a general requirement for user applications, it is not specific to these functions. It arises for two reasons: (a) users want to define a function to accept arguments of more than one type (as here), or (b) users have types defined in their schema as union types, and want to manipulate values of these types using function calls. For example, I have seen schemas that contain a type defined as a union of xs:date and xs:gYearMonth, and it would be convenient to write functions that accept instances of that union type.

The general idea is that it should be possible in a function signature to declare the required type of an argument as being a union type, and the supplied value then matches this type if it is an instance of one of the member types of the union.

To avoid complications, it is proposed to restrict this to "basic unions", defined as a simple type of variety union whose base type is xs:anySimpleType and whose member types are all either atomic or (in XSD 1.1 only) basic union types. That is, it excludes unions derived by restriction from other unions (for which the substitutability rules are complex, and buggy in XSD 1.0).

I would propose that we only allow use a named union type defined in the schema. It would be possible to define SequenceType syntax to define an inline union type, but this is probably overkill. XSLT already allows the definition of types locally to a stylesheet by means of an inline schema document.

Sequence type matching works if the supplied value after atomization is an instance of one of the member types of the union (transitive membership in the case of XSD 1.1). If an untypedAtomic value is supplied, then it is converted to the union type by a process analogous to schema validation (try each of the member types in turn.) 

Static typing works in the obvious way, and is not really different from the current rules for types element(*, U) and attribute(*, U) where U is a union type, which we already allow.