1 / 34

WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction

WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction. Jim Whitehead, U.C. Irvine Chair, IETF WEBDAV Working Group. What is WEBDAV?. Working Group on D istributed A uthoring and V ersioning on the World Wide Web

ingrid-carpenter
Download Presentation

WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related