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

Proposed resolution for typing issue

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 10 Jan 2003 17:09:00 +0100
To: <www-webdav-dasl@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCOEHEGCAA.julian.reschke@gmx.de>


(see [1] for the actual issue and [2] for previous discussions on the list).

The way DAV:basicsearch currently is defined, searches on non-string typed
properties such as DAV:getcontentlength and DAV:getlastmodified are not
going to work the way the naive user would expect.

For instance, compared as a string a DAV:getcontentlength value of "5" would
be greater than "10", which is clearly not what one would expect :-) So
first of all, we need to clarify syntax for specifying DAV:literals when
querying date-typed or numerical property values:

The contents of DAV:literal should be treated as string, with the following

- when used to compare with a DAV:getcontentlength property, it must be
parsed as integer (the behaviour for non-integer values is undefined).

- when used to compare with either DAV:creationdate or DAV:getlastmodified,
it must be parsed as a date in one of the two formats supported by RFC2518
(either HTTP format or the subset of ISO8601 defined in the appendices).

The next issue to decide is whether we want to allow servers to try to be
smart. Let's consider a server which as a proprietary property
"xyz:published", which is internally persisted as date. Is it legal for the
server to silently parse the DAV:literal to a date value, and then to do
date comparisons? Doing so is probably "convenient", but may harm

I think that it would be smart not to overload DAV:literal. Instead, we
should define alternatives to DAV:literal (which then could conveniently be
discovered using QSD). One approach would be to just define:

	DAV:date-literal (ISO8601 subset), DAV:numeric-literal and

The more extensible approach would be to have a DAV:typed-literal element
which would then carry a type attribute (xsi:type). So


would always do a string comparison,


would do a date comparison and


would fail (because the datatype "xs:foobar" is undefined).

I'd personally prefer the notation based on the xsi:type attribute (because
it's more extensible and fits nicely into the type notation for QSD), but I
could also live with explicit containers for dates, numericals and booleans.

Feedback appreciated,


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 10 January 2003 11:09:36 UTC

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