RE: SEARCH for displayname

RE: SEARCH for displaynameI'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 -- 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]
  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]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