Advanced Collection Requirements

Many thanks to Jim Davis for leading the discussion of advanced collection
requirements at the LA IETF meeting.  I would like to arrive at consensus
about these requirements and produce another draft by May 15.

You can find the current draft at:

http://www.ics.uci.edu/~ejw/authoring/collection/draft-ietf-webdav-collectio
n-reqts-00.txt

Based on Jim's summary of the IETF discussion ("notes of discussion of
requirements for Advanced Collection", 3 Apr 1998), I propose to take the
following actions, unless I hear protests from the group:

Keep these requirements unchanged: 3.1.1 - 3.1.8, 3.1.10, 3.1.12, 3.2.5
Keep with minor changes: 3.2.1, 3.2.2, 3.2.3, 3.2.4

Delete the following requirements:

3.1.9 A referential member of a collection also inherits the
properties of the resource it refers to.

3.2.6 It is possible to impose multiple orderings on the same collection.

3.2.7 An ordering is not required to contain all members of the collection.

3.2.8 A collection member may belong to the same ordering more than once.

Add the following new requirement:

N.2 It is possible to request creation of a referential member that
the server will guarentee to have referential integrity.

-----------------

The following requirements need more discussion:

3.1.11 Servers are encouraged to maintain referential integrity for
referential members as far as possible, but are not required to do so.

I assume that N.2 above, which Jim reported as having been agreed upon,
would replace 3.1.11.  There was a feeling that 3.1.11 was too weak for
many applications.

When I proposed 3.1.11, I was taking the pragmatic view that in the world
of the Web, where references might point to resources on another server in
another domain, it would often be impossible for a server to guarantee
referential integrity.  The proposal in N.2 is that it be possible to
request that a server guarantee referential integrity when it creates a new
referential member. When a server receives such a request, if it cannot
make the guarantee, the request should fail.  If N.2 is acceptable to
everyone as a replacement for 3.1.11, I will make that replacement.

3.2.9 It is possible to modify an existing ordering efficiently.

The implementation of orderings and operations on them should minimize the
number of round trips and the amount of data transferred when modifying an
existing orderings.  This includes cases where a single collection member
is inserted into an ordering or removed from an ordering, as well as cases
where many collection members are moved to different positions in the
ordering.

The intent here was to avoid any implementation that would have you do
things like GET a collection member, DELETE it, and PUT it into the
collection again at a different position, just to change the ordering.

Jim was uncertain of the reasons for dissention about 3.2.9.  Perhaps we
can get them stated again on the mailing list.

Proposed new requirements that need further discussion:

N.1 Operations on a target do not affect the reference(s).

This is the mirror of 3.1.4, which states that operations on a referential
member do not affect the resource it references.  Adding or deleting a
referential member or changing its properties has no effect on its target.  

This new requirement states that changing the properties of the target or
deleting it has no effect on the reference.  Now that we have dropped the
requirement that a referential members inherit the properties of their
targets, this looks more plausible.  It may be problematic that we are here
forbidding servers from having referential members inherit properties from
their targets.  It also looks as if this new requirement conflicts with
N.2.  Suppose the server has undertaken to guarantee referential integrity
for a referential member.  What happens when someone tries to move its
target resource?  Is the server not allowed to update the referential
member to point to the new location of the target resource?

N.3 It is possible to discover whether or not a referential member has such
'integrity protection'.

This is a follow-on to N.2.  To me it seems reasonable that once we accept
N.2, we should take this next step.  If we have a mix of members for which
referential integrity is guaranteed and members for which it is not, it
should be possible to find out which sort a particular member is.

N.4 Is is possible to discover whether a resource is the target of
such a 'protected referential member'.  

Again, it seems reasonable once we've agreed to N.2 to make it possible to
find out whether there are any references to a target of a protected
referential member.

Issues raised at LA IETF for discussion:

1) Can one have a reference to a reference?

It seems reasonable to allow this.  You can always find out whether the
target is itself a reference and, if so, what URI is its target.

2) Are circular references possible?  

Of course, once you say "yes" to 1), the consequence is that circular
references are possible.

3) Can a reference have more than one target (e.g. in content negotiation)?

I would suggest that a referential member references a single URI.  If that
URI has multiple variants, then the referential member points to that set
of variants, and content negotiation would be carried on just as you would
expect.  If the URI identifies a collection, then the referential member
points to the collection.

There was not enough time in LA to discuss the issues list at the end of
the requirements draft.  Here is a reminder of what was on that list:

What are we really trying to capture in distinguishing between internal and
referential members?  Are there important differences in functionality that
are not captured by these requirements?

What should be our position on passing requests through to the target of a
referential member?  Never?  Only for certain operations? Provide an option
for all / some operations?

Is there any requirement for unnamed referential members of collections?

How far should a server be expected to maintain orderings?  If a member is
deleted from a collection, should the server delete it from all orderings?
Should a server perform all maintenance on orderings, with clients
operating on them only indirectly by submitting requests to the server?

--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 Wednesday, 15 April 1998 14:06:29 UTC