Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 12 Jun 2002 16:20:49 -0400

I agree with Greg on all these issues.  The DAV:source field provides a
valuable standardized redirection to the "thing you have to modify in order
to get the thing you are looking at to change".  In many cases, it will be
sufficient to bring the source resource into your editor, make some changes,
save it, and refresh the page for the resource you were originally looking
at.
In more complicated scenarios, it at least points you to the right
neighborhood,
and you (or your client) can take advantage of any knowledge you have about
how authoring is done in that scenario.  This is an extremely valuable
function
that can be done with just a standard way of storing the "source" pointers.
From my perspective, even the "role" field is a valuable, but not essential
addition.

Cheers,
Geoff

P.S. And lest anyone forget (:-), I would want the href (and role info,
if we standardize on it) to appear in XML elements, not in attributes,
for compatibility with current WebDAV marshalling.

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 4:05 PM
To: Lisa Dusseault
Cc: 'Julian Reschke'; 'Webdav WG (E-mail)'
Subject: Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

>>> 1. Must the resources pointed to by the SOURCE header be
>>> WebDAV-compatible?
>>
>> a) What is the definition of a "WebDAV-compatible" resource? Being the
>> member of a WebDAV collection?
>>
>> b) I'm tempted to say: no.
>
> If an OPTIONS response for the resource includes the DAV: header with 
> level
> 1 or 2 support, it's a WebDAV resource.  If the answer is "no it's not a
> WebDAV resource", then how is authoring of the dynamic content possible?

That is not relevant.  The resources might just as easily be ftp or file 
URLs,
or might only be authorable by someone with authorization or coming from
a particular IP address.  Identifying the source does not imply 
authorability
on that resource, nor does it need to in order to be useful to the user.

>>> 2. Must the source property point to ALL the files involved in
>>> producing the result?  Be careful here -- there could be data files as
>> well as source
>>> code, libraries, build files, etc.
>>
>> I don't think that's feasible.
>
> If it's not possible to view and edit or replace all the files involved in
> producing the result, then how is it possible to authoring dynamic 
> content?

How is it possible to author an e-mail message when some of the message
header fields are generated?  That question is simply not relevant to
the issue of identifying the source of dynamic content when the server
does have a URI for that content.

>>> 4. Clearly in order to get the source code for a dynamic resource, the
>>> client must do a GET to the URL(s) in the source header. But what URL
>>> should the client send PUT to?  Does PROPFIND address the source
>>> code or the output?
>>
>> Source and dynamic resources are different resources with
>> separate URLs. All
>> HTTP/WebDAV methods operate on the respective request URLs.
>
> Compare with the next question/answer to see the inconsistency with this
> position.

They are different resources.  The effects of a particular method on any
particular resource are defined by that resource.  The source for one
resource may itself be a dynamic content resource with its own source URI.

>>> 5. What does it mean when a dynamically-generated resource is the 
>>> source for
>>> a COPY request?  Is it different when it's the source for a MOVE 
>>> request?

If that isn't already defined by RFC 2518, then it isn't defined for any
resource.  There is no distinction on the Web between dynamic and static
content.

>>
>> I think that's open to discussion. For COPY, it seems it
>> would make sense to
>> require that the newly created resource must behave as the original
>> resource, so it should still be a dynamic resource, and have
>> the same source
>> links. MOVE obviously MUST move the resource -- and if this
>> can't be done by
>> the server, the request must fail.
>
> All right, now we see the inconsistency.  Say we have a dynamic resource,
> "foo", and the server reports that there's only one source file,
> "foo-source".
>
> If all methods operate on the respective request URIs, that means that a
> COPY request to foo must operate on the dynamically-generated content, not
> the source.  So wouldn't that mean that a snapshot of foo is copied to the
> destination?  It wouldn't be a dynamic resource.  Fair enough. Presumably 
> we
> can COPY foo-source to get a second dynamic resource.  But what happens if
> you MOVE foo?  Does it operate only on a snapshot of the dynamic resource?
> What does that mean?

Why is this confusing?  If a resource does not allow COPY, then it would
not respond to COPY with 200.  There is no magic being done behind the
curtains.  What does COPY mean for RFC 2518?  It means the same thing for
both dynamic and generated resource -- there is no difference between the
two.  Some resources will simply not allow COPY or MOVE.  That is why it
is NECESSARY to point to the source of the resources, since those other
resources are the ones that usually can be copied or moved.

