W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > January to March 2008

Re: casting literal values

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 17 Feb 2008 19:56:21 +0100
Message-ID: <47B88355.10309@gmx.de>
To: Javier Godoy <rjgodoy@fich.unl.edu.ar>
CC: www-webdav-dasl@w3.org

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
Received on Sunday, 17 February 2008 18:56:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:10 GMT