RE: SEARCH by last path segment, Was: SEARCH for displayname

A new property with the value of the last path segment is useful in more
than just WHERE and SELECT.  It's also useful in ORDERBY and in some REPORT
types, and in general PROPFIND results.  If the server is capable of using
this information in the proposed exclude/include syntax, then it should be
equally capable of using the information in a property syntax.
 
I've heard the argument that this isn't a "real" resource property in that
different URLs to the same resource have different values for this property.
But it's no less feasible than other properties which the server may
calculate based on location/URL, possibly 'supported-live-property-set' or
'supported-method-set'.  E.g. I might not allow VERSION-CONTROL in some
hierarchies of my server and calculate whether to include it in
'supported-method-set' based on the first-path-segment.
 
Lisa

-----Original Message-----
From: www-webdav-dasl-request@w3.org [mailto:www-webdav-dasl-request@w3.org]
On Behalf Of Wallmer, Martin
Sent: Tuesday, November 18, 2003 1:49 AM
To: 'Julian Reschke'; Kevin Wiggen
Cc: Wallmer, Martin; www-webdav-dasl@w3.org
Subject: RE: SEARCH by last path segment, Was: SEARCH for displayname



Hi, 

another point is: when you have a property <last-pathsegment> which you can
use in <WHERE>, you surely might ask for it in <SELECT>. But definetly there
exists no property <last-pathsegment> for a resource. 

Regards, 
Martin 

-----Original Message----- 
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Dienstag, 18. November 2003 09:40 
To: Kevin Wiggen 
Cc: Wallmer, Martin; www-webdav-dasl@w3.org 
Subject: Re: SEARCH by last path segment, Was: SEARCH for displayname 



Kevin Wiggen wrote: 
>  
> 
> Martin, 
> 
>  
> 
> I take it you do not agree that adding this to the WHERE segment is not 
> more powerful?  It will definitely clear up these types of questions.  
> If you don’t want to put it in the WHERE (where it could be AND/OR/ETC 
> with other requirements as well) why not use some sort of nested 
> structure with <d:lastsegment> and allow <d:and> <d:or> <d:not> etc to 
> be used.  Then you have ½  the power I am talking about, at least you 
> can make the search for ANY type of last segment even though you won’t 
> be able to make sure that they conform to certain other where segments 
> in the same DASL query. 
> 
>  
> 
> I find it interesting we argued for multiple scopes because we want the 
> server to do the consolidation of different SCOPES, but are ignoring the 
> possibility that we might want different WHERE segments for different 
> <d:lastsegment> (%.pdf between a certain size and %.doc between a 
> certain size.) and make the server again do the consolidation. 

Two thoughts here: 

- The *preferred* way to search for document types is putting conditions 
on DAV:getcontenttype. Keep in mind that relying on file name extensions 
is a very bad practice (for instant consult the W3's Web Architecture 
Document). 

- Moving the condition into the <where> condition makes the definition 
easy, but may make the *implementation* extremely hard. Keep in mind 
that the we distinguish between the resources (which have a set of 
queryable properties) and the URIs mapped to them (with the BIND model, 
the set of URIs is a function of the collections having bindings to 
them). A server that implements a storage system with this distinction 
will usually *first* determine the set of matching objects and only then 
  construct the set of URIs pointing to these objects. 

Regards, Julian 


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