Subject: FW: RE: Future direction for DASL/WebDAV SEARCH

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 3 Oct 2003 15:44:39 -0700

Accidentally caught by the spam filter.

- Jim

-----Original Message-----
From: Kevin Wiggen [mailto:[email-masked]]
Sent: Thursday, October 02, 2003 7:39 PM
To: Jim Whitehead; WebDAV; [email-masked]
Subject: [Moderator Action] RE: Future direction for DASL/WebDAV SEARCH

I agree with Jim that the current implementation is very useful in its
current form.  Although there are holes, it is very useful in many
circumstances.  

Given the lack of work going on with this specification, I do not
believe it useful to put some of the "nice to haves" into the
specification now.  There are a number of production systems being used
today without extra features and I believe we should get the work that
is done issued.

I believe we should make this a Proposed standard.

Julian recently wrote that the remaining issues are marshaling and data
typing.

Let's go through the marshaling on this list quickly and get consensus
on those issues.  

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.

I believe a NEW WG can be made to improve on DASL and bring together web
searching, XPath, data typing etc. for not only Webdav resources but
others as well (can you say web service for Google, Verity, etc).

Kevin Wiggen
Xythos Software Inc.

-----Original Message-----
From: Jim Whitehead [mailto:[email-masked]] 
Sent: Monday, September 29, 2003 2:00 PM
To: WebDAV; [email-masked]
Subject: Future direction for DASL/WebDAV SEARCH

All,

I'm interested in people's thoughts on how to proceed with the DASL
specification.

The DASL protocol, in its current form, has a great deal of effort and
maturity. Its well-specified enough such that there are multiple
interoperating implementations. Though it has limitations, it is very
useful
in its current form. This argues for issuing the current specification
as an
RFC, either standards track or experimental.

On the other hand, there are many features that would be nice to have
added.
Some imply significant changes, as with proper sort ordering and
comparator
evaluation of dead properties which implies adding a type system to
WebDAV
properties. As well, handling XML querying intelligently would be a
plus,
but would also require much work. This argues for creating a new working
group to address further development of DASL. It might make sense to
involve
a wider audience, perhaps by including people in the W3C community
interested in protocols for XML searching.

So, there are a couple of choices:

a) Do we issue current specification more-or-less as-is?
   i) as Proposed
   ii) as Experimental
b) Do we continue development of the specification?
   i) within WebDAV community only
     - as new WG? in DAV WG?
   ii) expand community to address Web/XML searching in general, not
necessarily focused on WebdAV
     - as IETF WG? as W3C activity?

There are probably other choices as well.

Let me know what your thoughts are.

Thanks!

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 4 Oct 2003 11:58:50 +0200

> current form.  Although there are holes, it is very useful in many

Yes. However, where these holes affect the predictability of search results,
we need to close them.

> Given the lack of work going on with this specification, I do not

As a matter of fact, I've seen little progress with any of the WebDAV specs
in the last months. Progress occurs when people decide to spend time to
improve the draft. The SEARCH spec has been (albeit slowly) progressing,
mainly because of feedback from Software AG (Tamino) and the Catacomb
developers. If we can get all interested parties (probably that would
include Xythos and Oracle) to concentrate on the remaining issues, then we
can probably get the spec out within a few weeks.

> today without extra features and I believe we should get the work that

Yes. However I don't think that anybody is doing that. Almost all open
issues aren't about nice-to-have additions but about problems with the
existing functionality (for instance, the missing ability to relaibly query
on non-string typed properties, such as DAV:getcontentlength).

> I believe we should make this a Proposed standard.

...when we've closed these issues.

> Let's go through the marshaling on this list quickly and get consensus

That would be good.

> 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? If
the spec doesn't answer how queries can be made against the basic RFC2518
live properties, there's no point in submitting it. This is currently
covered in section 5.10. The remaining questions are summarized here:
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rf
c.issue.typed-literal>).

> others as well (can you say web service for Google, Verity, etc).

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 6 Oct 2003 10:04:08 -0700

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 6 Oct 2003 19:14:10 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Monday, October 06, 2003 7:04 PM
> To: 'Julian Reschke'; 'WebDAV'; [email-masked]
> Subject: RE: RE: Future direction for DASL/WebDAV SEARCH
>
> ...
>

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

> 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