RE: Internationalization Requirements

Now wouldn't it be more efficient to include this information as part of the response to an INDEX method or (preferably) as part of the entity header rather than requiring each update to first attempt a PUT (which might fail) evaluating the response and then redoing the PUT on the correct URL? This would allow the client to obtain this information through the GET or HEAD methods. It would also allow a client to present the author with a list of language versions for a particular resource without having to perform a PUT (or some other bogus method) to get the list.

According to the current standard the server SHOULD only present the user with a list of the entity characteristics and locations in the case that the method is not HEAD and only if the request cannot be met or is ambiguous. WebDAV should require that both GET and HEAD methods include the language variant information.

cheers
Dylan

----------
From: 	Martin J. Duerst[SMTP:mduerst@ifi.unizh.ch]
Sent: 	Montag, 28. Juli 1997 07:26
To: 	Roy T. Fielding
Cc: 	Dylan Barrell; w3c-dist-auth@w3.org
Subject: 	Re: Internationalization Requirements

On Sat, 26 Jul 1997, Roy T. Fielding wrote:

> >You may be right. I had a look at the HTTP 1.1 spec, and I only
> >found 10.4.7  406 Not Acceptable. The behaviour described there
> >is not very deterministic. Maybe Roy can help out?
> 
> That is why we have a WebDAV working group.  Both the 300 and 406
> response bodies were left unspecified because the intention was that
> they be specified by a group that actually had time to study the
> problem in detail and come up with a [hopefully] better solution
> than some off-the-cuff invention of mine.  It was one of the WebDAV
> to-do items, last time I checked.

Many thanks for this information. If we assume that the response
bodies to be designed will include language information (or any
other information needed for other kinds of variants) in an uniform
way (which should not be too difficult for language information),
then this should mean that reasonable clients can be written that
do whatever necessary for language variants, without knowing the
naming scheme used at the server for distinguishing language
variants, FOR ALL THOSE VARIANTS THAT ARE ALREADY EXISTING.

Not yet covered is the creation of new variants, but this should
also be covered. Otherwise, we have a half-way solution of rather
limited usability. So we need some way of asking the server:
"What actual URL would you give to a Spanish version of this
document" so that we can later do a post on this actual URL
and the document is correctly created, or it has to be possible
to do a POST directly on the "abstract" URL with "Content-Language: es"
and get the right actual URL created. Figuring out the actual
URL may indeed not be easy for the server, but if the server can't,
who would?


Regards,	Martin.

Received on Monday, 28 July 1997 09:08:02 UTC