Re: casting literal values

Julian Reschke wrote:

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

+1


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

I think this work is worthwhile, but, if current implementations are a 
concern, pre/postcondition should not be added at this late stage.


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

+1


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

Not a consistent behaviour, but at least one that either does not make up a 
broken query as if it were successful, or (as the first case does) states 
that some errors may be ignored and the client will not be warned, then it 
should verify the request unless it is comfortable with the possible 
outcome.


> As you noticed, the third case is special as it's outside the client's
> control. Thus, the query should not be rejected,

Agree, unless a precondition were used, but, as you said above, it might be 
inconvenient to do so.

Case A: the server supports DAV:typed-literal. It may be lenient about 
errors when casting DAV:literal, because DAV:typed-literal may be used for 
asserting that no casting error ocurred.
There is no need for rejection in this case, and allowing DAV:literal to be 
casted does not add expression power

Case B: the server does not support DAV:typed-literal, then DAV:literal is 
the only resort, no matter whether the client cares about server-dependent 
casting failures. Casting is useful because of the same reason. Rejection 
would be a problem because automated clients would be confused about the 
rejection cause.


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


Best Regards

Javier

Received on Saturday, 16 February 2008 15:28:02 UTC