RE: Distributed Authoring Proposals

1	Content-Nature Header

1.1	Problem Description

It is often important to be able to search for content based on data
type. For example, "Please find all documents which contains the word
"shmoo"". However in HTTP a resource is a resource is a resource. There
is no way to tell anything about the resource, such as, is it a
document? A collection? A database record?

1.2	Proposal

A new HTTP header be introduced called Content-Nature. This header is
passed in with a request and is returned in a reply.

ContentNature = "Content-Nature" ":" 1#ContentIdentifier
ContentIdentifier = URI

1.3	Discussion

As for Larry's example, the message would have a content-nature of
"email" or "discussion list posting". The same mystical group that will
provide us meta-data names and formats would standardize the set of such
values.

2	DAV.ResourceLink Link

2.1	Problem Description

The proposal before this group for handling structured resources
requires that members of the structure use the URI of the structure as
the base of their URIs. However there are times when one wishes to
include URIs in a structure which do not use the structure's URI as a
base.

2.2	Proposal

To provide a link type which when defined upon a structure using the
LINK method will result in the resource including the URI in the results
of a STRUCTURE method. The source of this link is to be the resource the
link is defined on. The destination must a URI that does not have the
source as its base. The type will be DAV.ResourceLink.

2.3	Discussion

I expect that DAV.ResourceLink will end up being handled in two ways.
For links pointing to resources on the same server, the entry in the
structure result will look like any other entry, including the listing
of whatever meta-data the server likes to return in its responses.
However, in the case where the resource is on another server I expect
that servers will list the URI and leave it at that.

If this proposal is accepted we can be completely rid of ADDRESOURCE and
REMOVERESOURCE.

3	PropagateLinks Header

3.1	Problem Description

A structured resource, by its very definition, recursively applies any
methods applied to it, to all of its members who use the URI of the
structure as the base for their URI. For sake of clarity I will now
refer to these resources as "primary members" of the structure. However
DAV.ResourceLink members of the structure require different behavior.
For sake of clarity I will now refer to resource which are linked to a
structure through a DAV.ResourceLink as "secondary members". The
secondary members are not normally considered in recursive operations.
For example, a MOVE on a structure does not cause secondary members to
be moved. Rather the links pointing to the secondary members are moved.
However, there are times, when it is desirable for secondary members to
be effected by methods executed on the resource . For example, a client
could very well desire that a LOCK on a structure effect both primary
and secondary members.

3.2	Proposal

Introduce the PropagateLinks header. This header will be included in
requests on structures. Certain methods may not allow this header, such
as COPY and MOVE, because it is impossible to determine appropriate
behavior. In that case the method should return a 412 Precondition
Failed.

3.3	Discussion

This header is meant as a replacement for the PropagateLevel header.
That header really only existed to help differentiate when a method
applied to secondary members as opposed to primary members. It is a
remnant and no longer necessary.

I would also like to comment on why PropagateLinks can not be used with
COPY and MOVE. When copying a structure whose members use the
structure's URI as their base, it is possible to concisely define where
the members of the structure should be copied. Just take the Request-URI
and use it as the new base. However secondary members do not use the
structure's URI as their base so it isn't clear exactly where they
should be copied. 

I know that some will argue that we need PropagateLevel so that it is
possible to say things like "Just copy the first 3 levels." However such
scenarios are rare and when they do appear, they tend to be more
complicated involving orders such as "Just copy the following members".
PropagateLevel only provides a crude tool. I feel it is better to
provide a clean but more limited tool in the form of PropagateLinks and
have the client formulate their requests by executing STRUCTURE and
multiple copies.


4 COPY Method

Now it is my turn to be confused. Would the request body of the PUT
contain a URI? If so, why not just use my proposed Source header in
conjunction with PUT? I agree that this would effectively rid us of
COPY.

5 DELETE Method

I believe that referential integrity constraints are out of scope for
this group. Any time you go down this road you will end up either with
MOVEHEAD and COPYHEAD or you will end up specifying server to server
functionality. The *HEAD methods show up because we will realize we have
no hope of specifying server to server functionality so in a desperate
bid to provide something, we will try to provide these sorts of
predictive methods. The server to server functionality shows up when we
try to provide concrete answers to what happens to references when they
are moved from one server to another. Either solution is a dead end. I
believe we will have to accept the compromise now used on every file
system I am aware of. If you copy, delete, whatever, within the server
you will get fully service, including link maintaince and other goodies.
If you copy between servers, you are roling the dice. The only thing
that can be guaranteed is that an entity will be transfered. This is
especially true as I expect most servers to implement COPY as a PUT.

6 UNDELETE Method

The UNDELETE method is logically equivalent to UNCHECKOUT for a
CHECKOUT. The client performed a DELETE and now they want to undo it.
Sometimes it works, sometimes it doesn't. The system is inherently
asynchronous so such behavior must be expected. As such, in what way
Larry, do you feel that this method would be non-interoperable?

7 Atomic Header

I keep thinking of how servers would actually implement Atomic and I
come to the conclusion that the introduced complexity is not worth the
small bandwidth savings. As such I remove my proposal for the Atomic
header.

		Yaron

> -----Original Message-----
> From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
> Sent:	Wednesday, March 19, 1997 9:24 PM
> To:	Yaron Goland
> Cc:	w3c-dist-auth@w3.org
> Subject:	Re: Distributed Authoring Proposals
> 
> In a previous life, I used to work on another standard where my
> greatest
> contribution to the standards effort, I claimed, was designing the
> form
> you had to fill out in order to get a change to the language
> considered.
> 
> The form had several fields, and mainly what I did (as chair of one of
> the working groups) was to get people to fill out the form correctly.
> 
> One of the most important features of the form is that it started with
> the section
> 
>     "Problem Description"
> 
> and you were required to define "what problem are you solving" before
> you could go on to the next section, which is
> 
> 
>      "Proposal"
> 
> where you described what you were proposing.
> 
> Your recent mail on "Distributed Authoring Proposals" is missing
> the "Problem Description" sections for each proposal, and it
> is a little difficult to guess exactly what problem you're solving.
> 
> 1. Content-Nature: The nature of this message is that the subject
> is "Re: Distributed Authoring Proposals", but is it the true nature
> of this message, or just another attribute?
> 
> 2. I cannot guess what Dav.ResourceLinks means from your message.
> 
> 3. COPY method
> 
> I suggest considering eliminating COPY and instead using
> PUT, but when the value being PUT is Content-Type:
> message/external-body, then the server can copy the data
> from the original source.
> 
> Copying structures and other more complex objects can be
> accomplished in the same way, or by PUTing other document
> types (e.g., multipart/related where some of the parts
> are message/external-body).
> 
> There's no point in inventing a new method when an old one
> will do fine.
> 
> 5. DELETE
> 
> The issue with Delete is exactly that of the referential
> integrity constraints. If you delete a container, what happens
> to the things contained? I think DELETE is the right vehicle
> to explore this issue. "PropagateLevel" is really unsatisfactory,
> since the required scope of deletion rarely corresponds to
> "this level down 3 levels", even in file systems.
> 
> 6. UNDELETE
> 
> I think this is so completely non-interoperable that it
> doesn't belong in the standard.
> 
> The Atomic header, while looking nice, is voodoo. Is there an
> interoperable client that would actually use this against
> arbitrary servers?
> 
> Regards,
> 
> Larry

Received on Thursday, 20 March 1997 05:09:30 UTC