RE: SEARCH for displayname

Somehow the server must calculate the scope, before the internal query takes
place. Couldn't that be a place for the <include> <exclude> filtering?
 
Martin

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Dienstag, 9. September 2003 13:47
To: Wallmer, Martin; www-webdav-dasl@w3.org
Subject: RE: SEARCH for displayname


Here are some concerns making it an extension to the scope:
 
Many servers will actually store resources and their bindings separately.
DAV:basicsearch is a search on properties (and content), thus internally the
server may query for the resources, and only will manufacture URIs for the
resource objects as a final step before reporting the result. If filtering
by names happens *after* internal execution of the query, the maxresults
element cannot be passed to the query.
 
So we really should also consider moving the feature into the query,
defining a new specific operator for it.
 
Julian

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

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, September 08, 2003 3:49 PM
To: Wallmer, Martin; 'Julian Reschke'; www-webdav-dasl@w3.org
Cc: Pill, Juergen; Nevermann, Dr., Peter; Hartmeier, Michael
Subject: RE: SEARCH for displayname


I'm adding it to the issues list for now. Maybe you want to experiment with
a scope element extension and report back to the list if this turns out to
work for you.
 
 
Julian

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

-----Original Message-----
From: Wallmer, Martin [mailto:Martin.Wallmer@softwareag.com]
Sent: Monday, September 08, 2003 3:46 PM
To: 'Julian Reschke'; Wallmer, Martin; www-webdav-dasl@w3.org
Cc: Pill, Juergen; Nevermann, Dr., Peter; Hartmeier, Michael
Subject: RE: SEARCH for displayname



Hi, 

thats correct, however how is the state of that discussion? 

To summarize this issue: 

Using <href> in the where clause is not possible 
Using <displayname> is not sufficient, as it is no "MUST" property 
making 1:1 mapping between <displayname> and <href> is not possible 

Did I miss something? 
I'd like to go into discussion again with this issue. 

Best regards, 
Martin 



-----Original Message----- 
From: Julian Reschke [ mailto:julian.reschke@gmx.de
<mailto:julian.reschke@gmx.de> ] 
Sent: Montag, 8. September 2003 15:15 
To: Wallmer, Martin; www-webdav-dasl@w3.org 
Cc: Pill, Juergen; Nevermann, Dr., Peter; Hartmeier, Michael 
Subject: RE: SEARCH for displayname 


> From: www-webdav-dasl-request@w3.org 
> [ mailto:www-webdav-dasl-request@w3.org
<mailto:www-webdav-dasl-request@w3.org> ]On Behalf Of Wallmer, Martin 
> Sent: Monday, September 08, 2003 12:53 PM 
> To: 'www-webdav-dasl@w3.org' 
> Cc: Pill, Juergen; Nevermann, Dr., Peter; Hartmeier, Michael 
> Subject: SEARCH for displayname 
> 
> 
> Hello, 
> A common usecase for DASL is to search documents with specific names, for 
> example all documents with the ending "doc", or following a certain naming

> pattern (for example chapter*.pdf). 

Known issue, see 
< http://lists.w3.org/Archives/Public/www-webdav-dasl/2002JanMar/0108.html
<http://lists.w3.org/Archives/Public/www-webdav-dasl/2002JanMar/0108.html>
>. 

> Thinking straightforward you would say something like: 
> ... 
> <where> 
>   <like> 
>     <prop> 
>       <displayname/> 
>     </prop> 
>     <literal> 
>       chapter%.pdf 
>     </literal> 
>   </like> 
> </where> 
> ... 
> 
> However, the WebDAV spec says for property "displayname": 
> ------------------- 
> Purpose: 
> Provides a name for the resource that is suitable for presentation to a 
> user. 
> Description: 
> The displayname property SHOULD be defined on all DAV compliant resources.

> If present, the property contains a description of the resource that is 
> suitable for presentation to a user. 
> ------------------- 

In general, this means that 

a) you can't rely on DAV:displayname being present (for instance, it won't 
be on our server or on Apache/moddav unless you previously set it) and 

b) you can't assume that there's any relationship between DAV:displayname 
and the "resource name". 

> Regarding BIND, the server has no chance to maintain a useful 
<displayname> 
> information, as several paths may point to the same resource, for example 
> /myplayground/test.pdf and /handbook/chapter1.pdf could both point to the 

Wrong. If a server uses DAV:displayname to store "a description of the 
resource that is 
suitable for presentation to a user" it's perfectly ok if it doesn't vary on

the request URL. After all, it's a description of the resource, not of the 
URL. 

> same resource. Regarding our usecase, the URL 
> /handbook/chapter1.pdf should 
> be returned, or to speak more abstract, return the URL, where the 
> last path 
> segment matches the searchpattern. 
> Currently it is not possible to pose this kind of query with DASL. I see 3

> options to express this: 
> 1. a new language element in <where> 
> <where> 
>   <lastpathsegment> 
>     <literal> 
>       chapter%.pdf 
>     </literal> 
>   </lastpathsegment> 
> </where> 
> 
> 
> 2. a new live property, for example 
> <where> 
>   <like> 
>     <prop> 
>       <lastpathsegment/> 
>     </prop> 
>     <literal> 
>       chapter%.pdf 
>     </literal> 
>   </like> 
> </where> 
> 3. introduce a new element in <scope> 
>     <d:from xmlns:d="DAV:"> 
>       <d:scope> 
>         <d:href>/handbook/</d:href> 
>         <d:depth>infinity</d:depth> 
>         <d:include>chapter%.doc</d:include> 
>       </d:scope> 
>     </d:from> 
> 
> 
> 
> 1. would affect only DASL. Not clear, if it should match exactly or match 
the pattern. 

Probably we would want "like" matching. 

> 2. would possibly affect the WebDAV spec as well, PROPFIND should return 
this property as well. 

That would introduce a property that varies on the request URL, something I 
really don't like. 

> 3. would affect only DASL. As the last path segment deals with the URI, 
the scope is not a too bad place. 

Sounds reasonable. 

> Any other options? 

We could try to express it as a special operator that matches specific 
values of DAV:parent-set (as defined in the binding spec). However that's 
not really different from option 1). 

I think extending "scope" makes a lot of sense. 

Julian 

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