Instead of disallowing it, I would say that casting from type T to T should be 
a noop and always be allowed.

I'm with Michael here.  Two suggestions:

Change the sentence in 17.3 that says: "It is always possible to cast a value of
any atomic type to an atomic type from which it is derived, directly or
indirectly, by restriction." to read "It is always possible to cast a value of
any atomic type to the same atomic type or an atomic type from which it is
derived, directly or indirectly, by restriction."

Add a sentence in 17.1 that says "As explained in Casting to Derived Types, it
is always possible to cast an atomic type to the same atomic type."

  
For your information, this is a duplicate of #1825. 
  
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1825  
  
  
  
Cheers,  
Frans  
  

I observe also that the following paragraph in F+O section 5.1

<para>
Constructor functions for xs:QName and types derived from xs:QName and
xs:NOTATION, are constrained to take a xs:string literal as their argument.
(This means that they are actually pseudo-functions: they can always be
evaluated statically). A static error is raised [err:XPST0083]XP if the argument
to a constructor function for xs:QName or a type derived from xs:QName or
xs:NOTATION is not an xs:string literal.
</para>

is misplaced: a reader wanting to know about the semantics of a constructor for
a type derived from xs:NOTATION or xs:QName will be looking in section 5.3, not
in 5.1. It might be best to take this and the following paragraph into a new
section 5.4, referencing it from both 5.1 and 5.3.

At first sight I was sympathetic to Michael Rys' suggestion that casting QName
to QName should be permitted. Given the peculiar nature of QName and NOTATION
constructors as pseudo-functions, however, it would be a lot easier to disallow
the identity cast in this case (by changing the entry in the casting table).
There is one practical use case, namely downcasting from an xs:QName to a type
derived from QName, perhaps because a user-defined function declares an argument
whose required type is this subtype. But I'm not convinced that this use case is
important enough to justify the added complexity.

It occurs to me also that 17.3 (Casting from derived types to parent types) and
17.5 (Casting across the type hierarchy) don't work as stated if the source type
is derived from xs:NOTATION.

Thanks for the reference, Frans. It also seems that you previously raised my
comments about NOTATION in

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1515

which we closed leaving some rough edges.

Michael Kay

I was actioned to identify the textual changes needed to permit casting of QName
to QName and NOTATION to NOTATION. Note that this is not just to allow an
identity cast: it also enables casting up and down the type hierarchy.

F+O

In 5.1, delete the caveat: "except for constructors for xs:QName and types
derived from xs:NOTATION which are identical to "cast as xs:TYPE ". "

In 5.1, delete the following two paragraphs:

"Constructor functions for xs:QName and types derived from xs:QName and
xs:NOTATION, ....

The prefix within the lexical xs:QName ....

replacing them with the paragraph:

"Special rules apply to constructor functions for xs:QName and types derived
from xs:QName and xs:NOTATION: see section 5.4."

In the list of constructors (still in 5.1) replace the entry for xs:QName

* xs:QName($arg as xs:string) as xs:QName
$arg must be a xs:string literal.

with

* xs:QName($arg as xdt:anyAtomicType?) as xs:QName?
(see section 5.4 for special rules)

In section 5.3, add a new second paragraph:

"Special rules apply to constructor functions for types derived from xs:QName
and xs:NOTATION: see section 5.4."

Add a new section 5.4 Constructors for xs:QName and xs:NOTATION:

<new>
Special rules apply to constructor functions for the types xs:QName and
xs:NOTATION, for two reasons:

* The lexical representation of these types uses namespace prefixes, whose
meaning is context-dependent

* Values cannot belong directly to the type xs:NOTATION, only to its subtypes.

These constraints result in the following restrictions:

* Conversion from a string to a value of type xs:QName or xs:NOTATION (including
types derived from these) is permitted only if the string is written as a string
literal. This applies whether the conversion is expressed using a constructor
function or using the "cast as" syntax. Such a conversion can be regarded as a
pseudo-function, which is always evaluated statically. It is also permitted for
these constructors and casts to take a dynamically-supplied argument in the
normal way, but as the casting table (see section 17) indicates, the only
arguments that are supported in this case are values of type xs:QName or
xs:NOTATION respectively.

* There is no constructor function for xs:NOTATION. Constructors are defined,
however, for xs:QName, for types derived from xs:QName, and for types derived
from xs:NOTATION.

When converting from a string, the prefix within the lexical xs:QName supplied
as the argument is resolved to a namespace URI using the statically known
namespaces from the static context. If the lexical xs:QName has no prefix, the
namespace URI of the resulting expanded-QName is the default element/type
namespace from the static context. Components of the static context are
discussed in Section C.1 Static Context ComponentsXP. A static error is raised
[err:FONS0004] if the prefix is not bound in the static context. As described in
Section 2.1 TerminologyDM, the supplied prefix is retained as part of the
expanded-QName value.
</new>

In 17.1.1, delete "A static error is raised [err:XPST0083]XP if the argument to
a cast for xs:QName or a type derived from xs:QName or xs:NOTATION is not an
xs:string literal.", replacing it with "If the argument to such a cast is
computed dynamically, error XPTY0004 is raised if the value is of any type other
than xs:QName or xs:NOTATION respectively (including the case where it is an
xs:string)"

In 17.3, change "It is always possible..." to "Except in the case of
xs:NOTATION, it is always possible..."

In 17.5, add a bullet 2a: "If TT is derived from xs:NOTATION, assume for the
purposes of this rule that casting to xs:NOTATION succeeds."

XPATH BOOK

In section 3.10.2 (casting) change this text in 4a:

"If the target type of a cast expression is xs:QName, or is a type that is
derived from xs:QName or xs:NOTATION, the input expression must be a string
literal; otherwise a static error [err:XPST0083] is raised.

Note:

The reason for this rule is that construction of an instance of one of these
target types requires knowledge about namespace bindings. If the input
expression is not a literal, it might be derived from an input document whose
namespace bindings are different from the statically known namespaces.
" 

to read

<new>If the target type of a cast expression is xs:QName, or is a type that is
derived from xs:QName or xs:NOTATION, and if the primitive type of the input is
not the same as the primitive base type of the target type, then the cast is
permitted only in the case where input expression takes the form of a string
literal. All other cases result in a type error [XPTY0004].

Note:

The reason for this rule is that construction of an instance of one of these
target types from a string requires knowledge about namespace bindings. If the
input expression is not a literal, it might be derived from an input document
whose namespace bindings are different from the statically known namespaces.
</new>

Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.