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

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 
source</a>
in all browsers.

Piece of cake really.

//Stefan

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