W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1998

Re: Requirements for Collections

From: Judith Slein <slein@wrc.xerox.com>
Date: Wed, 25 Feb 1998 10:45:08 PST
Message-Id: <>
To: "skreddy@us.oracle.com" <skreddy@us.oracle.com>
Cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>, "'skreddy@us.oracle.com'" <skreddy@us.oracle.com>, "'slein@wrc.xerox.com'" <slein@wrc.xerox.com>
Thanks for your comments, Surendra.

At 01:25 AM 2/8/98 PST, Surendra Koduru Reddy wrote:
>1. 	A resource is a direct member of only one collection
>	Is there any rationale for this "restriction" on resource membership? If
resource R is a direct member
>	of collection C and resource R( though the name is R; it may be different
from R in Collection C) can be
>	a direct member of another collection D. This is very common scenario. In
my opinion, there is no
>	reason why we cannot have multiple memberships. 

I'm not sure from reading your comment whether there is a real issue here
or not.  The requirement was not meant to be about naming.  There is
nothing to prevent the same name (R) from being used for two different
resources that are direct members of two different collections.  /C1/R and
/C2/R in that case are two different resources.  The requirement claims
that the very same resource cannot be a direct member of more than one
collection.  So if /C1/ has a direct member named R and /C2/ has a direct
member named R, then /C1/R and /C2/R must be different resources.

Do you disagree with this?  If so, I need to ask you, as I asked John
Turner, what you understand by direct vs. by-reference membership. it will
be interesting to get all the different interpretations of these notions
that are current in the group explicitly defined.
>5.	Maintaining referential integrity is not required.
>	What is the purpose of create a "member-by-reference" without making sure
that "reference"
>	is not a "dead reference" or has required permissions to access it?

In an ideal world, I think we would require servers to maintain referential
integrity.  Realistically, I don't think the Web environment makes this
possible.  We all experience broken links on the Web daily.  Can WebDAV fix
this problem in general?  I don't think so.  Should we try to fix it just
in the context of collections?  We could, but the WebDAV working group from
the beginning has taken the position that we are defining a client-server
protocol, and will not define any special server-server protocol elements.
I think this would be required in order to insure referential integrity,
and still wouldn't work because a member-by-reference may reside on an HTTP
server that doesn't understand the WebDAV protocol anyhow.

You could still argue that requirements should reflect the ideal world, and
we should state this requirement even though we know we can't satisfy it.
I'm open to that view.
>8.	It is possible to remove a member-by-reference to a collection
>	What happens if an external member(member-by-refernce) doesn't have
>	or if it is a dead "resource"(it doesn't exist)? I would suggest make
this requirement as an optional
>	and if server implementations choose to implement this ( a typical
requirement in Database based 	implementations), servers can do so.

Sorry, the requirement wasn't stated very clearly.  It's meant to convey
only that the reference can be removed from the collection, not anything
about the target of the reference.

>9. 	It is possible for a member-by-reference to carry out its own
properties, distinct from those of resource
>	it referes to:
>	In a very simplistic view, all members of a collection, regardless of
whether it is a direct member or
>	a member-by-reference it will have its own properties. If it is a
member-by-reference it inherits its "source"
>	properties in addition to having its own properties.	

The inheritance notion is an interesting suggestion that I haven't heard
before.  I'm not sure how feasible it is in cases where the "source" is on
a different server, possibly an HTTP server.  Jim Davis has suggested that
the member-by-reference might keep a copy of the source's properties,
though it would risk being out of date.

>	I would suggest  requirements 11 and 9 can be combined into a single
requirement describing about 
>	properties of "direct members" and "members-by-reference"
>13.	Members by refernce are not required to have names relative to the
>	This scenario is true not only in legacy applications but also in various
business application 
>	publishing reports to webdav name space. But these resources are not
relative to collections. 

Can you describe in a little more detail what you have in mind?

Section 3.3 of the current WebDAV spec says "Any attempt to create a
resource (excepting the root member of a namespace) that would not be the
internal member of a collection MUST fail."  Is this a problem for the
applications you have in mind?


Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	(716) 422-5169
Fax:		(716) 422-2938

Xerox Corporation
Mail Stop 105-50C
800 Phillips Road
Webster, NY 14580
Received on Wednesday, 25 February 1998 13:40:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:13 UTC