RE: ACTION A-617-01 Jonathan to bring discussion of bug 29119 to the mailing list

> 
> > We don’t allow it because there is a use case, we allow it because there is
> no reason not to.
> > We don’t disallow multiplication by zero just because we can’t see why
> > anyone would want to do it. Orthogonality drives the design here: no
> unnecessary restrictions.
> 
> We disallow it for variable bindings (type error), but allow it for all other uses
> of sequence type.
> 
> It's too late in the game to convince me to change this, but I think it would be
> more orthogonal to either make it a type error wherever it is used as a
> sequence type, since it can never match an instance, or to allow it in all cases.
> I don't think the status quo is badly wrong, but if we had caught this earlier, I
> think we could have improved it.
> 

Since present processors either raise a static error on assignment (even if never used) or a dynamic error when such variable is accessed, any change away from this will have the effect that existing error scenarios will now compile, but still raise on use. So there is no backwards compatibility issue *if* we were to change this.

It is interesting to see that:

a) Does not throw, unless used:
<xsl:variable name="t" select="error()" />

b) Warning that xs:anyAtomicType cannot be cast to xs:error unless it is an empty sequence, throws FOER0000 when used:
<xsl:variable name="t" select="error()" as="xs:error" />

c) Same as (b), the warning ignores the "*", throws FOER0000 when used:
<xsl:variable name="t" select="error()" as="xs:error*" />

d) No error when declared, no error when accessed:
<xsl:variable name="t" select=" ()" as="xs:error" />

e) Static error when declared, (other procs, error when accessed):
<xsl:variable name="t" select=" 1" as="xs:error" />

While the above is XSLT, I would assume the same rules apply to let $t as xs:error... etc. I think, in the spirit of the spec, most of the above behaves as one would expect, except imo (d), as an error can be cast to an empty sequence, but an empty sequence cannot be cast to an xs:error.

I like the way it was worded in XQuery 1.0: "However, the fn:error() function must not be evaluated during the static analysis phase.", which seems somewhat appropriate, apart that, as Michael Kay mentioned, it is not orthogonal to treat xs:error differently.

On the other hand, I think that, from an XSD standpoint, every type has xs:error as subtype, which to me seems to imply that "test" castable as xs:error should return true, "test" instance of xs:error should return false, "test" cast as xs:error should succeed (type promotion), but then fail on use.

I think that is, in another way, also an orthogonal approach (but too late for such a big change, though I don't think there will be backward compatibility issues).

Cheers,
Abel

Received on Tuesday, 29 September 2015 12:08:52 UTC