W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1997

RE: New requirements draft!

From: Yaron Goland <yarong@microsoft.com>
Date: Fri, 8 Aug 1997 12:49:15 -0700
Message-ID: <11352BDEEB92CF119F3F00805F14F4850354E170@RED-44-MSG.dns.microsoft.com>
To: "'Judith Slein'" <slein@wrc.xerox.com>, Yaron Goland <yarong@microsoft.com>
Cc: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>, "'WEBDAV Mailing List'" <w3c-dist-auth@w3.org>
Retrieving Properties without knowing the name of the property's
location on a resource - You use GETPROPS for this, this replaces
SEARCH. GETPROPS accepts a list of property names and returns the value
of those properties on the specified resource. "GET bar;DAV/" is now
officially dead. The server folks were just too disturbed by having
their namespace hijacked, in violation of the general principal that
URLs are opaque, for that to be a sellable idea.

I also looked into allowing for wildcarding on property names but it
turns out that it is unbelievably inefficient on just about every
implementation available. Just about everyone implements properties as a
flat list so wildcarding on names would require a linear search of that
list. This would basically shut down a thread on the server until the
search was done, this has a very serious impact on scalability. There
will be however, a way to say "Give me ALL properties".

What to do when you know a resource has an author but not what kind of
author - If you don't recognize the schema being used on a resource then
you won't be able to meaningfully retrieve properties. Of course you
could come up with super schemas that would performing mappings. So you
could have the foobar schema which provides an "author" property which
is then mapped to Dublin or Z39.50. That way you could go to a resource
and ask for a foobar author property and the resource could
automatically map that to any property on the resource which has roughly
the meaning of author. However this is a schema issue and does not
require any changes to DAV's property mechanisms.

		Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Friday, August 08, 1997 12:19 PM
> To:	Yaron Goland
> Cc:	'Judith Slein'; 'ejw@ics.uci.edu'; 'WEBDAV Mailing List'
> Subject:	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:49:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:43 GMT