RE: Proposed resolution for typing issue

Hi,

agree with <typed-literal/>.

regards,
Martin

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Freitag, 10. Januar 2003 17:09
To: www-webdav-dasl@w3.org
Subject: Proposed resolution for typing issue



Hi,

(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
exceptions:

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

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
DAV:boolean-literal

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

	<gt><prop><xyz:published></prop><typed-literal
xsi:type="xs:string">2003-01-10T17:00:00Z</typed-literal></gt>

would always do a string comparison,

	<gt><prop><xyz:published></prop><typed-literal
xsi:type="xs:dateTime">2003-01-10T17:00:00Z</typed-literal></gt>

would do a date comparison and

	<gt><prop><xyz:published></prop><typed-literal
xsi:type="xs:foobar">2003-01-10T17:00:00Z</typed-literal></gt>

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,


Julian



[1]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rf
c.issue.DB2/DB7>
[2]
<http://lists.w3.org/Archives/Public/www-webdav-dasl/2002OctDec/0010.html>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 13 January 2003 04:18:17 UTC