Re: Version identifier in URL

Scot Malloy (malloys@documentum.com)
Fri, 31 May 1996 09:06:30 -0600 

Jim Whitehead wrote:

>
> Larry Masinter later writes:
>
> >Well, there's already precedent for form URLs, for example, e.g.,
> >
> >  http://host.dom/form-handler?x=a+y=b+z=c
> >
> >even though the client treats any URL it receieves as 'opaque', they
> >can still be constructed. I see some value in just continuing this
> >tradition for versions.
> >
> >In fact, how about making a "version" just a special kind of
> >query?
>
> Dan Connolly agreed, stating:
>
> >Fair enough. ?version=xxx seems reasonable for (a)
>
> Thus, there appears to be some agreement that employing the URL parameter
> or URL query field would be useful for specifying the version of an entity.
>
> However, it is not entirely clear to me what the tradeoffs are between
> using the URL parameter mechanism (e.g., ";version={version identifier}")
> versus using the URL query mechanism (e.g., "?version={version
> identifier}").  Can any members of the list shed some light on the intent
> of these two mechanisms?  This information is unavailable in either the
> HTTP specification or RFC 1738 (Uniform Resource Locators).


I also agree that the "?version={version identifier}" mechanism is a good
choice,
for practical reasons - regardless of the original intent of the spec ;-).
(I also looked for a hard distinction between "parameter" and "query" in
the RFCs and found nothing
conclusive - Dan, any thoughts on this?).

While both "?version={version identifier}" and ";version={version
identifier}" appear to be valid
constructs, forms submission capability might be a consideration here.
"application/x-www-form-urlencoded" forms submission causes current forms
supporting user-agents to construct a
URL using the query mechanism.
The query mechanism would therefore give us the added benefit of allowing
either the user to specifiy the
version identifier via a form element *or* the author to "hardcode" the
version identifier into the URL within
the tag (anchor,img etc...).
So, I'd say the query mechanism looks slightly more preferable.

- Scot

--
======================================================================
Scot Malloy                      E-mail: malloys@documentum.com
Documentum, Inc.                 Voice:  (510) 463-6827
5671 Gibraltar Drive             Fax:    (510) 463-6850
Pleasanton, CA 94588             http://www.documentum.com
======================================================================