Re: Draft Combined Requirements Document
>>126.96.36.199. 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.
>>188.8.131.52. 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
>>***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
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.
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.