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

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes
> Sent: Monday, March 04, 2002 11:11 PM
> To: DAV
> Subject: RE: DAV-Enabled field (was RE: A case for GETSRC)
>
>
> >The most fundamental question from a data modeling perspective
> >is the following: "Is the source the same entity as its output?"
> >Julian and I agree that it is not. RFC2616 section 9.3 says
> >it is not. Julian has provided examples below, including the
> >case of multiple outputs from the same source supporting that
> >position.
>
> I've given in on the source-vs-display URI.  In fact, I've always
> acknowledged that it is a perfectly good model.  What I'm trying to
> do is allow people who only use DAV for editing sources to not have
> to do extra configurations to make it happen.
>
> All I'm asking for at this point is some way for server implementors
> to know when a GET arrives from a DAV client.  A DAV-Enabled (or
> whatever) field on the requests would do that.  I'm not trying to
> break the model, or add new methods.  I just want to know when a DAV
> client is GETting a resource vs a normal web client.

This *is* the problem. GET is GET. It's an HTTP method. Once you are making
it depend on the type of client, you *are* breaking the HTTP model.

> Why?  Because what most users expect is to be able to edit their
> pages at the same URI.  I realize that doesn't fit your model, but it
> is what most people really want from DAV.

People want to send around URL that point to output resources. They *also*
want to send around URLs that point to source resources. This isn't possible
if the URLs are the same.

Now what?

> Even assuming we were to implement a way for our DAV to map sources
> onto some user-configurable alternate URI space with a minimal amount
> of configuration, one of the first things people would ask us is why
> they can't use the same URIs for DAV and for their web browser.  And
> they aren't going to understand the data modeling argument.

But maybe they would be able to understand my previous argument?

> I think having this field would:
>
> 	(a) speed up the adoption of DAV by solving a serious problem
>
> 	(b) retain the clarity of the data model and make it clear
> that a good implementation would have separate URI spaces
>
> 	(c) ultimately encourage use of DAV:source, since lots of
> people will finally be using DAV and start to understand the
> advantages of source vs display URIs
>
>
> I realize adding such a field would not contribute materially to the
> data model or the theoretical soundness of the protocol, but it would
> remove a major headache from the configuration and management from
> most DAV servers.

I disagree. Your proposal breaks GET in a very fundamental way.

Received on Monday, 4 March 2002 17:33:57 UTC