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_at_w3.org)
• Send message with subject subscribe to
  w3c-dist-auth-request_at_w3.org
• Attend a working group meeting
• Next scheduled meeting Washington, DC IETF,
  December, 1997.

16
Requirements

• Overview of Requirements from draft-ietf-webdav-re
  quirements-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 (contd)

• 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