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

> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of yamuna prakash
> Sent: Monday, October 06, 2003 6:25 AM
> To: julian.reschke@gmx.de; www-webdav-dasl@w3.org
> 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 collection
> 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 would
> 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.

Sure.

> 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
the
> response would be in the above scenario.

Yes.

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
to
> 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
'prop1'
> on 'col2' (col1 and col2 are different URIS). However given the fact that
> properties are in a flat namespace and property names are universally
unique
> 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 properties
with identical names and different types in the same scope) -- this issue is
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 www.dasl.org with a scope of http://www.cnn.com).

Julian



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

Received on Monday, 6 October 2003 03:41:00 UTC