RE: SEARCH for displayname

RE: SEARCH for displaynameHere 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 -- 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 -- 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