- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 8 Sep 2003 15:15:09 +0200
- To: "Wallmer, Martin" <Martin.Wallmer@softwareag.com>, <www-webdav-dasl@w3.org>
- Cc: "Pill, Juergen" <Juergen.Pill@softwareag.com>, "Nevermann, Dr., Peter" <Peter.Nevermann@softwareag.com>, "Hartmeier, Michael" <Michael.Hartmeier@softwareag.com>
> From: 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>. > 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 -- tel:+492512807760
Received on Monday, 8 September 2003 09:15:21 UTC