W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1997

RE: New Requirements Draft

From: Yaron Goland <yarong@microsoft.com>
Date: Wed, 27 Aug 1997 14:56:39 -0700
Message-ID: <11352BDEEB92CF119F3F00805F14F485037BC203@RED-44-MSG.dns.microsoft.com>
To: "'Andre van der Hoek'" <andre@bigtime.cs.colorado.edu>
Cc: (wrong string) ürst'" <mduerst@ifi.unizh.ch>, "'Judith Slein'" <slein@wrc.xerox.com>, w3c-dist-auth@w3.org
If you are doing variants in HTTP then you are using accept headers. If
you are not using accept headers and are working in HTTP then you are
not doing variants.
	It really is just that simple.
			Yaron

PS I fully understand the difference between a requirement and a
solution, however unlike versioning, which HTTP is silent on and
therefore we are free to create our own mechanisms, HTTP is NOT silent
on variants therefore we MUST use their mechanisms. The solution has
been forced upon us.

> -----Original Message-----
> From:	Andre van der Hoek [SMTP:andre@bigtime.cs.colorado.edu]
> Sent:	Wednesday, August 27, 1997 1:49 PM
> To:	Yaron Goland
> Cc:	'Martin J. Dürst'; '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
> 
> Not necessarily, that is the road that the Configuration Management
> community 
> has been taking for the past 20 years since it has been defined by
> Tichy the 
> way I described. It has been non-confusing, non-madness, and commonly 
> understood throughout the software development community to have this
> meaning.
> 
> > 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?
> 
> I have done so.
> 
> > 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.
> 
> Again, you define variant in terms of a *solution*. We are talking
> about a requirements document here, which should have nothing to do
> with accept headers etc., but instead should contain an abstract
> definition.
> 
> Also, one of properties WebDAV is talking about is versioning. You
> create a separate mechanism for that, and the server is supposed to
> serve up particular versions. Sounds like exactly the same problem to
> me, but in one case you dismiss giving a solution and put it as
> "server-issue", in the other case you completely embrace a solution
> (i.e., the versioning HTTP primitives bing created). To me there is no
> reason to make this distinction.
> 
> === Andre ===
Received on Wednesday, 27 August 1997 17:57:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:43 GMT