RE: Clarification of URI vs. Resource

Judith A. Slein
CR&T/ADSTC
jslein@crt.xerox.com
8*222-5169


> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@ics.uci.edu]
> Sent: Friday, November 13, 1998 12:30 PM
> To: Slein, Judith A; WEBDAV WG
> Subject: RE: Clarification of URI vs. Resource
> 
> 
> 
> > Collections are resources, and their members are resources, 
> and membership
> > in a collection has nothing to do with what identifiers are 
> used for the
> > collection or its members.
> 
> OK, but from a protocol standpoint, there is no way to talk 
> about resources
> without using identifiers (URLs).  As a result, I cannot see how to
> meaningfully discuss the membership of a collection without 
> using URLs.
>

It wouldn't mean you couldn't mention URLs, but just that you couldn't say
that URLs are members of collections, or design the protocol so that
anything depends on URL syntax for figuring out collection membership.  Now
that I sit down to look at it, I see that this would require changes to the
protocol, so never mind.  For example, MKCOL now determines the parent
collection as well as the name of the new collection from the request-URI.
And of course there would have to be a new method for navigating up.

> >
> > Methods are defined for creating and deleting collections, 
> adding and
> > removing collection members, copying and moving collections, listing
> > collection members, and listing the collections a resource 
> belongs to.
> > (Only the last of these is missing today.)  So we never have to
> > rely on the
> > syntax of identifiers for any of these operations.
> >
> > MOVE resource R from collection C1 to collection C2 just 
> means if you do a
> > PROPFIND on C1, you will no longer see R in the result set, and
> 
> But PROPFIND returns a URL, identifying the resource on which 
> properties are
> defined.  The requirement would have to be written "any URL 
> which identifies
> R will no longer be seen in the result set".

Right.

> 
> > if you do a
> > PROPFIND on C2, you will see R in the result set.  It implies
> > nothing about
> > identifiers for R.
> >
> > DELETE collection C1 means that C1 and all of its member
> > resources are gone,
> > not just that certain identifiers for those resources don't 
> work any more.
> >
> > Eventually we need to ask, can there be collections that 
> weren't created
> > with MKCOL?  In particular, may the file system directory 
> hierarchies that
> > many Web servers expose be collections?  We want to say, 
> yes.  All that's
> > necessary is that the Web server support PROPFIND, etc., for those
> > resources.  May a server decide that some of the resources 
> in the file
> > system directories are collection members and others are 
> not? Yes, that
> > might be confusing to users, but it could be done.  We 
> expect that mostly
> > servers would decide to have their URL namespaces exactly mirror
> > collection hierarchies, so that mostly it would be possible 
> to deduce
> collection
> > membership from the URL syntax, but no one should ever rely on this.
> 
> OK, to make sure I understand, this is an argument against strict
> consistency for DAV resources, right?

Yes

> 
> - Jim
>

Received on Friday, 13 November 1998 17:43:51 UTC