RE: draft-reschke-webdav-search-05 - a few questions on the draft

Indeed I was mixing issues because my pitch was basically, if basic search 
required that the server be able to handle different property schemas in a 
single scope then the issues that crop up with multiple scopes would be the 

From your mail I gather that this may not be the case.

One of the issues you mention with multiple scopes is the fact that the 
persistence layers maybe different. However if I wonder how this would be 
different from a scenario wherein I had a symbolic link to a resource in a 
different persistence layer. I am assuming this is possible.

I am not sure I follow your comment on the ability to specify any URI as the 
scope but I am speculating that what you had in mind is that since we can 
specify any URI in the scope,  if multiple scopes are supported then these 
scopes may refer to different persistence layers and thus the issues you 
mention that crop up with the server having to talk to multiple persistence 


>From: "Julian Reschke" <>
>To: "yamuna prakash" <>, 
>Subject: RE: draft-reschke-webdav-search-05 - a few questions on the draft
>Date: Mon, 6 Oct 2003 09:40:39 +0200
> > From:
> > []On Behalf Of yamuna prakash
> > Sent: Monday, October 06, 2003 6:25 AM
> > To:;
> > Subject: RE: draft-reschke-webdav-search-05 - a few questions on the
> > draft
> >
> >
> >
> > Julian, thanks for your response.
> >
> > However I do need to understand a few things...
> >
> > Lets say I have a hierarchical collection and lets suppose root 
> > is 'A' and 'A' contains collections 'B', 'C' and 'D'.
> >
> > Lets say collection 'B' has properties 'prop1', 'prop2', 'prop3'.
> >
> > Collection 'C' has properties 'prop1', 'prop2'
> >
> > Collection 'D' has properties 'prop3', 'prop4'.
> >
> > I send a search request with scope as 'A' and depth as infinity what 
> > be the result of such a search?
>That depends on the query :-) But all the resources are certainly in-scope.
> > To be fair the question is open-ended to a certain extent but it is not
> > clear to me from reading the DASL draft as to what the behavior of the
> > server will be in this scenario.
>Could you please be more specific?
>A resource not having a property is a complete valid use-case. If you put a
>condition on a property like that, the expression will evaluate to UNKNOWN
>(therefore the resource will not appear in the result), unless you put in a
>specific OR with "not(is-defined(prop))".
> > As far as I can see this seems to be a valid organization of resources.
> > Based on my understanding of WebDav specification, I can send a PROPFIND
> > request on 'A' without any issues.
> >
> > To me the behavior on multiple scopes should be somewhat similar to what
> > response would be in the above scenario.
>But with multiple scopes, it may be much harder for the server. For
>instance, multiple scopes may be stored in completely separate distinct
>persistence layers, for instance a file system, a database and a remote
>server. In such cases, the server would need to run the query separately
>against each of them, and then do the merging/sorting etc on it's own. As
>DAV:basicsearch is supposed to be a *simple* grammar, there has been
>resistence to require that ability.
> > Given the above statement, my thoughts are that the server already needs
> > handle to a large extent the issues w.r.t to multiple scopes.
>I'm not sure I can follow.
> > I could see potential issues if the say collection 'col1' and 'col2' has
> > properties 'prop1' and 'prop1' on 'col1' is totally different  from
> > on 'col2' (col1 and col2 are different URIS). However given the fact 
> > properties are in a flat namespace and property names are universally
> > identifiers it does not seem to be an issue.
>Well, that's an additional problem, but this one can occur with a single
>scope as well. The spec needs to deal with it in some way.
> > I guess I am missing something here and would appreciate if somebody can
> > enlighten me...
>First of all, you seem to mix different issues:
>- different property "schemas" within the same scope (such as live
>properties only present on a certain subset of resources, or dead 
>with identical names and different types in the same scope) -- this issue 
>valid, but it exists completely independantly of multiple scopes
>- multiple scopes -- keep in mind that a search arbiter doesn't necessarily
>search on the request URI -- scopes can possibly be anywhere (so I could
>submit SEARCH to with a scope of
><green/>bytes GmbH -- -- tel:+492512807760

Contact brides & grooms FREE! 
Only on Register now!

Received on Monday, 6 October 2003 04:48:20 UTC