WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction

1. WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction Jim Whitehead, U.C. Irvine Chair, IETF WEBDAV Working Group

2. What is WEBDAV? Working Group on Distributed Authoring and Versioning on the World Wide Web Goal:To enable distributed web authoring tools to be broadly interoperable. Home page: http://www.ics.uci.edu/~ejw/authoring/

3. Facets of WEBDAV • There are many ways to view the DAV work: • Collaboration infrastructure • Metadata recording infrastructure • Hypermedia infrastructure • Namespace management infrastructure • Versioning infrastructure

4. Collaboration Infrastructure • Whole resource locking supports: • remote collaborative authoring of HTML pages and associated images • remote collaborative authoring of any media type (word processing, presentations, etc.) • Infrastructure for development of asynchronous, widely distributed, hypertext-aware, collaborative editing tools.

5. Metadata Recording Infrastructure • Metadata support • Properties. (name, value) pairs can be created, modified, deleted, and read on Web resources. • Consistency of properties can be maintained by the server or the client • Infrastructure for how to record information about Web data

6. Hypermedia Infrastructure • Hypermedia linking: • Relationships. Allow relations between resources to be captured (e.g. source code “implements” requirements, “table of contents”) • Relationships can be defined on any media type, not just HTML. • Clients can expose relationships in their user interface, making them browsable hypermedia links • Infrastructure for authoring hypermedia among all media types.

7. Namespace Management Infrastructure • Remote name space management: • Copy resources • Move resources • Create and modify containers of resources (such as directories) • Redirect queries for resources • Infrastructure for remotely organizing and viewing collections of Web resources

8. Versioning Infrastructure • Versioning is integral • check-out, check-in • version graph history • comments on check-out/check-in • server merge/difference • browse old versions • Infrastructure for remotely versioning Web resources

9. Requirements • Requirements Document • High-level distributed authoring and versioning requirements • Editor: Judith Slein, Xerox • Began working group last call on September 3, 1997 • Call for consensus, submission to IESG in late September

10. Protocol • Protocol Specification • Specifies details of extensions to HTTP protocol to meet requirements • Covers properties, collections, namespace operations, locking (perhaps versioning) • Currently at draft-ietf-webdav-protocol-02.txt • Editor: Del Jensen, Novell • Next release: September 24, 1997

11. Scenarios • Scenarios document • Gathers scenarios of usage of distributed authoring and versioning technology as a sanity check for requirements, protocol specification • Editor: Ora Lassila, Nokia

12. Access Control • Access Control Document • Currently working on access control requirements • Jon Radoff, Novalink is current editor, but has not responded to email status inquiries • Goal: finish requirements and protocol aspects by June 1998

13. Recursive Operations • Recursive Operations Specification • Describes how to perform copy, move, lock for a tree structure of resources (a direct containment hierarchy) • Saveen Reddy, Microsoft is editor • Goal: finish by April, 1998

14. Variants Specification • Variants Specification • Will describe requirements for authoring resource variants • Specify protocol elements needed to support authoring of resource variants • No editor yet chosen • Goal: August, 1998

15. Getting Involved • How do you join the WEBDAV Working Group? • Join the mailing list (w3c-dist-auth@w3.org) • Send message with subject “subscribe” to w3c-dist-auth-request@w3.org • Attend a working group meeting • Next scheduled meeting: Washington, DC IETF, December, 1997.

16. Requirements Overview of Requirements from draft-ietf-webdav-requirements-02.txt

17. Metadata Requirements • Properties. It must be possible to create, modify, query, read and delete arbitrary properties on resources of any media type. • Relationships. It must be possible to create, modify, read and delete typed links between resources of any media type.

18. Collection Requirements • List Collection. A listing of all resources in a specific collection must be accessible. • Make Collection. It must be possible to create a new collection. • Add to Collection. It must be possible to add a resource to a collection directly or by reference.

19. Collection Requirements (cont’d) • Remove from Collection. It must be possible to remove a resource from a collection. In the case of a resource that belongs to the collections directly, this results in the resource being deleted. In the case of a resource that is merely referenced by the collection, only the reference is removed.

20. Copy Requirements • Copy. It must be possible to duplicate a resource without a client loading, then resaving the resource. • After the copy operation, the content of the destination resource must be octet for octet identical to the content of the source resource. • A modification to either resource must not cause a modification to the other.

21. Move Requirements • Move/Rename. It must be possible to change the location of a resource without a client loading, the resaving the resource under a different name. • After the move operation, the content of the resource at its new location must be octet for octet identical to the content of the prior resource. • It must no longer be possible to access the resource at its original location. • The move operation should leave an audit trail.

22. Locking Principles • Independence of locks. It must be possible to lock a resource without re-reading the resource and without committing to editing the resource. • Multi-resource locking. It must be possible to take out a lock on multiple resources on the same server in a single action, and this locking operation must be atomic across these resources.

23. Locking Requirements • Write Locks. It must be possible to restrict modification of a resource to a specific person. • Lock Query. It must be possible to find out whether a given resource has any active locks, and if so, who holds those locks. • Unlock. It must be possible to remove a lock.

24. Reservation Requirements • Reserve. It must be possible for a principal to register with the server an intent to edit a given resource, so that other principals can discover who intends to edit the resource. • Reservation Query. It must be possible to find out whether a given resource has any active reservations, and if so, who currently holds reservations. • Release Reservation. It must be possible to release the reservation.

25. Miscellaneous Requirements • Source Retrieval.The source of any given resource must be retrievable. • Partial Write. After editing a resource, it must be possible to only write the changes to the resource, rather than retransmitting the entire resource.

26. Versioning Principles • Stability of versions. A client must be able to determine that a version has been frozen. Any successful attempt to retrieve a frozen version of a resource will always retrieve exactly the same content. • Versioning Policies. The protocol should identify the policies that it dictates and the policies that are left up to the versioning system implementors or administrators.

27. Versioning Principles • Media Type Independence. It is possible to version resources of any media type.

28. Version Topology Requirements • Version topology. The collection of related versions of a resource forms a directed acyclic graph (known as a “version graph”) • Version graph distribution. It should be possible for a version graph to span multiple servers. • Version graph handle. There must be a way to refer to the version graph as a whole.

29. Version Graph Retrieval Requirements • Version graph retrieval. There must be a way to retrieve the complete version topology for a version graph. • Default version. There must be a way to assign a default member of a version graph for retrieval.

30. Version Graph Navigation Requirements • Navigation. Given a reference to a member of a version graph, it must be possible to discover and access the following: • root member of the graph • predecessor member(s) • successor member(s) • default member of the graph

31. Uniqueness/Addressability Requirements • Uniqueness of version identifier. A version identifier must be unique across a version graph. • Addressability. All versions of a resource are themselves resources, and are individually addressable.

32. Versioning Session Requirements • Check-out/Check-in. It should be possible to check-out, and then check-in a resource. • Session tracking. It must be possible for a client to query the server for information about a version tree, including which versions are locks, which are reserved for editing, and by whom. • Comments. It should be possible to assign comments on a check-out or check-in.

33. Difference/Merge Requirements • Server difference. It must be possible for a client to retrieve a list of differences between two or more resources of the same media type. • Server merge. A client must be able to request that the server merge two or more resources, and return the results of the merge to the client, or store the result as a resource. Server support for this functionality must be optional.

34. End of Presentation