7529 2009-09-07 14:34:08 +0000 [XQuery] General comparison argument conversion with xs:untypedAtomic and xs:NOTATION 2009-10-20 17:01:08 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 1.0 2nd Edition Recommendation PC Windows NT RESOLVED INVALID P2 normal --- 1 oliver jonathan.robie public-qt-comments oldest_to_newest 26910 0 oliver 2009-09-07 14:34:08 +0000 The errata XQ.E18 defines argument promotion for untyped atomic values in general comparisons as follows: If T is a numeric type or is derived from a numeric type, then V is cast to xs:double. If T is xs:dayTimeDuration or is derived from xs:dayTimeDuration, then V is cast to xs:dayTimeDuration. If T is xs:yearMonthDuration or is derived from xs:yearMonthDuration, then V is cast to xs:yearMonthDuration. In all other cases, V is cast to the primitive base type of T. This definition is a bit wooly when it comes to comparing an xs:untypedAtomic value with an xs:NOTATION value. xs:NOTATION is clearly the primitive base type of xs:NOTATION. Should this raise a type error, or should a value be created with the abstract type xs:NOTATION for purposes of the comparison? Nowhere in the specification is it defined what it means to cast to an abstract type, this issue is carefully avoided every time a cast is used otherwise. This bug also affects XPath 2. 26911 1 oliver 2009-09-07 14:34:59 +0000 > xs:NOTATION is clearly the primitive base type of xs:NOTATION. I meant to say here, xs:NOTATION is clearly the primitive base type of a value of type xs:NOTATION. 26912 2 oliver 2009-09-07 14:42:16 +0000 Since comparing an xs:QName with an xs:untypedAtomic raises an XPTY0004 type error, I would expect the same to happen with xs:NOTATION, although the specification really should make this explicit. 28590 3 oliver 2009-10-20 16:43:55 +0000 18.1 (17.1 in 1.0) states: [XML Schema Part 2: Datatypes Second Edition] defines xs:NOTATION as an abstract type. Thus, casting to xs:NOTATION from any other type including xs:NOTATION is not permitted and raises [err:XPST0080]XP. However, casting from one subtype of xs:NOTATION to another subtype of xs:NOTATION is permitted. This does apply in this case and it is clear that the expression should raise XPST0080. I have marked the bug report INVALID. 28592 4 oliver 2009-10-20 17:01:08 +0000 This XPST0800 error is a static error, and I believe only applies to cast/castable expressions. It is defined as (http://www.w3.org/TR/xpath20/#ERRXPST0080) as: It is a static error if the target type of a cast or castable expression is xs:NOTATION or xs:anyAtomicType. F&O (1.1) 18.1.1 states: Casting is permitted from xs:string literals to xs:QName and types derived from xs:NOTATION. If the argument to such a cast is computed dynamically, [err:XPTY0004]XP is raised if the value is of any type other than xs:QName or xs:NOTATION (including the case where it is an xs:string). The process is described in more detail in 17.2 Constructor Functions for xs:QName and xs:NOTATION. So I now think XPTY0004 is the right error. It is not clear from the text that the paragraph in 18.1 only applies to cast and castable as expressions.