RE: New requirements draft!

I've given up on search, and am assuming that it will be out of scope for
WEBDAV.  (To repeat my understanding of what search is: it's the ability to
get a list of the resources in a given name space that have properties
matching the search criteria I set out.)

What I want to focus on now is what it would take to satisfy the requirement
to be able to retrieve the properties of a resource.  We've left the
requirement vague enough that we have lots of room for debate.  Here are
some possible interpretations, more or less from weakest to strongest.  

1. If you know the name of a property instance, you can retrieve it.

(Section 2.6.2 GET of the current draft satisfies this.)

2. You can retrieve several properties of a resource at once if you know
their names.

(Section 2.6.5 SEARCH of the current draft satisfies this.)

3. You can retrieve all the properties of a resource, without knowing their
names.

(Although the current draft does not explicitly say that you can do this,
one of the examples in 2.6.2.1 shows this happening in response to "GET
bar;DAV/".  So I assume we expect to satisfy this.)

4a. You can find out the names of all the properties on a resource, in order
to retrieve the particular ones that interest you using 1.  You can find out
which property schemas the resource supports, and retrieve all properties in
a given schema.

(There is no support for 4a that I can see in the current draft.)

4b. You can retrieve the properties of a resource that meet specified
conditions.  This allows you to retrieve properties without knowing their
names in advance.  You may want to know the author of a resource, but not
know the spelling of the property name that will get it for you, so you ask
to retrieve "*author*".

(Section 2.6.5 of the current draft satisfies this, but I hear you saying
that you want to change the definition of Match-String in 2.6.5.2.6, so that
it will no longer be possible to use "*" or "?" to give approximate names of
the properties you want to retrieve.)



My view is that there absolutely has to be some way to retrieve the
properties of a resource without knowing ahead of time what all their names
are.  If we satisfy 1 - 3 above, we have that in sort of a clunky way.  

I think we would be better off if we supported 4a or 4b as well, so that
people weren't forced to retrieve all the property names and values, and
sort through them on the client side, just to get the value of a property
whose exact name they don't know.  You can imagine applications wanting to
be able to get the name of each property on a resource, together with a
human-readable display name, in order to show the list to users and let them
select what they want to see.

--Judy

At 01:39 PM 7/31/97 PDT, Yaron Goland wrote:
>My concern is that this will require us to allow for wild card matching.
>I believe that FINDPROPS should just accept a list of property names
>which should then be retrieved. The connotations of the word "search"
>worry me.
>		Yaron
>
>> -----Original Message-----
>> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
>> Sent:	Thursday, July 31, 1997 11:59 AM
>> To:	Yaron Goland
>> Cc:	'ejw@ics.uci.edu'; 'WEBDAV Mailing List'
>> Subject:	RE: New requirements draft!
>> 
>> I think what Jim advocates, "searching properties and links on a
>> single
>> resource," is what the spec provides now in the SEARCH method -- that
>> is, it
>> is really GETPROPS.  I agree with Jim that we should keep this in.  I
>> see
>> you and Jim agreeing that we should rule a true search capability out
>> of scope.
>> 
>> --Judy
>> 
>> At 11:19 AM 7/31/97 PDT, Yaron Goland wrote:
>> >So Spake Jim:
>> >>Based on this, and on the current wording of our charter, I feel
>> that 
>> >>searching properties and links on a single resource is OK, but 
>> >>across-resource searching is beyond our scope, and is not likely not
>> >become 
>> >>part of our scope.  I feel the requirements should reflect this.
>> >
>> >I disagree. Given that search is going to be dealt with, potentially
>> in
>> >another group, I do not believe we have the right to foist upon the
>> >world a broken search which becomes obsolete legacy code before the
>> spec
>> >is even finished. All we are doing is forcing implementers to support
>> a
>> >search system that will most likely have nothing in common with the
>> >search that will be specified by the IETF HTTP SEARCH group. I
>> believe
>> >the search requirement should be completely removed from the
>> >requirements document.
>> >
>> >			Yaron
>> >
>> >
Name:			Judith A. Slein
E-Mail:			slein@wrc.xerox.com
Internal Phone:  	8*222-5169
External Phone:		(716) 422-5169
Fax:			(716) 265-7133
MailStop:		105-50C

Received on Friday, 1 August 1997 11:00:33 UTC