WWW Distributed Authoring and Versioning (WEBDAV ):

An Introduction

Jim Whitehead, U.C. IrvineChair, IETF WEBDAV

Working Group

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/

Facets of WEBDAV

• There are many ways to view the DAV work:– Collaboration infrastructure– Metadata recording infrastructure– Hypermedia infrastructure– Namespace management infrastructure– Versioning infrastructure

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.

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

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.

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

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

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

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

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

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

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

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

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.

Requirements

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Versioning Principles

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

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.

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.

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

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.

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.

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.

End of Presentation