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: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 20 Nov 2003 13:15:00 +0100
Message-ID: <3FBCB044.3060001@gmx.de>
To: www-webdav-dasl@w3.org

Elias Sinderson wrote:

> If order of evaluation doesn't matter, then the following would produce 
> the same results:
> all AND included AND NOT excluded
> all AND NOT excluded AND included
> This, however is clearly not the case as shown below.
> Consider the scenario in which we have a collection, /A, containing 
> resources /A/index.html, and /A/foo.pdf, both authored by Phil A. Novel. 
> Further, let us suppose that we are evaluating a SEARCH request for 
> resources authored by Mr. Novel and which specifies the scope as /A. In 
> this case, the set 'all' (which satisfies the above constraints) is 
> {/A/index.html, /A/foo.pdf}. For the sake of argument, let us assume 
> that the values of the include-lastpathsegment and 
> exclude-lastpathsegment elements are '%.pdf'.
> Order of evaluation is important:
> all AND included AND NOT excluded yields {/A/index.html}.
> all AND NOT excluded AND included yields {/A/index.html, /A/foo.pdf}

I understand "AND" as logical and. Thus both expressions will yield the 
same result, /A/foo.pdf not being included.

Anyway, could you re-test your theory with the notation I used in my 
previous mail?

> Granted, this is a somewhat contrived example (albeit moreso for 
> simplicity than otherwise), but I think it illustrates the idea that 
> order of evaluation is important. The include and exclude sets don't 
> need to be identical for evaluation order to matter, they only need to 
> share some members in common. If you'd like I'll provide another 
> illustrative example that is more realistic.

I think we all agree that evaluation order should not matter. So we need 
to come up with a description which makes that clear.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 20 November 2003 07:15:03 UTC

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