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: Tue, 9 Sep 2003 15:41:00 +0200
To: "Wallmer, Martin" <Martin.Wallmer@softwareag.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, <www-webdav-dasl@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMEIHIGAA.julian.reschke@gmx.de>
RE: SEARCH for displaynameYes.

What I wanted to say is that both approaches are valid, so I think we
shouldn't rely on a particular one.

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

  -----Original Message-----
  From: Wallmer, Martin [mailto:Martin.Wallmer@softwareag.com]
  Sent: Tuesday, September 09, 2003 3:36 PM
  To: 'Julian Reschke'; Wallmer, Martin; www-webdav-dasl@w3.org
  Subject: RE: SEARCH for displayname


  not necessariliy. Is it necessary to do the filtering *after* doing the
query? It should be possible, to do the filtering at the same time, when you
calc your scope.

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


    Hm.

    It doesn't necessarily need to compute the scope *before* doing the
query, right?

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

      -----Original Message-----
      From: Wallmer, Martin [mailto:Martin.Wallmer@softwareag.com]
      Sent: Tuesday, September 09, 2003 3:22 PM
      To: 'Julian Reschke'; Wallmer, Martin; www-webdav-dasl@w3.org
      Subject: 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 -- 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
Received on Tuesday, 9 September 2003 09:41:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:09 GMT