W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > October to December 2003

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

From: Wallmer, Martin <Martin.Wallmer@softwareag.com>
Date: Tue, 18 Nov 2003 10:48:30 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106063A9131@daemsg02.software-ag.de>
To: "'Julian Reschke'" <julian.reschke@gmx.de>, Kevin Wiggen <kwiggen@xythos.com>
Cc: "Wallmer, Martin" <Martin.Wallmer@softwareag.com>, www-webdav-dasl@w3.org

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. 


-----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 

- 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
Received on Tuesday, 18 November 2003 04:49:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:43 UTC