This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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()
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.
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]."
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.
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.
I have raised bug #29192 against the XPath and XQuery specs: their non-normative summary of the casting rules is incomplete.
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.
Thanks, closing.