Rejected Requirements

I was considering keeping a list of requirements that have been considered,
but rejected, along with the reasons for rejecting them, at the end of the
requirements document.  In the end, I decided not to do that, but I do want
to make sure that such a list stays in our archive, so here it is:

1. Optional Server Support for Locking.  Some systems use other
mechanisms besides locking to ensure consistency in environments where
several users may wish to edit a resource at once.  These other 
strategies must be permitted.

Reason for rejection: A general decision was made that the requirements
draft should not specify which functionality is optional and which is
mandatory for servers to support.  The WebDAV specification will discuss
levels of compliance.

2. A client must be able to request that the server generate a 
version identifier for a new member of a version graph. Such an 
identifier will not be used by any other client in the meantime. The 
server may refuse the request.

Reason for rejection: Other requirements capture the intent of this one:
That there should be a way to refer to any member of a version graph, that a
client should be able to propose the identifier to be used for a new member
of a version graph, that the server should be free to ignore the client's
proposal and use a different identifier for the new version, and that the
server should inform the client of the identifier assigned to a newly
created version.

3. It must be possible for a client to request from the server a 
list of the differences between two or more resources of the same media 
type.

Reason for rejection: The consensus was that this facility is not needed.

4. A client must be able to request that the server merge two or 
more resources, and return the result of the merge to the client or
store the result as a resource.  Server support for this functionality
is optional.

Reason for rejection: The consensus was that this facility is not needed.

5. Partial-Resource Locking. It must be possible to take out a 
lock on a subsection of a resource.

Reason for rejection: HTTP methods should operate only on resources.  If the
subsection is to be locked, it must be addressable, and so is itself a resource.

6. Attributes are resources that may have attributes of their own, may be
subject to content negotiation, etc.

Reason for rejection: Whether attributes will be resources is a design decision.

7. Only the owner of a lock or a principal with appropriate access rights
may remove the lock.

8. Only the owner of a reservation or a principal with appropriate access
rights may release the reservation.

Reason for rejection: Cannot reconstruct the reasons for removing 7 and 8
from the requirements.

9. It must be possible for a client to specify whether a resource's user
attributes and relationships are to be copied with it, although the 
server may decline to copy them. It may decline to copy user attributes
if the destination namespace supports different attributes from the 
source namespace, for example. The server may follow whatever policy it
likes for copying server attributes.

Copying a collection causes all of the resources that belong to it
directly to be copied as well. For resources that belong to it by 
reference, the reference is copied.  It must be possible for a client
to specify whether subcollections should be copied with the collection.

If a version graph is copied, all relationships between nodes in the 
graph must be changed in the new copy to reflect its new location.

10. It must be possible for a client to specify whether a resource's user
attributes and relationships are to be moved with it, although the 
server may decline to move them. It may decline to move user attributes
if the destination namespace supports different attributes from the 
source namespace, for example. The server may follow whatever policy it
likes for server attributes.

Moving a collection causes all of the resources that belong to it
directly to be moved as well. For resources that belong to it by 
reference, the reference is moved.  It must be possible for a client
to specify whether subcollections should be moved with the collection.
If not, subcollections that belong to the collection directly should be
deleted from the source location.

If a version graph is moved, all relationships between nodes in the 
graph must be changed in the destination resource to reflect its new 
location.

Reason for rejection: 9 and 10 specify too much detail about the semantics
of copy and move for a requirements document.  Decisions at this level
should be made in the protocol specification.

11. The copy operation should leave an audit trail.

12.  The move operation should leave an audit trail. The audit trail makes
it possible for the server to redirect client requests for the resource at
its old location, perhaps with a "301 Moved Permanently" status code.

Reason for rejection: Requiring audit trails has no effect on the interface
for performing WebDAV operations. Audit trails are a side effect of other
operations.

13. Delete

HTTP already provides a DELETE method, but the semantics of DELETE must
be reconsidered once attributes, relations, collections, and versions
are introduced.

When a resource is deleted, it must be possible for a client to specify
whether a its attributes are to be deleted with it. In an environment 
where resources may share the same attributes, the server may decline 
to delete the attributes.

When a resource is deleted, the relationships in which it participates
should also be deleted.

If the resource being deleted is a collection, all resources that belong
to it directly will be deleted as well.  Resources that belong to it by
reference are unaffected.

If the resource being deleted is a member of a version graph, the
predecessor and successor relationships in the graph must be updated,
and any metadata required by the versioning server must be supplied.
The versioning server may, for example, require a comment explaining
the reason for the deletion.

Reason for rejection: Again, 13 is at too low a level for a requirements
document. The requirements should not state in detail what changes in
existing HTTP methods are needed. They should say only that WebDAV should
consider the impact of all WebDAV extensions on current HTTP methods, and
specify how the existing methods need to change.

14. Structured Documents

Some level of document structuring can be achieved using collections.
Providing more extensive document structuring capabilities is too large
a task for this group.

15. Link Integrity

Servers should not be asked to guarantee link integrity.  It would be
impossible to achieve this without collaboration between servers. Enforcing
link integrity would also make move and delete have scope beyond just the
resource on which the method is being invoked.

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:		128-29E

Received on Thursday, 29 May 1997 17:50:47 UTC