- From: Fabio Vitali <fabio@CS.UniBO.IT>
- Date: Wed, 12 Feb 1997 01:15:51 +0100
- To: w3c-dist-auth@w3.org
>>>4.9.2.6. A way to determine whether a given URL points to a version >>>of a versioned resource. >>> >>>***Judy - Are we requiring that you be able to tell this just by >>>examining the URL? >>> >>Ehm, yes. The URL does not contain enough information to be able to >>determine the position of the version in the version tree, but enough to be >>able to tell a versioned resource from an unversioned one. At least this is >>what we came in July, when we discussed about these things,I think. > >What is the rationale for wanting this capability? What user scenario does >this support? I'm starting to think this might be a design decision >(especially if you require version identifier information embedded in a >URL), not a true requirement. Agreed, my explanation was worse than could have been. As David says, >we said "a method" in order to allow the group >to decide whether "URL-hacking" or new HTTP methods were the best >implementation. , which wasn't hinted to in no way in my "explanation", and for which I am deeply sorry. I probably went further and proposed some design consideration, which are not appropriate in a requirement document. Thus the generic wording ("a way to determine...") is appropriate there. Nonetheless, the issue of whether using URL mangling or additional HTTP methods has to be faced, sooner or later. Barred those cases of alias URLs (in which I can give a version of a resource an URL that doesn't show sign of beign a version of anything), my point is that those URLs that are used by some appropriate user agents to determine base URL and version identifier -- those that that specific form of URL form was created for -- well, them: it should be possible for every agent, not just the proper one, to distinguish in those URLs a part that could be called "base URL" and a part that could be called "version identifier". Now, as far as I am personally concerned, I would like to be able to require, simply and flatly, that a version identifier is an overspecificaton of a path in a URL: version 3.2 of http://host/resource.html made by Jim within configuration called Einstein could have the URL: http://host/resource.html/Einstein/Jim/3.2 or something like that. Since this is not deemed possible, we have to find other solutions, but, please, could there be a way, in the URL of something showing signs of being a version of something, to determine which is the base URL of the resource and which is the version identifier? >>>4.9.2.7. A way to distinguish, given a URL of a version, the part of >>>the URL that identifies the version from the part that identifies the >>>versioned resource. >>> >>>***Judy - Do we really have to (want to) require that you be able to >>>find out the URL of the versioned resource by examining the URL of the >>>version? Is the requirement really just that there be some way to find >>>out, for any version, the URL of its versioned resource? >> >>Well, the idea was to have the URL of a version to be "something more" than >>the URL of the whole resource, and that this "something more", although >>opaque to the client, could be easily separated from the rest of the URL, >>so that it was possible to find out the whole resource, given one version >>of it. > >Same issue. What capability are we really trying to support? Is the idea >to provide the user a way to figure out from the name what version they're >working with? Or is the consumer of this information software? > >Also, I fear that any URL decoration scheme will have an assumption of a >non-replicated version store behind it. No. Well, yes because we are calling them URLs instead of what they should be, URIs. But not otherwise. It's in the URI that you keep the information about the suite of hosts in which the resource is replicated, spreaded, or whatever. The issue, again, is whether we want to require an additional round-trip to determine information such as the base URL, or the default version, etc., or can we deduce it, in some way, from the URL alone, even if we don't agree on a format for version identifiers in URLs, etc. Now, the question is: is there a safe way, without imposing a format on version identifiers, to be able to deduce from URLs this basic information? If so, why bother generalizing? Couldn't we simply adopt that? Even if it means imposing a format on URLs? Having this information would be useful both for software AND for humans, very much like I and Netscape Navigator both know that the URLs http://host/resource.html and http://host:80/resource.html refer to the same resource, even if the URLs are different. >I'm also interested in how you propose to keep URL's opaque, yet still >embed semantic information (in this case, a version identifier) in them. I don't believe the URL as a whole should be opaque. I believe it should be composed of two opaque parts, one being the opaque URL of the base resource, and the other the opaque string of the version identifier, just like http://host/application?parameter is composed of two opaque but easily identifiable parts, a base URL and some additional information. >The W3C position, strongly >articulated by Dan Connolly, was that any interpretation of URLs was not >acceptable. Maybe what I said is just stupid, and David hints that it has already been discussed before, I probably missed or forgot that. But the prohibition to interpret URLs is not complied to neither for locations (after #), nor for parameters (after ?). So this would be a (highly justifiable) case for another special decoration. Tough. But, the way I see it is that the alternative is *REQUIRING* an additional HTTP request for editors that are not of the same brand of the server, and therefore can't interpret the URL directly. This implies that the users using matched server and user agent may discover some information in one trip, while the users using a different user agent would require two. I can just see the comparisons and benchmarks of servers and clients on Byte. This is a GOOD excuse for information racism. Fabio Vitali
Received on Wednesday, 12 February 1997 10:10:44 UTC