Re: Requirements for Collections

Judy,

See my comments below:

regards,
Surendra

-----Original Message-----
From: Judith Slein <slein@wrc.xerox.com>
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>
Date: Thursday, February 26, 1998 3:04 AM
Subject: Re: Requirements for Collections


>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.
>
I got you. My confusion here is on naming.

>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.
>

We are not trying to solve broken links problem in WEBDAV. But, still I
recommend to
consider lessons learnt or difficulties from HTTP protocol, we MUST solve
these problems
in new extensions are protocol built around HTTP. If we can leave
referential integrity as
an optional.

>>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
>authorizations
>> 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.
>

If other HTTP server is DAV compliant, we can query on the
properties of the reference. Hoping that there will be more DAV
implementaions,
users can see real benefit of this inheritance notion. We should not "lock
in"  DAV
with limitations. I would recommend to include "inheritance
notion" in the requirements.

>> 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
>collection.
>> 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?
>

There is no issue in this comment. I am in full agreement with this
requirement.

>--Judy
>
>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 Monday, 2 March 1998 13:32:01 UTC