W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

Re: Source header instead of property? (was Re: A case for GETSR C (or other mechanism to that effect))

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 1 Mar 2002 15:19:11 +0100
Cc: w3c-dist-auth@w3c.org
To: "Clemm, Geoff" <gclemm@rational.com>
Message-Id: <4D12C9DC-2D1F-11D6-8C26-00039384827E@greenbytes.de>
Not speaking of the problem how the heck google is to
display search results for such source documents...

But by then we probably have extended HTML to handle
<a href="http://xyz/doc.asp" translate="F">link to interesting 
in all browsers.

Piece of cake really.


Am Freitag den, 1. März 2002, um 14:32, schrieb Clemm, Geoff:

> The special header would effectively break the ability for Web Search
> engines (e.g. google.com) to index the resource space, unless they were
> upgraded to re-crawl the URL space with the "Translate" header, and
> then store in their cache that the "Translate" header needs to be
> included in the request.  Analogously, it becomes impossible to just
> embed a URL in a mail message that refers someone to the source ...
> you'd have to somehow include an annotation that says "and use the
> Translate header when you request this URL".  These kinds of reasons
> make me strongly object to either the GETSRC method or a Translate
> header.
> Cheers,
> Geoff
> -----Original Message-----
> From: Erik Seaberg [mailto:erk@flyingcroc.com]
> Sent: Thursday, February 28, 2002 11:41 PM
> To: w3c-dist-auth@w3c.org
> Subject: Source header instead of property? (was Re: A case for GETSRC
> (or other mechanism to that effect))
> The only reason for GETSRC or "Translate: F" is to overload one URI for
> both the source and output resources, but it seems to me that breaks a
> lot of features.  We suddenly need to duplicate most properties
> ({DAV:}getsrcetag, {DAV:}getsrccontenttype...) to deal well with 
> caching
> and editing.  You're likely to go through content negotiation and wind
> up editing just one variant without even realizing it (or worse, store
> one variant at the vanilla URI's corresponding filename and inhibit
> negotiation!).  And Web development being the way it is, it's almost
> certain that when GETSRC seems to usually work on simplistic servers,
> hardly any clients will know how to use {DAV:}source in the cases where
> it won't.
> But if the output resource does have a separate URI, a PUT or LOCK or
> PROPPATCH on it probably doesn't make sense, so it's not likely that
> many modules will bother being compliant enough to answer a PROPFIND
> request for {DAV:}source (in my case, GET clients and DAV clients are
> talking to different servers entirely).  An HTTP header containing the
> source URIs for an output resource (only for authenticated requests?)
> should be much easier to implement; would that be more likely to be
> widely adopted and used?
Received on Friday, 1 March 2002 09:19:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:25 UTC