RE: New Requirements Draft

After wading through this email war I have come to the conclusion that the main bone of contention is whether support for handling variants amounts to "authoring" or "configuration".

So I think we should stop arguing about the exact definition of a variant and answer the following question.

Where does manipulation of server content and the way that it is served-up cease to be "authoring" and start to be "configuration"?

In my opinion translating a resource and placing that translated resource on the server, such that a consumer who prefers her content in that language is served that language variant, amount to authoring (or more generally - web site construction) and not server configuration. Special handling for this (and this gets back to my original point made weeks ago) in WebDAV would allow the authoring client to provide an easy-to-use interface for doing this which would work with all WebDAV compliant servers.

An example of server configuration would be the activity of enabling or disabling the content negotiation for the server as a whole.

Cheers
Dylan

----------
From: 	Yaron Goland[SMTP:yarong@microsoft.com]
Sent: 	Mittwoch, 27. August 1997 16:38
To: 	'Martin J. Dürst'
Cc: 	'Andre van der Hoek'; 'Judith Slein'; w3c-dist-auth@w3.org
Subject: 	RE: New Requirements Draft

I know, I made the same mistake that everyone else did. In the first
paragraph you site I was using the term variant in the way that I think
you and Andre mean it. Of course that road leads to madness. That is why
I later defined the word variant as I understand its meaning in HTTP.
However matters only get worse because the definition given in the HTTP
spec does not necessarily match the common usage of the term in the HTTP
working group.

So might I suggest we all put our definitions down on the table so we at
least have some clue as to what we are talking about?

When I speak of "variant support" I am specifically speaking of putting
in place commands which instruct a server how it should handle accept*
headers. Thus if a client puts up a document and marks it as "the French
variant" it is expected that if the server receives accept-language:
(whatever the hell the French code is), it will return the French
version. It is this behavior which I do not wish to have specified by
DAV because I believe this is more server configuration than document
authoring. Document authoring is creating a document and putting
properties on it. One of those properties could even be "Language". But
it says nothing about how a server will server up that document. Only
that if you get the URL you PUT the document to, you will get the
document back.

		Yaron

> -----Original Message-----
> From:	Martin J. Dürst [SMTP:mduerst@ifi.unizh.ch]
> Sent:	Wednesday, August 27, 1997 1:24 PM
> To:	Yaron Goland
> Cc:	'Andre van der Hoek'; 'Judith Slein'; w3c-dist-auth@w3.org
> Subject:	RE: New Requirements Draft
> 
> On Wed, 27 Aug 1997, Yaron Goland wrote:
> 
> > We can't have a conversation where everyone is using the same word
> to
> > mean different things. I have defined what the term variant means in
> > HTTP.
> 
> You mentionned earlier what the term variant means for you:
> 
> > > > In so far as I am concerned a variant is simply "yet another
> > > > version" and requires no special handling outside of the normal
> > > > versioning mechanisms.
> 
> and in this mail, you indicate that believe it is the definition
> from HTTP.
> 
> > If you use the word variant, in a HTTP working group, it is
> > expected that you will use it to mean what it means in HTTP. If you
> are
> > referring to a concept other than the one meant by HTTP, please use
> > another term.
> 
> So let's go back to the sources (RFC 2068). For "variant", we find
> in 1.3, Terminology, on page 9:
> 
> >>>>
>    variant
>       A resource may have one, or more than one, representation(s)
>       associated with it at any given instant. Each of these
>       representations is termed a `variant.' Use of the term `variant'
>       does not necessarily imply that the resource is subject to
> content
>       negotiation.
> <<<<
> 
> For "version", it's more difficult. The word version mostly turns
> up in RFC 2068 in the sense of "protocol version" for HTTP.
> But upon careful sceening, one finds, in 19.6.2.2, Content-Version,
> the following paragraph:
> 
> >>>>
>    The Content-Version entity-header field defines the version tag
>    associated with a rendition of an evolving entity. Together with
> the
>    Derived-From field described in section 19.6.2.3, it allows a group
>    of people to work simultaneously on the creation of a work as an
>    iterative process. The field should be used to allow evolution of a
>    particular work along a single path rather than derived works or
>    renditions in different representations.
> <<<<
> 
> True, this appears in an appendix entitled "additional features".
> But it is the only place where in RFC 2068, versions have anything
> like a definition. Either you accept this as part of RFC 2068,
> in which case your statement "variant is simply 'yet another version'"
> is definitely not in agreement with HTTP terminology, or you exclude
> it from HTTP as such, in which case your statement "variant is simply
> 'yet another version'" has nothing to do with HTTP terminology
> because HTTP terminology neither defines "version" nor anywhere
> says that a variant is simply a version.
> 
> 
> Regards,	Martin.
>

Received on Thursday, 28 August 1997 03:46:16 UTC