RE: New requirements draft!

My proposed solution is to drop the SEARCH method and replace it with a
GETPROPS method that takes as its argument an XML body containing a
series of PROP elements which contain the names of the properties to be
retrieved. Please note that these are the abstract names of the
properties, such as http://www.ietf.org/standards/dav/source not the URL
which referes to that property on that specific resource. Thus I can
retrieve a property without having to know the name of the property as
defined on that resource, all I need is the generic name of the
property.

		Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Friday, August 01, 1997 8:04 AM
> To:	Yaron Goland
> Cc:	'Judith Slein'; 'ejw@ics.uci.edu'; 'WEBDAV Mailing List'
> Subject:	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 18:08:22 UTC