Re: casting literal values

Javier Godoy wrote:
>> "A server SHOULD reject a request if the value provided in
>> DAV:typed-literal can not be cast to the specified type".
> 
> +1

Done.

>> The second case probably should be aligned with the first one (->
>> undefined).
> 
> +1

Done.

>> and the expression
>> evaluate to FALSE or UNKNOWN. As UNKNOWN would have undesirable effects
>> when combined with other expressions, FALSE seems to be right. Would that
>> be ok?
> 
> IMHO, FALSE is right *only* when the operator is DAV:eq. If the literal 
> is not casted, the negated expression (<not><eq> .... ) evaluates as 
> TRUE, which is right too. If the literal were casted and the expression 
> evaluates to FALSE, the result would not depend on the server's behaviour.

Correct.

> However, if the comparison uses other comparison operator (such as 
> DAV:lt) and the literal is not casted, it will evaluate as either TRUE 
> or FALSE according to the property value (xs:string comparison). If the 
> literal is casted and the expression evaluates to FALSE, then NOT 
> <lt>...</lt> evaluates to TRUE, meaning that e:edits is greater or equal 
> than "foobar", when treated as xs:integer... but <gte>...</gte> 
> evaluates as FALSE!
> 
> <lt xmlns="DAV:" xmlns:e="http://ns.example.org">
>   <prop><e:edits/></prop>
>   <literal>foobar</literal>
> </lt>
> 
> This inconsistency seems to indicate that something is wrong with this 
> approach... Instead, the expression should have been evaluated to 
> UNKNOWN, which is consistent with DAV:literal being dependent on the 
> server behavior (although DAV:eq may evaluate to FALSE, since it is 
> harmless).
> 
> Alternatively, the server may cast the literal only if it is possible. 
> If the literal cannot be casted to the property type, then xs:string 
> should be used.
> 
> How is this issue handled by current implementations?

The one I implemented tries to cast, but if it's not possible compares 
string representation. I think that's consistent with the grammar; the 
client did not ask for a typed comparison, after all.

The "MAY do typed comparison" case mainly is for those servers that know 
about property types, but do not support DAV:typed-literal.

So it seems we should change

"when operand for a comparison with a property for which the type is 
known, it MAY be treated according to this type."

to

"when operand for a comparison with a property for which the type is 
known and when compatible with that type, it MAY be treated according to 
this type."

Feedback appreciated,

Julian