Re: Draft Combined Requirements Document

>>>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