a review
I thought it might be nice to take a quick spin through RFC 2291, otherwise known as Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web.
This is the 1998 think-piece by Judith Slein, Fabio Vitali, E James Whitehead, Jr., and David G. Durand that led to WebDAV the next year. But the important thing is that what they came up with doesn't just apply to WebDAV, but to any distributed authoring system.
Briefly, the document is a pretty comprehensive set of requirements for a collaborative authoring environment. There are certainly requirements outside of these -- the existence of a social contract, usability requirements, and backchannel communication to name just three -- but these are the basics from an engineer's point of view.
Properties
This is the ability to associate arbitrary metadata with any object. This seems obvious on the surface: title, author, date, etc. But the key word here is arbitrary. What will happen in twenty years when all web images are expected to have a foo score, and users want it as the primary means of searching and sorting? Will your system be able to handle this?
Links
Again, it seems obvious at face value. Pages need to be able to link to each other. But so do other things: songs need to link to other songs in a track list; a photo I took needs to link to a related photo you took, on another server; all of my videos need to link to licensing information.
The list goes on and on, and obviously we don't want to have to code all these relationships using href tags.
Write Locking
From a social standpoint, there is nothing worse than two or more people editing a web resource at the same time, because it will almost certainly result in wasted time all around. This is something that writing blogging tools doesn't prepare you for...
Reservations
A reservation is a declaration of intent to edit a resource at some point in the future. The RFC is a little fuzzy on how this differs from a write lock, except to say that there are situations where you might lock a resource but have no intention of editing it. I'm much more interested in the task-assignment implications of this functionality than in its particular role of supporting write locks. I'd rather reimagine this as a changelog that stretches into the future...
Retrieval of Unprocessed Source
There are two categories I can think of here. The first is source code, the second is an unprocessed binary that would normally be compressed and/or filtered before delivery via GET. A shadow meaning of this has to do with version control, and always being able to retrieve the original version of a file. (As in, give me the raw image before cropping, color-correction, and jpeg compression.)
Partial Write
This is an incremental update requirement. I should be able to submit just the part of the document I edited, not the full document. This requirement seems a little stale to me, because it assumes that conserving bandwidth will be worth implementing partial editing functionality -- essentially getting a client to submit a diff against the original file and getting the server to apply it as a patch. Worth looking at, but I'm skeptical about implementation.
Copy and Move
Yep. No question about it, you gotta be able to move stuff around, and make new stuff from it.
Collections
The RFC spends a lot of time on direct, hierachical collections, also known as directory structures, but that's boring. I'm much more interested in the possibility of ad hoc collections-by-reference: these are my favorites, these are the purple ones, these are the ones I wrote when I was drunk, etc.
Versioning
Essentially this allows for browsing of document history, but the implementation they suggest allows following branches -- say a particular version of a document is copied and turned into something else -- as well. Remember that you need some way of dealing with the collection of versions as well as each specific version of a resource.
Variants
There must be a mechanism for serving the same resource in different file formats or different languages depending on client configuration. This implies that variants may also have their own local properties apart from the main resource.
Security
The RFC is a little light on the details here. It recommends both authentication and access control using existing methods. Yup.
Internationalization
Like security, this is deemed something you need, but without any concrete recommendation on how to achieve it. That's why Unicode is so tasty.
By Chris Snyder on September 17, 2003 at 12:19am