W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2002


From: Roy T. Fielding <fielding@apache.org>
Date: Thu, 27 Jun 2002 11:13:05 -0700
Cc: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
To: "Jason Crawford" <ccjason@us.ibm.com>
Message-Id: <86A9237C-89F9-11D6-BE63-000393753936@apache.org>

> I assume the following questions (and perhaps more) need to be answered 
> (by the DAV:source property). I don't think it's acceptable to say that 
> the answer varies and that the client just know the mapping function. 
> I've explained why above. I think we need to perhaps admit that the 
> answer will vary from server to server, but that some aspect of WebDAV 
> (presumably the DAV:source property) tells the client how to get the job 
> done.
> 1) An author wants to create a dynamic web page using an implementation 
> he has. The URL where he wants the dynamic content served is currently 
> unmapped. Where does he PUT the implementation to create the mapping? (I'
> m assuming an automatic mapping process.)

It will depend on the server.  That is true of all name creation 
whether they be static or dynamic.

> 2) An author wants to browse the code he submitted as an implementation 
> of a resource. At what URL does the author do the GET? (I think we answer 
> this with DAV:source.)

The source property tells the client where to go next.

> 3) A dynamic page is being served at a given URL. The author wants to 
> update the implementation of that dynamic resource. Where does he PUT the 
> updated implementation? (I think we've answered the basic form of this 
> question via the dav:source propety. Questions like whether the update 
> will be refelcted immediately can be answered later.)

The dynamic content resource will point to other resources that the client
might be interested in authoring to change the content of both resources.

If the server is capable of handling PUT on a "dynamic content" resource,
then it may also support direct editing of the resource.  Day Software's
products support that kind of editing, but as far as the client is 
it is just performing methods on a WebDAV resource.  There is no difference
between the two EXCEPT that there are some circumstances when the client
needs to be encouraged to go elsewhere (such as when the author wishes to
edit a presentation template).  The principles are the same.  A source
property is merely a mechanism to supply metadata for a relationship
between two or more resources.

> 4) An author wants to no longer serve dynamic content at a specific URL. 
> What URL does the author DELETE?

The URL they want to DELETE, which, depending on the implementation, may
result in a suggestion to the author that they need to DELETE some other
resource instead (or as well).

> 5) Make sure the answers to the above question still work in concept for 
> resources that would list multiple DAV:source resources.

They work for resources in general.

> 6) Make sure the answers to the questions above don't cause problems for 
> servers that require explicit client controlled mapping operations.

A server that requires explicit name bindings will naturally require
operations on those bindings that make them explicit.

> I'm sure I've missed some other fundamental questions, but the 4+2 above 
> seem like a good easy to understand start.
> I do think it's acceptable to say that DAV:source only solves 2 & 3 and 
> we'll solve the other questions later. In doing so, in the spec we can 
> clarify what DAV:source is NOT doing so that it doesn't get misused. We 
> also should mentally envision how we'd solve the other problems to insure 
> that what we are doing now will not prevent us from solving the remaining 
> problems later.

The purpose of the source property is to allow a WebDAV-able resource to
supply information to an authoring client regarding the nature of its
underlying implementation by providing links to other resources that
make up that implementation.  That's all.  It doesn't need to do anything
more to justify its existence.

Received on Thursday, 27 June 2002 14:15:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC