RE: SEARCH for displayname

Hi Kevin,
 
with the introduction of BIND one resource with its singular set of
properties may be reached through several URIs,
http://my.server.com/slide/reports/report-03-2003.pdf
<http://my.server.com/slide/reports/report-03-2003.pdf>  and
http://localhost/myContext/myDrafts/draft.pdf
<http://localhost/myContext/myDrafts/draft.pdf>  might point to the same
physical resource. So you have two "last path segments", report-03-2003.pdf
and draft.pdf. Which one is the one to put into the <lastpathsegment>
property? 
You could somehow put a list of segements into that property, our resource
could have something like:
 
<d:lastpathsegments>
  <d:segment>report-03-2003.pdf<d:/segment> 
  <d:segment>draft.pdf<d:/segment>
</d:lastpathsegments>
 
but then you need a way to access sub-elements of the property. But the
value of a property is a string (ok, may be integer). We currently have no
XML valued properties.
 
So for my opinion the last path segment deals best with the scope. I agree,
it should be an optional feature at the first glance.
 
Best regards,
Martin
 
 
-----Original Message-----
From: Kevin Wiggen [mailto:kwiggen@xythos.com]
Sent: Dienstag, 11. November 2003 19:31
To: Wallmer, Martin; www-webdav-dasl@w3.org
Subject: RE: SEARCH for displayname



 

 

While the approach of adding this lastpathsegment to the scope is valid, I
believe it is limiting and will force DASL parsers to understand extra
elements.  Why don't we simply add a new property <D:lastpathsegment> and
allow DASL to use it in a where clause?  

 

That way you can have the whole arsenal of operators (eq, gt, like, etc) and
OR instead of just AND (what if I want file %.pdf OR %.doc).  You also
shouldn't need to change your DASL parser that much as it needs to already
handle the parsing of the operators.

 

That way your example below turns to:

 

Example: 
<d:searchrequest xmlns:d="DAV:"> 
  <d:basicsearch> 
    <d:select> 
      <d:prop><d:getcontentlength/></d:prop> 
    </d:select> 
    <d:from> 
      <d:scope> 
        <d:href>/container1/</d:href> 
        <d:depth>infinity</d:depth>
      </d:scope> 
    </d:from> 
        <d:where>
             <d:and>
 
<d:like><d:prop><d:lastpathsegment/></d:prop><d:literal>%.pdf</d:literal></d
:like>
 
<d:not><d:like><d:prop><d:lastpathsegment/></d:prop><d:literal>%-2001%.pdf</
d:literal></d:like></d:not>
 
<d:like><d:prop><d:lastpathsegment/></d:prop><d:literal>chapter%.doc</d:lite
ral></d:like>
             </d:and>
         </d:where>
  </d:basicsearch> 
</d:searchrequest> 

(I apologize if my DASL and XML are not perfect; it's been some time since I
looked at exact syntax)

 

I believe that this has great strength in its functionality (very flexible)
and a lower overall cost of creation and support of DASL parsers and
therefore is a good idea.

 

Whether <d:lastpathsegment> makes its way into 2518 is optional I think at
this point.

 

Kevin Wiggen

Xythos Software Inc.

 

-----Original Message-----
From: Wallmer, Martin [mailto:Martin.Wallmer@softwareag.com] 
Sent: Tuesday, November 11, 2003 7:41 AM
To: 'www-webdav-dasl@w3.org'
Subject: SEARCH for displayname

 

Hi, 

I'd like to propose following change to section 5.4 (DAV:from): 

(additions enclosed in <Martin/> 

5.4  DAV:from 
<!ELEMENT scope            (href, depth, include-versions?, 
<Martin>include-lastpathsegment*, exclude-lastpathsegment* </Martin>) > 
<!ELEMENT include-versions EMPTY > 
<Martin> 
<!ELEMENT include-lastpathsegment(#PCDATA)> 
<!ELEMENT exclude-lastpathsegment(#PCDATA)> 
</Martin> 

DAV:from defines the query scope. 
This contains one or more DAV:scope elements. Support for multiple scope 
elements is optional, however servers MUST fail a request specifying 
multiple DAV:scope elements if they can't support it (see section 2.2.2, 
precondition DAV:search-multiple-scope-supported). The scope element 
contains mandatory DAV:href and DAV:depth elements. 

DAV:href indicates the URI to use as a scope. 

When the scope is a collection, if DAV:depth is "0", the search includes 
only the collection. When it is "1", the search includes the (toplevel) 
members of the collection. When it is "infinity", the search includes all 
recursive members of the collection. When the scope is not a collection, the

depth is ignored and the search applies just to the resource itself. 

When the child element DAV:include-versions is present, the search scope 
will include all versions (see [RFC3253], section 2.2.1) of all 
version-controlled resources in scope. Servers that do support versioning 
but do not support the DAV:include-versions feature MUST signal an error if 
it is used in a query. 

<Martin> 
The content of DAV:include-lastpathsegment and DAV:exclude-lastpathsegment 
is a literal pattern same as defined for (@see 5.15.1) Like. 
When one or more child elements DAV:include-lastpathsegment are present, the

scope includes all resources, of which the last pathsegment of the uri 
matches the pattern. 
When one or more child elements DAV:exclude-lastpathsegment are present, the

scope excludes all resources, of which the last pathsegment of the uri 
matches the pattern. 

Example: 
<d:searchrequest xmlns:d="DAV:"> 
  <d:basicsearch> 
    <d:select> 
      <d:prop><d:getcontentlength/></d:prop> 
    </d:select> 
    <d:from> 
      <d:scope> 
        <d:href>/container1/</d:href> 
        <d:depth>infinity</d:depth> 
        <d:include-lastpathsegment>%.pdf</d:include-lastpathsegment> 
        <d:exclude-lastpathsegment>%-2001-%.pdf</d:exclude-lastpathsegment> 
        <d:include-lastpathsegment>chapter%.doc</d:include-lastpathsegment> 
      </d:scope> 
    </d:from> 
  </d:basicsearch> 
</d:searchrequest> 

The scope of this query comprises all resources within or below container1, 
that have the postfix .pdf, all doc files starting with "chapter", but not 
the file (for example) report-2001-july.pdf 

</Martin> 
.... 

The former discussion showed, that it is a common task to somehow filter 
resources according to the "displayname". With BIND, several URI's may point

to the same resource. So a kind of "displayname" is not a property of the 
resource, but of the URI. 
If for technical reasons it would be more suitable for a specific 
implementation to have this information within the query, a preprocessing 
step could transform the SearchQuery document into the desired format. 

 

__________________________ 
Martin Wallmer 
Research & Development 
Software AG    ++49 6151 92 1831 
Uhlandstr. 12 
D 64297 Darmstadt