- From: <hallam@ai.mit.edu>
- Date: Mon, 28 Oct 96 12:51:10 -0500
- To: connolly@beach.w3.org, w3c-dist-auth@w3.org
- Cc: hallam@ai.mit.edu
>That's what I'm saying as well. The bottom line is: if both >the client and the server need to refer to the same thing, >give it a name (i.e. a URL) and consider it a resource. This is one reason why early attempts to "solve" the versioning problem ended up tied in knots. If you decide that everything has a URI and that the URI is all that is needed to retrieve a resource its not possible to provide versioning through lexical properties of the URIs. Ie one cannot create a convention that http://foobar.com/fred;3 is version 3 of fred. I agree with Dan that we have to name everything and keep to the principle of only using one typr of URI rather than attempt to create ad hoc accessors for "versions" of a URI. What we have is not a resource with many versions but a collection of resources and a collection of assertions stating which resources are earlier variant of others. Ie if we take the "fred" resource we may have the following URIs :- Fred The resource itself, the operation GET("Fred",t) returns the current value of Fred, the Fred of time t. It is the "essence" of Fredishness. Fred.v1 Fred version 1, A Fred that is known to be immutable in time. GET("Fred.v1", t) returns the same value for all values of t. This value can be cached since it cannot change by definition. Fred.v2 Fred version 2, see above. The advantage of separating the assertions from the resources is that we then have a scheme in which we can move the assertions about in lieu of objects. If we want to synchronise two repositories we can do so by first exchanging the assertions as to which fred versions have changed. The other key advantage of this approach is that because we have not relied on particular lexical properties of the labels (ie convention fred;3 fred;4 are versions 3,4 of fred) we can go to offline distributed authoring and make it work. Consider the following scenario. I have two machines, a laptop and a desk machine. I work on projects on both machines, the two machines are only briefly in communication with each other so we have a continuing problem of synchronising two databases. I'm using this example because I think it gets to the core of what is hard in the distributed authoring problem. If we can solve this problem in a principled manner I think we can do the collaborative, multi-author one as well. I also think that it is the key to making the Network computer something that would be an advance on our current systems rather than an Oracle/IBM big systems, MIS centric disaster. There is a reason why the world has gone to Microsoft and some people just "don't get it", but thats a digression. The rules for the laptop/desktop scenario are as follows:- 1) If compatible changes in the two databases are made the system synchronises transparently. 2) If there are collisions the system responds with a semantic level merger of the two systems. By "semantic" level I mean that the merger cannot be the CVS style lexical kludge. The merger process must exploit structure or else it is all hopeless. To make this work I think we need to consider carefully the nature of hypertext structure. I believe that hypertext has structure in the broad scale that is as "cliched" as ordinary text but is beyond merely headings, paragraphs etc. For example where there is a list of objects there is probably a need for a cliche which allows that list to be extended. Anyone who has done requirements engineering will be familliar with a structure of text in which requirements and architecture have to be mutually cross linked. The generation of tables of authorities, crossindexing and cross referencing is all part of this structure. Phill
Received on Monday, 28 October 1996 12:45:06 UTC