- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 9 Sep 2003 15:24:59 +0200
- To: "Wallmer, Martin" <Martin.Wallmer@softwareag.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, <www-webdav-dasl@w3.org>
- Message-ID: <JIEGINCHMLABHJBIGKBCAEIGIGAA.julian.reschke@gmx.de>
RE: SEARCH for displaynameHm.
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:25:56 UTC