I think "A is an instance of T" definitely includes the case where A is an instance of a subtype of T. I haven't looked to see whether we say that clearly anywhere, but it is undoubtedly the intent.

The interesting thing about your example is that it sheds new light on the phrase "is cast to the dynamic type of the other value". I had always assumed that it was intended that one should cast to the primitive type of the other value, that is, in your example, to cast to xs:string. In fact it never occurred to me that casting to xs:Name could give a different result for the comparison, but your example clearly shows that because of whitespace normalization, it can.

I find it hard to believe that we really intended to require casting to the derived type, because that would cause a large number of errors in places where a false result is surely more reasonable. Also, instead of optimization using indexes or hash tables being difficult, it becomes virtually impossible. It would also defy expectations on substitutability: if a developer writes //a[.=1000] in the knowledge and belief that a is typed as xs:int, it's unreasonable that this should fail at run-time because someone has created a subtype in which a is an xs:byte.

Michael Kay

Reassigned to XPath.

I realized that my rationale in comment #1 was OK in principle, but flawed in the detail. Here is a better example.

Consider the following function

<xsl:function name="x" as="xs:boolean">
  <xsl:param name="y" as="xs:integer"/>
  <xsl:sequence select="exists($input//a[.=$y])"/>
</xsl:function>

where $input is untyped, and it is known that the <a> elements have values whose lexical form makes them castable to integer.

Now it seems entirely unreasonable to me that this function should cause a dynamic error when someone calls it supplying a value of type xs:negativeInteger, merely because casting one of the <a> values to xs:negativeInteger fails. The writer of the function should not have to defend against that possibility.

Michael Kay

(In reply to comment #2)

It took me some time to fully understand the implications of your remarks! We must pay attention to the particular situation when one operand is a formal parameter, which implies: the query writer has no possibility whatsoever to know *exactly* which subtype of the formal parameter type has been provided by the function call (unless he himself wrote the call, of course).

The "right" to provide any subtype of the formal parameter type is really a vital aspect of function call semantics! This implies a general rule, pertaining to the semantics of any expression (excepting sequence-type related expressions like "typeswitch"): the semantics should warrant that changing any subexpression's type annotation to a derived type does not affect the expression's evaluation result. (In a P.S. I try to formulate this rule more formally.)

So your remarks reveal that the present semantics of general comparisons should be changed indeed because they constitute a conceptual bug - not less. (Although practical consequences will be very rare, because present rules a) and b) exclude any trouble as long as the operand compared with the untypedAtomic operand is any numeric type, or a string-derived type.) Here comes a proposal for new rules, which should replace "3.5.2 General Comparisons, rules a) to c):

<proposedNewText>
(a) If both atomic values are instances of xs:untypedAtomic, then the values are cast to the type xs:string.
(b) If exactly one of the atomic values is an instance of xs:untypedAtomic, it is cast to a type depending on the other value's dynamic type T according to the following rules, in which V denotes the value to be cast:
(b1) If T is an instance of a numeric type, V is cast to xs:double
(b2) If T is an instance of xs:dayTimeDuration, V is cast to xs:dayTimeDuration
(b3) If T is an instance of xs:yearMonthDuration, V is cast to xs:yearMonthDuration
(b4) In all other cases, V is cast to the primitive base type of T

Note:
The special treatment of the duration types is required to avoid errors that may arise when comparing the primitive type xs:duration with any duration type.
</proposedNewText>

Finally, one question concerning the rule: 
<quote>
If a cast operation called for by these rules is not successful, a dynamic error is raised.
</quote>

Might we not completely drop this rule? It constitutes a permanent threat to queries' runtime safety, and what does it protect, which quality does it assert? It seems quite natural to discard any value pair where the cast is not possible as simply not having the required magnitude relationship.

With kind regards -
Hans-Juergen Rennau


P.S.
An attempt at a formal rule to be observed when defining expression semantics in order to protect the "right" of a function caller to provide a formal parameter's subtype.

<rule>
Consider an expression E containing a subexpression U which has the value V of type T. Let E neither contain any type-related subexpression (like typeswitch) nor explicitly refer to any type S that is a subtype of T (like "let $x as S := ..."). For any value V1 from the value space of T let V2 be a value obtained by replacing the type annotation of V1 by a subtype of T. Then XPath expression semantics SHOULD guarantee the following rules, where E(V) denotes the value of E, as dependent on the value V of subexpression U:
- if E(V1) raises an error, E(V2) raises an error
- if E(V1) evaluates to a value V3, E(V2) evaluates to a value V4 which can be obtained from V3 by replacing the type annotation by a subtype.
</rule>

In particular, if a certain value V of the subexpression raises no error, submitting the same value with a subtyped type annotation should also raise no error. And this requirement is exactly what the present rules of 3.5.2 do not meet.

P.P.S Privetik ot zheni i Marini.

Thanks for your comment - your proposed reformulation of the type conversion rule seems very precise and (speaking personally of course) I favour it.

We had a lot of debates about the "fail vs. return false" question. On the whole I was personally inclined to favour the "return false" approach. In fact this semantic is the one that was eventually adopted for some analogous cases including the functions distinct-values(), index-of(), and deep-equal() (and also for key() in XSLT). It's also (more-or-less) the semantics we adopted for pattern matching in XSLT: a failure during attempted matching is treated as no-match.

Although I would have preferred the "return false" behaviour, I don't think there is any rationale that would justify a change to the spec at this stage. However, there is some latitude under the "errors an optimization" rules.

Arguably a conformant implementation could exploit the "errors and optimization" rules to deliver false for the general comparison "a"=3. In section 2.3.4 we discuss the example //product[id = 47]. We say "if an implementation can find (for example, by using an index) the product element-nodes that have an id child with the value 47, it is allowed to return these nodes as the result of the path expression, without searching for another product node that would raise an error because it has an id child whose value is not an integer." I think this includes the case where the set of product elements with id=47 is empty; in this case we can return an empty sequence without testing that all id's are numeric. That's equivalent to returning false rather than an error from the general comparison.

There is of course one big disadvantage to returning false in such cases - it makes it quite hard for the user who has made a genuine mistake (like writing id=47 instead of id='47') to work out what has gone wrong. This I think is the reason the spec is written as it is.

Michael Kay

(Discussed on 2007-10-30. No clear consensus on what the original intention of the WG was - some thought we intended the untypedAtomic value to be cast to the primitive type, some that we intended it to be cast to the specific type, others that we never gave the question any thought... Will come back to it.)

This bug report was discussed by the working group on 26 Feb 2008. The group decided to accept the changes labeled as <proposedNewText> in Comment #3 and to make no other changes. Hans-Juergen, if this resolution is acceptable to you, please change the status of this bug to "Closed".
Regards,
Don Chamberlin (for the Query and XSL working groups)