RE: Issue: JW7 (redirects)

<alan>
My comments are interspersed.
</alan>

Alan Babich

-----Original Message-----
From: Yaron Goland [mailto:yarong@microsoft.com]
Sent: Wednesday, June 16, 1999 3:42 PM
To: 'Babich, Alan'; www-webdav-dasl@w3.org
Subject: RE: Issue: JW7 (redirects)


I suspect I may have missed the point here. Are we discussing getting rid of
the concept of search arbiters (bad idea) or just getting rid of LDAP esque
search redirections (good idea)? If the later than I have already said this
probably isn't a V1 feature and given the solution I provided which allows
the feature to be added later in a 100% backwards compatible way it would
seem a really good idea to rip it out now.

Also, Alan, your comment regarding XYZ is NULL is very disturbing to me. If
DASL can't distinguish between "The property exists and its value is null"
and "The property doesn't exist" then DASL has a very serious hole in its
specification that needs to be immediately repaired.

<alan>
Yaron: First, let me say that the point of my e-mail 
was to recommend that we not use a particular rationale 
to justify (or refute) keeping, adding, or dropping a feature:
I want to keep things simple and make it possible to
implement things efficiently. So, I'm uncomfortable 
with arguments that assume that we could figure out what 
properties are supported by a specified arbiter for a specified
scope, then figure out what role these properties play
in the query, and then decide whether there can
be any possible hits from the query from the arbiter
in the specified scope, then if so ... (do whatever).
<alan>

<alan>
Second, Yaron, let me try to put your mind at ease: There 
are no big holes in the DASL spec. 

One thing you can do in DASL is try to find out what
properties are supported by query schema discovery (QSD).
High end document management systems all have a centralized 
property schema, and presumably you could discover it.
In contrast, low end systems do not necessarily have 
a centralized schema, but we consider them to be an 
important use case for WebDAV. Therefore, QSD is optional 
in DASL. Note that for the case QSD is not supported, 
it would be very expensive to discover what properties are 
supported, because you would have to fetch all the resources
using PROPFIND, asking for all the properties supported 
on each resource, and take the union of all of the 
properties returned over the network.

So, DASL needs a mechanism to deal with the following
situations on a resource-by-resource basis: 
Relative to the current resource under scan, 
a given property in the query condition:
(1) is defined and has a value for the current resource, 
(2) is not defined for (i.e. is not supported at all by)
the current resource, (3) is supported by the current resource, 
but has no value for the current resource
(or, you could think of it as having an empty value 
for the current resource).

Remember, if a property is not supported by a resource, then
PROPFIND returns an error 404 (not found), or maybe 403
(forbidden). If the property is supported by a resource,
you get back something for the property, even if it
doesn't have a value (or you could think of it as having
an empty value).

If you want to test whether or not a property is defined for
(i.e., supported by) the current resource under scan in DASL,
you can use the DAV:isdefined operator in your query condition.

If you want to test whether the property is defined but
has no value (or, you could think of it as having an empty value), 
you can use the DASL equal or the DASL unequal operator, and 
test against a literal with an empty body.

Remember that we use three valued logic (1) to prevent queries
from blowing up, and (2) also to return results that are as intuitive
as possible, both for the case that properties in the query 
condition are not defined for the resource, and for
the case that properties in the query condition are defined
but have no value for the resource.

So, you can query for anything you want to: You can retrieve
(or not retrieve) a resource if any of the following cases
pertain: (1) the property is defined for the resource 
and has a value satisfying some condition, 
(2) the property is defined for the resource but has no value, 
(3) the property is not defined for the resource.

I'm sorry if my "SQL-ish" rendering of the example query and the
way I worded things confused the issue.

I hope this helps out.
</alan>



			Yaron

