[Bug 5223] [XPath] Casting rules in 3.5.2 General Comparisons (editorial)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5223





------- Comment #3 from hrennau@yahoo.de  2007-10-28 23:09 -------
(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.

Received on Sunday, 28 October 2007 23:09:55 UTC