RE: RE: Future direction for DASL/WebDAV SEARCH

Hi,

treating creationdate as date and getcontentlength as number really seems to
be obvious, our server handles it this way as well. 

However, I agree with Julian to finish datatyping in the DASL spec.

Regards,
Martin

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Montag, 6. Oktober 2003 19:15
To: Lisa Dusseault; 'Julian Reschke'; 'WebDAV'; www-webdav-dasl@w3.org
Subject: RE: RE: Future direction for DASL/WebDAV SEARCH



> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Monday, October 06, 2003 7:04 PM
> To: 'Julian Reschke'; 'WebDAV'; www-webdav-dasl@w3.org
> Subject: RE: RE: Future direction for DASL/WebDAV SEARCH
>
> ...
>
> It's easy.  Let's say a client presents a GUI allowing the user to
> select this kind of search and to select a directory to search on.
> The user can fill in a file size, say 1 MB.
>
>  - Find files larger than [_____] MB  [SEARCH]
>
> The client then issues a SEARCH against that scope with a where
> clause including
>   <gte xmlns="DAV:">
>     <prop><getcontentlength/></prop>
>     <literal>1048576</literal>
>   </gte>
>
> For an example of this kind of GUI implemented as a Web-based UI,
> see Sharemation's search function.  This is an implementation proof
> that DASL is useful without data-typing support in the protocol.
>
> The reason why this works without data-typing support in the protocol
> is because data typing is done first in specifications.  RFC2518
> specifies that the getcontentlength property is an integer, and
> that getlastmodified is a date.  Therefore clients presenting searches
> against known properties have no problems - they know that for searches
> on length the user should only be allowed to enter an integer whereas
> for searches against 'getlastmodified' the user should be allowed to
> select a date to compare.

Well, the only reason why this works is because Sharemation *happens* to
make the assumption that a query against DAV:getcontentlength is meant to be
numeric. Of course this is what common sense dictates, and probably all
other implementations do the same (our's does). However, nothing in the
original spec said anything about that, so clients couldn't really rely on
that behaviour.

This has been fixed in one of the previous drafts, but I think it
illustrates why the spec can't simple be silent on that issue (similar
questions arise with the date-typed properties from RFC2518).

> What data typing doesn't work for, of course, is searches against
> unknown properties -- custom properties, for example.  THat's why
> WFS supports only string compares on dead properties.
>
> The DASL grammar is "incomplete" in that it doesn't contain every
> function we can imagine.  I'd prefer to standardize it that way and
> work on data typing (for both property get/set and DASL) separately.

Of course that's possible. I'd agree with you if this part was completely
unfinished. However, it's almost there (as optional grammar element), so I'd
prefer to get it finished (instead of removing it).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760