> -----Original Message-----
> From: Babich, Alan [mailto:ABabich@filenet.com]
> Sent: Mon, June 14, 1999 2:15 PM
> To: www-webdav-dasl@w3.org
> Subject: RE: Issue: JW7 (redirects)
> 
> 
> There is something I'm not comfortable with. Suppose that
> search arbiters tell each other what properties they support
> on what resources as has been hypothesized. That's an interesting 
> issue in and of itself, but, I assume, a solvable problem. 
> 
> Assuming that, suppose you have a query
> 
>     Author != "Joe" OR Amount != 3 OR XYZ IS NULL.
> 
> Any given resource can support one, some, or all of these
> properties. By the rules of standard 3 valued
> logic, you either retrieve the resource or not, depending
> upon whether the property is supported and, if so, what it's
> value for that property is. Fine.
> 
> Here's what I'm not comfortable with: Suppose a search
> arbiter does not support the Amount property at all, 
> but supports the Author property on some of its
> resources. You can get tons of hits for this query
> on such a search arbiter, even though it doesn't support
> one of the properties. 
> 
> Even more interesting, suppose the search arbiter does 
> NOT support the XYZ property on any of its resources.
> Then EVERY resource on that search arbiter would be
> returned by the above query. Seems like such a search
> arbiter ought to be included to me.
> 
> So, the decision of whether to include a search arbiter or 
> not is not as simple as "does the search arbiter support 
> the one and only property of this query" for the one-property 
> simple queries used as examples so far, or even "does the
> search arbiter support ANY of the properties mentioned
> in this query" for queries mentioning multiple properties. 
> I don't think going down this path is a good idea. 
> Let's not go down this path.
> 
> Alan Babich
> 
> -----Original Message-----
> From: Yaron Goland [mailto:yarong@microsoft.com]
> Sent: Friday, June 11, 1999 8:56 PM
> To: 'ejw@ics.uci.edu'; www-webdav-dasl@w3.org
> Subject: RE: Issue: JW7 (redirects)
> 
> 
> The idea is that different search arbiters can provide each other with
> enough information to let them know what kind of data they 
> possess, not
> necessarily the entire index of that data (which would probably be too
> large). For example, the search arbiter might tell other 
> arbiters that it
> supports the "author" property. Thus when you ask your search 
> arbiter for
> all documents written by John Doe the arbiter will 
> immediately return all
> the information it has and point you to other arbiters within 
> your request
> scope which it knows support the author property. You can 
> then execute your
> query on those other arbiters. So if the request scope is my 
> entire company
> then there are a number of arbiters I may need to be talking to.
> 
> Check out
> http://search.ietf.org/internet-drafts/draft-ietf-find-cip-arc
h-02.txt, it
talks about these sorts of query routing concepts.

BTW, as I said in my original letter, I'm not suggesting that we require
redirectable multi-result queries in V1. I'm just saying that the feature is
definitely useful and should be kept on the table, potentially for future
revisions. In fact an easy way to add this later on would be to return a
bunch of extra XML goop in the SEARCH response which specifies which other
search arbiters to talk to. The beauty of this is that V1 DASL clients will
just see search responses and ignore the extra group. V2 DASL clients will
know what to do with the extra goop.

		Yaron

> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@ics.uci.edu]
> Sent: Thu, June 10, 1999 10:44 AM
> To: www-webdav-dasl@w3.org
> Subject: RE: Issue: JW7 (redirects)
> 
> 
> 
> > 2) Also, I don't quite get how an arbiter could *know* that 
> it has only
> > partial  knowledge.  Either it recognizes the scope (which 
> is a URI) or it
> > does not.  (I suppose you could have very smart arbiters 
> that recognize
> > that they don't index certain properties, but know of 
> another than does,
> > but that seems implausible.)
> 
> I've been thinking about how your would configure a search engine to
> properly send you to another arbiter, and I just can't 
> envision how this
> configuration could easily be done.
> 
> So, I'm agreeing with Jim Davis.
> 
> - Jim
>

Received on Thursday, 17 June 1999 21:47:50 UTC