W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 2003

RE: SEARCH for displayname

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>
Message-ID: <JIEGINCHMLABHJBIGKBCOEEOIGAA.julian.reschke@gmx.de>

> 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

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

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


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 8 September 2003 09:15:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:43 UTC