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

> 
> I think there are some important differences between xs:error and 0.  
> 
> 0 is a  value. It can be assigned to variables and used in expressions.  If xs:error is the result of any operation, it is an error, not a value that can be used in expressions. 

Eh? xs:error is a type. The result of an expression cannot be a type.

> 
> And if I take your analogy seriously, we should allow division by xs:error. I don't think you are suggesting that.  

Indeed not. I don’t know what it means to divide by a type.

> We allow division by zero because we allow division by a numeric value, and don't want to create lots of special cases.  But xs:error is not a value that can occur.
> 
> The simplest fix really might be to say that xs:error, used as a SequenceType, is always a type error. 

That would be removing a feature.

For example, one can imagine implementing a schema processor by generating XQuery code from the XSD source. It would then be very natural for the code for conditional type assignment, when it encounters the XSD construct

<xs:element name="message" type="messageType">
  <xs:alternative test="@kind='string'" type="messageTypeString"/>
  <xs:alternative test="@kind='base64'" type="messageTypeBase64"/>
  <xs:alternative                       type=“xs:error"/>
</xs:element>

to generate a query along the lines

declare function A($x as messageTypeString) {
  $x
};

declare function B($x as messageTypeBase64) {
  $x
};

declare function C($x as xs:error) {
  $x
};

if (@kind = ‘string’) then A(.)
else if (@kind = ‘base64’) then B(.)
else C(.)

It’s perfectly reasonable to have a type with no instances, and we’ve designed it carefully so it behaves in a completely standard way (exactly like a user-defined type with no instances). It doesn’t need any special rules. §2.5.7 should be saying “it is a consequence of rules defined elsewhere that…”. The last sentence "A variable binding with a type declaration xs:error always raises a type error.” should be changed to “Matching any value against the sequence type xs:error (for example when calling a function or binding a variable) always fails.” 

I would also be inclined to remove the sentence "xs:error offers an alternative way of raising errors, in addition to fn:error.” because it implies some kind of recommendation. Dividing by zero is another alternative way of raising errors, but I don’t think it’s one we would want to recommend.

Michael Kay
Saxonica

Received on Tuesday, 29 September 2015 18:07:31 UTC