Collaborative Batch Web Editing Tool

Project Manager: Daniel Dardailler <danield@w3.org>
Author of this document: Yves Lafon <ylafon@w3.org>

Created: 29 August 2002. Last updated: 29 August 2002.

Table of Content:

• Introduction
• Jidegit
• Using Jigedit
• Deviation from plan

Introduction

Plain HTTP servers do not have tools to help remote edition of content, at best, the basic functions defined by HTTP can be enabled, like the PUT and DELETE methods, used to save or delete remotely content on the web servers. Allowing control of the content on the server cannot be done without some tools. The WebDAV protocol allow more control by addding the possibility for WebDAV enabled clients to control some of the metadata associated with a resource, like changing its MIME type. But still, no way of managing content. The goal of this project is to allow management control by implementing tools that will provide batch update and control over content.

JigEdit

The concept

JigEdit is an extension to Jigsaw, W3C's generic and extensible server. This extension implements WebDAV to allow editing of some metadata of resources, and allow WebDAV enabled clients to use JigEdit as a publication server. It also impements some actions to manage the content accessible by any browser that allows batch publication, updates, revert to older version or annotation of content changes. It uses CVS(Concurrent Versions System), and show a Web interface to it, this interface can be controlled by any graphical or non-graphical browser.

JigEdit works with three spaces:

• The CVS repository, that contains all the version and the differences between revisions
• The exported space, the so-called "publishing space", a view of what the world is seeing
• Some optional working spaces, where people can modify several resources before releasing them in the publishing space

The classic scheme is a user who has a local editing space. The client gets a page from his editing space (with or without automatic synchronization with the CVS repository - latest version), edit, and sace the edits using a PUT-aware client, like Amaya. The document is then saved on the client editing space, and this document can be commited automatically in the CVS repository, so that other editors can share the latest edits. Then, when all the documents the client edited are ready for publication, the client goes to his PutList, and propagate the changes to the publishing space (it can, of course, be automated, using the "auto-publish" option). Here is an example of PutList in auto-publish mode (as content is automatically published, there are no pending recently updated resources to publish):

Also, direct editing on the publishing space can be done, the publishing phase is then no longer needed, and the auto-commit option should be enabled, so that users editing their own space are as much as possible synchronized with the exported version.

To allow control over resources, a way of triggering CVS actions, like updates, commit, revert, remove are accessible from a Web form, it has a HTML UI. The following snapshot is the special UI to control files:

The file FAQ.html has been edited by someone else, and the UI allows you to mark it for an update. There is also a link to the log of revision that allows you to see the history of changes, as well as edit those changes, as pictured below:

The interface to control directories is more limited as CVS is mostly file-oriented, it still allows the user to view what is there and what is missing.

The lost update problem

One of the main issue when updating resource on the web is to ensure that the resource you are editing has not been modified by a third party. The main way to achieve this is not to check for date stamps, as clocks may be different, depending on the machine, but to rely on a unique identifier for a specific version of a resource, the HTTP entity tag (ETag). A strong ETag is a unique identifier for a particular representation of a resource, it means that the same URI may have different ETags as a function of time. Also, multiple URIs may share the same ETag to indicate that the resources are perfectly equals (at the bytes representation level).

Jigsaw implements ETags checking and even negotiated resource will enforce ETags checking prior of any modification on resources.

More information on the lost update problem can be found in a W3C Note. We also developed the a way to avoid lost update problems in Amaya.

Installation

JigEdit being an extension to Jigsaw, please refer to Jigsaw installation page, download the latest jigedit.jar, and follow the specific instruction as defined in the JigEdit sample configuration document.

Deviations from plan

none.