RE: DAV-Enabled field (was RE: A case for GETSRC)

>  > Now you are arguing circularly.  You say that because the source and
>>  generated output are different resources, they should have different URLs.
>
>Yes.
>
>>  Now you are saying that because they have different URLs, they
>>  are different
>>  resources.
>
>Did I say that?
>
>- Resources (RFC 2616):
>
>"A network data object or service that can be identified by a URI, as
>defined in section 3.2. Resources may be
>available in multiple representations (e.g. multiple languages, data
>formats, size, and resolutions) or vary in
>other ways."
>
>- URI (RFC 2616)
>
>"As far as HTTP is concerned, Uniform Resource Identifiers are simply
>formatted strings which identify--via name, location,
>or any other characteristic--a resource."
>
>
>So if two things have the same URI, they *must* be the same resource (by RFC
>terminology). If the URIs differ, they *may* be different resources.

I think we can all agree on that.

What we're disagreeing on is that the source can be the same URI as 
the output.  They can be two views of the same resource.  That is how 
most people think of it, and it would be practical to accomodate 
them.  But the current spec is very inconvenient in that it 
effectively prevents it (without explicitly forbidding it).


>  > My line of argument is that having a separate URL space for
>>  generated output
>>  >from the underlying executable doesn't work well because:
>>
>>    * the generated "resources" won't have the correct values for many live
>>  properties (other than dav:source!!!), and will probably (your words) not
>>  support dead properties
>
>Not having values is something different from not having "correct" ones. I
>simply don't see a problem here.

I think Eric mentioned that some of these values are required, so you 
can't not return them.

>  >   * creating a virtual URL space for generated outputs (as you suggest)
>>  makes the <href> linking unworkable when doing the 1-1 sitecopy semantics
>>  between local filesystems & servers that is common practice today, thus
>>  making the separate URL space idea unusable if backwards compatability is
>>  maintained.
>
>I think it is *also* common practice to replicate the source URL spaces (and
>not to touch the output URL spaces at all). In which case there's no
>problem.

It is common because it is the only way to deploy DAV under the 
current spec.  It causes no end of confusion amongst people who are 
deploying/using DAV for the first time.  It is counter-intuitive, and 
is not really useful in most situations.

>  > Julian's other argument is that you might want to have existing clients be
>  > able to edit the source just by pointing to some URL.  Well, without
>  > understanding dav:source they won't know what the URL is to use
>  > for the next
>  > GET method.  So, clearly clients will need to be upgraded either to handle
>  > Translate:/GETSRC or to handle the dav:source header.  Existing clients
>  > won't cut it, so I don't by this reasoning, anyway.
>
>Yes, clients and servers will need to be upgraded. Did I say otherwise?

Someone claimed that Translate/GETSRC would require implementation 
changes.  Eric was just pointing out that implementations have to 
change anyway because of these very issues, therefore the argument is 
irrelevant.

cjh

--

Received on Wednesday, 6 March 2002 14:28:21 UTC