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

>  > >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?

No, I don't agree that this is a problem.  In most cases it is the 
_desired_ effect because users generally only use DAV for messing 
with their source, and they don't care about using DAV with the 
output.  But they _do_ want to use the same URLs for both editing 
source and viewing output.  If the administrator wants something 
different he should be able to configure his server accordingly.

Separating "source" and "display" into different resources with 
different URIs is a very nice idea, but not terribly useful to most 
people.  Maybe once the DAV:source property is fixed and DASL gets 
off the ground, this will become a more useful configuration.

I believe the DAV spec needs to allow both scenarios, and the 
simplest way to do that is to either:

	- have a definitive way to know when a client expects the source or
	- know when a GET method originates from a DAV client

cjh

-- 

Received on Wednesday, 6 March 2002 14:13:37 UTC