[Bug 2678] Can't cast xs:QName to xs:QName

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





------- Additional Comments From mike@saxonica.com  2006-01-07 18:17 -------
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.

Received on Saturday, 7 January 2006 18:17:29 UTC