RE: New requirements draft!

As long as it's possible to retrieve the properties of a resource without
knowing their names, I'm willing to accept the proposal.  The only way I see
of doing this is "GET bar/DAV/", which according to the example in 2.6.2.1
does return all the property names and values for the resource bar.  I'd
just be happier if the proposal said explicitly that this works.

I'd be still happier, of course, if I could either ask a resource what
properties it has -- getting back a list of property names -- or maybe what
property schemas it has, if we think that properties will generally be
organized into schemas.   Or if I could retrieve properties based on
wildcarded property names.

----------

Your comment below makes me wonder if I really understand how property names
are supposed to work, so let me check . . .

I thought that the name of a property instance was constructed this way:
<URL of the resource it describes> ";DAV/" <URL of the property definition>.

To write a GETPROPS request, I have to know both the name of the resource
being described and the name of the property definition (the abstract
property), which is equivalent to knowing the name of the property instance.

Is this right?

So the kind of case that is worrisome is where I know (or suspect) that a
resource has an author property, but I don't know whether it's the Dublin
Core author property or the MARC author property, or maybe even creator or
composer or photographer or cartographer, depending on what kind of resource
it is.

--Judy

At 03:07 PM 8/1/97 PDT, Yaron Goland wrote:
>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
>
>
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, 8 August 1997 15:15:44 UTC