>>> 6. How does a client *create* dynamically-generated Web pages? Think of 
>>> all
>>> the problems with that - where should the client upload new source 
>>> files?
>>> How can the client specify what URL in the main repository is actually 
>>> an
>>> invocation to handle this dynamic resource?
>>
>> Right now I'd say that's server-specifc. Depending on how dynamic 
>> resources
>> are implemented, it's hard to see how there can be a generic way to 
>> author
>> them.

There are many ways in which a namespace can be constructed on a server.
The user creating a service generally knows what they are doing or are
following the instructions provided to them by the server owner.

>>> 7. How does a client add a new source file to an existing set of source
>>> files?  E.g. assume I want to modify a JSP to call a new object in a new
>>> library.  That library is not on the server yet.  How do I upload
>>> it?  Where
>>
>> Again, I think this is server-specific. The server may allow you to PUT 
>> the
>> file anywhere, or at a specific location. And of course a server may 
>> allow
>> PROPPATCH on the source-set property.
>
> Seems to me both 6 and 7 are essential features.  I don't understand how
> authoring dynamic content is supposed to work unless we offer them.

The degree to which the server's implementation space is itself a WebDAV-
enabled name space is dependent on the particular site configuration and
none of our business.  If they are authorable, the user will be able to
author them.  There is no need, nor any desire, for such security-sensitive
activities to be automatically handled by authoring tools.

>>> to? How do I indicate to the server that it's a source file and not a
>>> content file?
>>
>> What's the difference?
>
> A new source file is a new file which will be interpreted or compiled by 
> the
> server in order to produce dynamic content.  By "content file" I meant
> static Web page, or regular resource.  How can the client create a new
> source file and let the server know it's supposed to interpret or compile
> it?

The server will either already know how to interpret its name space or
the client will author (via another URL) the appropriate configuration
or binding needed to enable the dynamic resource.

....Roy

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 24 Jun 2002 22:50:50 -0400

I agree that 2 and 3 are sufficiently important use cases
to support the DAV:source protocol element.  I think one
can make a reasonable case that 4 is also handled by
DAV:source (i.e. it is a reasonable extension of 3).

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Monday, June 24, 2002 1:57 PM
To: Clemm, Geoff
Cc: 'Webdav WG (E-mail)'
Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

I've spent some time trying to list the questions brought up in this
discussion and the answers offered. I can post that list later. 

In building the list I found Lisa's questions interesting. For the most part
the questions in the first half of Lisa's note [1] seem to be answered, but
Lisa's later questions about mapping did not seem to be. The mapping issues
seem to be an important issue for the source property, and the answer can
vary from server to server. Are answers also hinted that the client has to
know how the server does mappings, as they do now, but if that is our
answer, then I'm not sure why we are defining the DAV:source property. 

[1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0170.html

Can everyone do a mental reset and review why we have a source property?

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.)

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.)

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.)

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

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

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

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.

J.

------------------------------------------
Phone: 914-784-7569, [email-masked]

---

From: "Jason Crawford" <[email-masked]>
Date: Thu, 27 Jun 2002 11:44:56 -0400

> to support the DAV:source protocol element.
Noted.

> I think one
Four.  That's the items that says we need a way to
know what URI to delete to remove the mapping of this
resource at this URI.

I think that would require a bit more discussion... but
we can do that now...

If a resource has multiple sources listed, we'd need to
designate which one is the one that causes the deletion
at this URI.   That's why I suggested that a single
resource be able to have multiple roles.  I was
envisioning a DELETE role... among others.

Is this reasonable?

There is also the case of a dynamic resourse that is
mapped to at URI via some manual/explicit process. An
example would be some servlet engines I've seen.  There
is a registry that says that a certain class handles
requests at a certain URL.  There must be other examples.
I assume in these servers, it's an unmapping process
that's really what is wanted.... not necessarily
the destruction of the implementation of the resource
at that URI.

In this case, the resource to delete might vary.

1) The URI itself might be deletable.
2) The server might create a virutual resource just for
    the purpose of giving the clieting something to delete
    to cause the unmapping.
3) The server might have some other process for unmapping
    the resource and not support the DELETE method to do
    the unmapping of that resource.

Is all of the a reasonable analysis?  If so, do we allow
case (3)?  If so, what do we suggest the server should
do to denote behavior (3)?

J.

---

From: "Jason Crawford" <[email-masked]>
Date: Thu, 27 Jun 2002 15:26:23 -0400

Okay... Julian, Geoff and Roy makes 3:0.  Unless I hear some dissenting
opinions, it looks like we should make it clear in the spec that the dav:
source property is only serving a specific purpose (2, 3, and possibly 4)
and use beyond that is not interoperable.

Wow... we might actually resolve this issue this time.  :-)

J.