W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1996

Re: Prelim. DAV spec.

From: Larry Masinter <masinter@parc.xerox.com>
Date: Thu, 31 Oct 1996 09:56:34 PST
To: yarong@microsoft.com
CC: connolly@beach.w3.org, ejw@rome.ics.uci.edu, w3c-dist-auth@w3.org
Message-Id: <96Oct31.105634pdt."415911"@mule.parc.xerox.com>
Re my remark:
# When we add versioning, you can say that 
#   a) versions apply to resources
# or
#   b) versions apply to representations

# and there is some temptation, for generality, to try to go down the
# road (b), but I want to argue that choice (a) is the choice you should
# make.

Yaron responded:

> I say we take the weasel way out and support both. The draft already allows for this.

But actually, I meant to make a stronger case that you should NOT try
to support choice (b): that is, don't try to allow for 'versioning' to
apply to resources that don't have URLs. The reason that you shouldn't
is that you'll have to invent some way of referring to the
thing-that-is-versioned in order to talk about the version of it that
you want, and that doing so will be hard, and you'll wind up with
something that looks enough like a URL in the first place that you
might as well have just required there to be a URL anyway.

The primary reason why content negotiation ALLOWS for multiple
representations without specific URLs for each of those
representations is to support those situations where the
representation is computed on-the-fly, e.g., different charset
encodings (EUC, Shift-JIS) of the same Japanese document, different
image representations (GIF, PNG, JPEG) of the same original image, or
just different pages constructed on the fly from a database.

I'd claim that in all of those situations, 'versioning' will not apply
to the individual representations anyway.

Are there any situations you can imagine or explain where the
versioned representations don't conveniently have URLs but should be
versioned independently?

Received on Thursday, 31 October 1996 14:01:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:09 UTC