Informal Technical Meeting on WWW Distributed Authoring and Versioning

MIT Faculty Club, Cambridge, Mass.

September 16, 1996

An informal technical meeting on the subject of Distributed Authoring and Versioning on the World Wide Web was held on September 16, 1996, at the MIT Faculty Club, on the campus of the Massachusetts Institute of Technology, Cambridge, Mass. There were 19 attendees from the following organizations: America Online, Apache Group, Dynamic Diagrams, Harlequin, Microsoft, Massachusetts Institute of Technology, Mortice Kern Systems, Open Group Research Institute, Novell, NTT Palo Alto Labs, University of California, Irvine, World Wide Web Consortium, and Xerox. The attendees thank the World Wide Web Consortium for graciously supplying the meeting site and food. Many thanks also go to Susan Hardy, W3C, for her help in arranging the meeting.

These meeting minutes were recorded by Jim Whitehead. The Chair of the Meeting was Jim Whitehead. These notes were not developed into minutes until June, 1997, and were never approved by the attendees of the meeting. Thus, while every effort has been made to ensure these notes reflect the activities which took place at this meeting, they have not been subject to review, and hence may reflect the bias of the recorder.

Introductory remarks by Jim Whitehead.

Presentation by Yaron Goland on an overview of Microsoft Distributed Authoring and Versioning Requirements and draft implementation ideas.

Described interest in subject. Microsoft is very interested in following standards.

There are many distributed authoring and versioning tools available today -- this is not new.

What people want for tomorrow: location independence, and collaboration.

Backwards compatibility is very important. VSS team admits they will not be able to give full backward compatibility to people with only browsers. Backawards compatibility leads to URL munging, which is not desirable.

Need groups of functionality, so if you want versioning, use the versioning functionality package of HTTP.

Attributes. Need attributes, they're very powerful. Need a registry for the namespace -- perhaps have per-company (novell.*) registry. Can do security, for example.

Directory URL. URL ends with a slash. Need directory infomation in a standard format. Interactions with other functions needs to be discussed -- for example, DELETE should delete the directory, and all files & directories below it.

File control for URLs - Copy, Delete, Get, Move, Put, Rename. Issue of copying from one server to another is tricky, need for many.

Need for byte ranges and insertions. Don't want to change whole file just for 10 byte insertion.

Word and Excel need locking, are "dead in the water" without it, and with full [Full|Partial][Read|Write][Lock|Unlock] capability. Locks need to be independent of other methods.

Checking out a directory -- should this be recursive? Should all operations on directories be recursive? Attributes could be powerful enough to implement check-out -- just store the person who has checked out the file into an attribute.

Command comments -- the ability to add a string or URL to any method. Can be used for comments for checkin and checkout.

Server diff capability. Use VTML for returning a server-generated diff between two files. Want the server to be able to do a diff -- for efficiency?

Merge - need to be able to specificy how to do this on either the client or the server.

Search - requirements: wild card and regular expressions. Don't do this through URL munging -- do it with a new method.

Version identification -- requirement: URL independent.

Access control. Needs to support group management. Suggest the formation of another group to address access control. This could cause a major interoperability problem. All our work could be for naught if access control is proprietary, but everything else is open.

Stressed need to make separate specifications so companies can pick them up or put them down, depending on whether they need them.

Del Jensen: Working on server side diff for his product. What about different types?

Yaron Goland (YG): Can specify the type you want for the diff coming back.

Steve Carter: Need to abstract the notion of directory away from just a directory. ODMA as an example.

YG: Word supports ODMA.

Need to discover where artifacts are.

Judith Slein (JS): Need ability to say "Show me everything in the X collection."

Henrik Frystyk Nielsen (HN): Why do we need file operations? I don't see a clear need why they are needed. For the first time there's a naming scheme which is finally independent of the filesystem.

YG: Users want it to be able to aggregate their information into hierarchies. Can specify these capabilities as a PEP extension.

HN: Can simply specify relations between items, and this is used to organize information.

YG: Users want this ability. As a result, MS is going to implement this capability.

Some discussion of interaction between names, versions, and caching.

Discussion of retrieving a named version of an entity. Should it be possible to get there directly, or via a history view, then to the version itself.

Novell also needs direct access to a named version of an entity.


Presentation by Jim Whitehead on Distributed Authoring Requirements.

During the presentation, many comments on the requirements were made:

- change "entity" to "resource" throughout
- there is a need to list relationships in addition to creating, querying, and deleting them
- there is a need for a relationship discovery mechanism
- the terminology used to describe locks is inconsistent with standard usage, and needs to be made consistent with standard lock/transaction semantics
- a read lock should have the meaning that only the owner of the lock may read the resource
- there needs to be a section describing lock combinations
- the server makes administrative policies about locks
- the section "Notification of Intention to Edit" needs to be moved to the versioning requirements document
- in partial write, a note needs to be made that updates can be small or large, and can extend past the end of the resource
- a question was raised whether support for move/rename capability across servers would also be supported
- there is a need for a new requirement for server difference functionality on a per media type basis, since it is cheaper than performing two gets, especially for small changes.
- interactions with digitial signitures need to be explored
- a comparison with the DMA (AIIM) requirements would be worthwhile


Presentation by Jim Whitehead on the Group's Charter

Wording changes to the Charter were suggested.


Presentation by David Durand on Versioning Requirements

Discussion of overlapping requirements. Notification of intention to edit --> versioning. Locking remains in distributed authoring.

Discussion of non-change of versions. Problem is a version could be accessed via more than one name. How to specify the requirement without basing it on a name.

Discussion of client interoperability. Jim Whitehead (JW) thought that the server should adapt to the clients. Most others thought that a client would adapt to the particular implementation offered by a server.

Big discussion over backawards compatibility, and whether a version should be specified in a URL. Seemed to be consensus that there does need to be support for non-version aware clients.

David Long (DL): Discussion of name of all versions of a resource vs. name of individual versions sounds a lot like content negotiation.

Agreement on "deafult" or "tip".

Agreement on getting to pred/succ//root/default version of a document.

Remove timeouts on locks. Wasn't perceived as very useful.

Discussion of delete vs. destroy. Destroy is a common functionality.

Discussion of server diff -- need to get a diff of two objects which are large, but which may have a small set of differences.


Discussion of Action Items:

Modify Distributed Authoring Requirements based on feedback and put it out this week.

Revise the scenarios document this week.

Revise the Charter based on feedback from the meeting.

Revise the Versioning Requirements by two weeks from this Friday.

Scenarios of server-server activities should be submitted during the week of Sept. 23-28.

*** Meeting Adjourned ***