- From: Judith Slein <slein@wrc.xerox.com>
- Date: Mon, 10 Feb 1997 11:24:30 PST
- To: w3c-dist-auth@w3.org
The version of the requirements document that I distributed today tried to consolidate the two earlier requirements papers without changing their content. Some changes will need to be made before the new document is ready to be submitted as an Internet Draft. The requirements are inconsistent with the current specification on many points, and these need to be resolved. In addition, the requirements document takes positions on many issues that have turned out to be controversial. The group needs to come to some consensus on these issues. Since our schedule calls for the requirements document to be submitted as an Internet Draft by the end of February, I hope that we will be able to discuss and resolve many of these questions by Monday, February 24. Whatever issues have been resolved by then can be reflected in the requirements paper that gets submitted. Requirements not satisfied by the specification: 1. Attributes. The current specification says almost nothing explicitly about attributes, although it is possible to deduce a lot about how attributes would be manipulated from the discussion of links. I believe that all the requirements about attributes are satisfied except one: "Via HTTP, it should be possible to ... query ... arbitrary attributes ..." We need to decide whether we want to define a query syntax. If not, we need to decide whether we want to support a weaker requirement, for example that the model of attributes we define should be capable of supporting some query mechanism. 2. Locks. "It should be possible to take out a lock on multiple resources in the same action." 3. Locks. "It should be possible to assign a lock to a single person or to multiple persons with a single action." 4. Locks. The requirements call for support of read locks, which are not in the specification. 5. Notification of Intent to Edit. "It should be possible to notify the HTTP server that a resource is about to be edited by a given person." This requirement is stated independent of versioning, implying that it should be possible to give this notification even for non-versioned resources. However, the specification supports notification of intent to edit only in the context of versioning. 6. Retrieval of unprocessed source for editing. Support for this requirement was accidentally dropped from the specification. 7. Partial Write. "After editing a resource, it should be possible via HTTP to write only the changes to the resource, rather than retransmitting the entire resource." Not mentioned in the specification. Does it need to be, or is it adequately supported by HTTP already? 8. List URL Hierarchy Level. Support for this requirement was accidentally dropped from the specification. 9. Versioning - navigation. The requirements state that from any version, it should be possible to find the root. It should be possible to navigate to the predecessor. 10. Versioning. For any URL, it should be possible to find out whether its resource is a version in some version tree. It should be possible to find out what versioned object (version handle) it belongs to. 11. Version - tracking. "A way for the server to ensure that the user operating on a resource is the same one who reserved it." Functionality in the specification that is not in the requirements: 1. Destroy 2. Undelete 3. CopyHead 4. MoveHead 3. Schema Methods (discovery mechanism) 4. Diff/Merge 5. ServerMerge 6. UnVersion The following controversial issues need to be resolved: 1. The requirements (as well as the charter) say that we are extending HTTP. Discussions at Irvine made it clear that there is no consensus on this in the group. 2. Locking. The requirements say that it should be possible to lock subsections of a resource. The specification does allow this. But at Irvine it appeared that there was not consensus on this point. 3. Copy, Move / Rename. Discussions at Irvine made it clear that there is controversy about the desired semantics of these operations, especially for complex resources like collections, versioned resources, and resources with attributes. The requirements are vague and don't address the hard questions. Do we want to leave them that way? 4. Versioning General Principles need to be revisited. - It is not clear that the specification obeys the "Stableness of Versions" principle. If a user requested to overwrite an existing version rather than create a new one, there is nothing to prevent that, and nothing to prevent the server from complying. Should there be? - "Separation of resource retrieval and concurrency control" is supported by the Request-Lock, Request-Intent, and Request-Working-Loc parameters to the CheckOut method and the discovery mechanism. This is all embroiled in the controversy over how much latitude we want to give servers, how simple we want to make things for clients, whether we want to rely on the discovery mechanism, etc. 5. Versioning - uncheckout. Neither in the requirements nor in the specification. Is it needed? 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 Monday, 10 February 1997 14:21:01 UTC