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


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


>> 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.


> 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."


"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,

Received on Sunday, 17 February 2008 18:56:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:44 UTC