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: Fri, 15 Feb 2008 14:05:34 +0100
Message-ID: <47B58E1E.2060102@gmx.de>
To: Javier Godoy <rjgodoy@fich.unl.edu.ar>
CC: www-webdav-dasl@w3.org

Javier Godoy wrote:
> Excuse me, I should have written "literal" instead of "property". So my
> question is: what happens if the *literal* can not be cast to the specified
> datatype?:
>> if the DAV:typed-value specified in the query can not be converted to the
>> desired type, it probably would be good to reject the query,
> I agree. Should this behaviour be RECOMMENDED?


Currently we say

"A server MUST reject a request with an unknown type."

How about adding:

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

I don't believe it makes sense to reject a specific 4xx code here. In 
theory most of the spec could be rewritten to use RFC3253/3744 
pre/postcondition terminology, but it would be a lot of work, and would 
not reflect what's actually implemented?

>> as in
>> <lt xmlns="DAV:"
>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>   xmlns:xs="http://www.w3.org/2001/XMLSchema">
>>   <prop><edits xmlns="http://ns.example.org"/></prop>
>>   <typed-literal xsi:type="xs:integer">foobar</typed-literal>
>> </lt>
>> Did you mean that case?
> Yes, and about DAV:literal too, because Section 5.10 says [[
>  when operand for a comparison with a property for which the type is known,
> it MAY be treated according to this type
> ]]
> Suppose the type of the "edits" property is xs:integer.
> If the server ignores its type, the following expression is valid, and it
> evaluates to false because  "foobar" may not be a value of e:edits, if the
> comparison is performed as if the property were xs:string (default
> behaviour).
> <eq xmlns="DAV:" xmlns:e="http://ns.example.org">
>   <prop><e:edits/></prop>
>   <literal>foobar</literal>
> </eq>
> On the other hand, if the server knows e:edits is xs:integer, and it cast
> the literal as xs:integer, the expression will not be not valid and there
> will be a casting error (as in the typed-literal example above).
> Note that
> <typed-literal xsi:type="xs:integer">foobar</typed-literal>
> is likely a client's fault (e.g., it did not validate the literal against
> the specified datatype)


> In the DAV:literal case, whether the error is a fatal one or it is silently
> ignored, depends on how the server handles DAV:literal for that property.
> My point of view is that, since the client would have used 
> DAV:typed-literal
> if it wanted to force casting, the server MAY invalidate the query, or it
> MAY fail as in the typed-literal case...
> Does this make sense?

5.10 currently says:

"In comparisons, the contents of DAV:literal SHOULD be treated as 
string, with the following exceptions:

- when operand for a comparison with a DAV:getcontentlength property, it 
SHOULD be treated as an integer value (the behavior for non-integer 
values is undefined),
- when operand for a comparison with a DAV:creationdate or 
DAV:getlastmodified property, it SHOULD be treated as a date value in 
the ISO-8601 subset defined for the DAV:creationdate property 
([RFC4918], Section 15.1).
- when operand for a comparison with a property for which the type is 
known, it MAY be treated according to this type."

The second case probably should be aligned with the first one (-> 
undefined). I think we say "undefined" because servers were known to 
behave differently, and it didn't seem important to mandate a consistent 
behavior for broken queries.

As you noticed, the third case is special as it's outside the client's 
control. Thus, the query should not be rejected, 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?

BR, Julian
Received on Friday, 15 February 2008 13:05:58 UTC

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