Re: casting literal values

Javier Godoy wrote:
> +1, I think it is clear and concise.
> ...

OK, please review at: 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.5.10> 
or below:

"5.10.  DAV:literal

    DAV:literal allows literal values to be placed in an expression.

    White space in literal values is significant in comparisons.  For
    consistency with [RFC4918], clients SHOULD NOT specify the attribute
    "xml:space" (Section 2.10 of [XML]) to override this behavior.

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

    o  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),

    o  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 (see
       [RFC4918], Section 15.1; the behavior of values not in this format
       is undefined).

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

5.11.  DAV:typed-literal (optional)

    There are situations in which a client may want to force a comparison
    not to be string-based (as defined for DAV:literal).  In these cases,
    a typed comparison can be enforced by using DAV:typed-literal
    instead.

    <!ELEMENT typed-literal (#PCDATA)>

    The data type is specified using the xsi:type attribute defined in
    [XS1], Section 2.6.1.  If the type is not specified, it defaults to
    "xs:string".

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

    The comparison evaluates to UNKNOWN if the property value can not be
    cast to the specified datatype (see [XPATHFUNC], Section 17)."





BR, Julian

Received on Monday, 18 February 2008 17:07:14 UTC