29173 2015-10-02 14:56:13 +0000 [QT3TS] xs-error tests expecting XPTY0004 2015-10-14 13:13:49 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3 & XPath 3 Test Suite Candidate Recommendation PC Windows NT CLOSED FIXED P2 normal --- 1 debbie tim debbie mike tim public-qt-comments oldest_to_newest 123451 0 debbie 2015-10-02 14:56:13 +0000 The following tests expect error code XPTY0004, but should the error be FORG0001? xs-error-009 xs:error(xs:untypedAtomic("")) xs-error-010 xs:error("") xs-error-011 xs:error(1.0) xs-error-012 xs:error(1e0) xs-error-013 xs:error(1) xs-error-014 xs:error(1) instance of xs:error xs-error-032 xs:error(1) castable as xs:error xs-error-033 xs:error(1) castable as xs:integer xs-error-039 xs:error(1) cast as xs:error xs-error-043 xs:error(1) instance of xs:error xs-error-045 typeswitch (xs:error(1)) case xs:error return fn:true() default return false() 123452 1 mike 2015-10-02 15:08:26 +0000 Rationale on this: the xs:error function is defined to be equivalent to casting to a union type with no member types. This takes you to 19.3 (casting to union types), which takes you to 19.2.2. This defines the cast in terms of validation. Validation fails, because the value space is empty. Except where otherwise specified, validation failures result in FORG0001. The significance of this is that calling xs:error() produces a dynamic error rather than a type error, which makes it safe to use for deliberate signalling of a dynamic error in a branch of a conditional. Indeed F+O section 18.4 explicitly says that casting to xs:error will always fail with a *dynamic* error. 123453 2 mike 2015-10-02 15:16:37 +0000 The above rationale applies when the supplied value is a string or untypedAtomic. When it is any other type, e.g. integer, the relevant rule is in 19.3.5 casting to a union type: "If none of these conditions applies, the cast fails with a dynamic error [err:FORG0001]." 123657 3 tim 2015-10-12 09:23:15 +0000 Could you please confirm which of the rules under point 5 of 3.18.3 Cast? I can see that (c) cast is supported if the target type is a non-primitive atomic type and the input type is xs:string or xs:untypedAtomic. applies in some of these cases, but not (for example) in xs-error-011. 123658 4 mike 2015-10-12 09:42:50 +0000 XQuery 3.18.3 refers to F+O section 19 as the normative specification, so I tend to largely ignore it. It doesn't seem to handle the case of casting to a union type from a type other than string/untypedAtomic. I'll raise a bug on that. 123660 5 mike 2015-10-12 09:49:13 +0000 I have raised bug #29192 against the XPath and XQuery specs: their non-normative summary of the casting rules is incomplete. 123671 6 tim 2015-10-13 11:51:51 +0000 Test cases updated. BTW, it would be nice to add a dependency other than XSD 1.1 for this, in view of the note: <!-- NOTE: An implementation supporting XSD 1.1 must support xs:error, however it is not an error for an implementation not supporting XSD 1.1 to support xs:error. --> Please mark as CLOSED if you agree with the resolution. Otherwise, REOPEN. 123709 7 debbie 2015-10-14 13:13:49 +0000 Thanks, closing.