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

Based on basic data modeling considerations, I agree
with Julian that the source(s) and the output should not 
be considered variants of the same resource. Hence, 
they would seem to require different URI's.

Alan Babich

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, March 01, 2002 5:41 AM
To: w3c-dist-auth@w3c.org
Subject: RE: Source header instead of property? (was Re: A case for
GETSR C (or other mechanism to that effect))


Thanks, Geoff.

Sorry if I keep repeating myself, but:

are the source and the output resource 

a) different resources, or

b) variants of the same resource [1].

I say "a)", and thus they need to have different URIs.

Julian


[1] RFC2616, section 1.3

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, March 01, 2002 2:32 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: Source header instead of property? (was Re: A case for
> GETSR C (or other mechanism to that effect))
> 
> 
> 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 16:12:34 UTC