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

CJ,

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> Sent: Tuesday, March 05, 2002 12:37 AM
> To: DAV
> Subject: Translate (was RE: DAV-Enabled field (was RE: A case for
> GETSRC))
>
>
> >I think "Translate" is much clearer than "DAV-Enabled" because
> it at least
> >it says what you want.
>
> Then let's spec Translate and make it part of DAV.  Interoperable
> implementations exist.

Just because there's a proposal that I think is even worse doesn't make the
Translate header a good solution.

If you want to go ahead, you'll have to:

1) Clearly define what Translate means for every HTTP method defined in HTTP
1.1, WebDAV (and preferably ACL and deltaV).

2) Note that ths definition must be compatible with what the base specs do
today.

> >As I've said numerous times: make up your mind whether the
> source and it's
> >output are the same resource or not. If they are, you can use
> "Translate".
> >If they aren't, they will have different URLs.
>
> They are if the administrator says they are.  Again, that's policy.
> I don't set policy, I just make the tools my users want.

I personally do not agree that this is a question of policy. It should be
*consistent*.

> >HTTP takes the position that they are different resources (see
> introduction
> >to "GET"), and I don't see how a different working group could
> change this
> >view.
>
>     The GET method means retrieve whatever information (in the form of an
>     entity) is identified by the Request-URI. If the Request-URI refers
>     to a data-producing process, it is the produced data which shall be
>     returned as the entity in the response and not the source text of the
>     process, unless that text happens to be the output of the process.
>
> If DAV is responsible for processing GET, and it makes the policy
> decision that the correct output is the the same as the source text
> (and the security sub-system gives the go-ahead) then it should be
> able to return the source text if that's the policy.

DAV is not responsible for "processing" anything. DAV defines semantics of
new HTTP methods, and in particular, it doesn't define GET.

> >  > I don't see that
> >  > it would be so horrible to allow the idea that one of the
> >>  representations of a resource could be its raw source.  What
> >
> >The most horrible thing being that the source resource doesn't
> have it's own
> >URL and thus cannot be properly referred to using just a URL. Could you
> >please explain why you think this particular problem *isn't* relevant?
>
> Because in practice most people don't want to view the source in a
> browser.  They use DAV for working with their source, and they only
> use it for working with their source.

It's not a question of seeing the source in a browser, it's about being able
to *refer* to it. What do you do when somebody sends an email asking for a
link to the source resource? Do you send the URL and add wording to explain
what program will be needed to open it?

> >>  representation you receive is a matter of server policy.  And some
> >>  way of identifying that the server is talking to a DAV client would
> >>  help with managing that policy.
> >
> >No, "DAV-Enabled" vs. "Translate" is the completely wrong approach.
> >Following your proposal, a "DAV enabled" client never would want
> to GET the
> >output resource.
>
> Sure you could.  If the administrator decides that's a good thing,
> and wants to separate the URIs for source and display, then you could
> certainly GET the output resource with your DAV client.  And if
> DAV:source ever gets fixed and implemented then you could even have
> automatic linking between display and source  URIs.  Its all about
> how the administrator wants to set up the policy.

OK, so you agree that this is a problem with your proposal, while it isn't
with separate URLs?

Received on Wednesday, 6 March 2002 07:01:50 UTC