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