RE: RE: Future direction for DASL/WebDAV SEARCH

> 
> > Data Typing.  If the Webdav WG can't get a consensus on 
> this topic in 
> > all these years, I don't think DASL should be held up on 
> it.  In the 
> > last week I have only seen Julian answer this email, so I 
> don't think 
> > a lot of people will work on the data typing just to get 
> DASL done.  
> > Let's simply get what work has been done into an RFC.
> 
> However, without data typing the grammer simply is 
> incomplete. Could you please explain how you're going to 
> query for resources where DAV:getcontentlength is between 
> 1000 and 5000 without somehow introducing a distinction 
> between strings and numbers. And what about queries on dates? 

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.

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.

Lisa

Received on Monday, 6 October 2003 13:03:58 UTC