Hi. Being really up to being torched alive by this group, I'll add some more questions to my previous posting. What does an undecorated URLs mean? Opaque and determined by the versioning tool? Access to a "default version"? What about being able to access to the whole tree (or whatever) of versions? VTML allows the access to the whole block of data, and allow the client to parse and show individual versions. This is also useful for differencing and comparison at the client side. What about enquiring about the shape of the version tree (or whatever)? How do I ask: How many branches are growing out of version x? Say I want to merge diverging contributions, and need to know how many offsprings of a specific version have been checked in at this moment. Larry Masinter writes: >Separate out the problem of > a) construct a URL for a previous version of a resource > given the current version of a resource and information > about the server's versioning system > b) determining from two URLs what their version relationship > might be. > >I think it's reasonable to use URL-decoration for (a) and not for (b). I really don't see the difference. They both depend on the specifics of the versioning system, and therefore at the very least from the opaque "versioning identifier" contained in the URL. Some naming systems will contain no clue about the relations between versions. E.g. if version "Madagascar" is derived from version "Bolivia", I bet you can't provide (a). If the versioning system uses any of the naming schemata proposed in the VTML paper, then you can have the exact relation existing between any two versions. In both cases, anyway, the URL has nothing to do with this determination, because it's everything in the versioning identifier, which is opaque to the URL decoration (I think we agree on this, don't we?). David Fiander writes: >>Fetch the version previous to URL(x). > >if "URL(x)" is a versioned URL, this boils down to > > Fetch the version previous to the version "foo" > >which will clearly give the same answer all the time, since every >version of the document will only have one immediate predecessor. Uhm, will it? Diverging branches of versions are only one of the possible options for the development of documents. VTML allows for re-joining branches through the MERGE operation, and Palimpsest goes even further by allowing versions to be composed of arbitrary collections of changes, so that there can be no proper "previous version". This is something that is specific of the versioning system. What I'm trying to say, is that Robert Pettengi's question may have a unique answer (tree-shaped versioning structure), a non-unique answer (DAG-structure as in VTML), or no reasonable answer (sick graph structure as in Palimpsest), depending, again, from the versioning system. Ciao Fabio Vitali