RE: Request for Comment

I'm glad that you will be able to do a comparison of the work space.
Your first work space summary was very useful, as you will see in the
new draft, I have made several changes based on it.

Section 7 now reads:
7. URI Groups
Any URI, which has a representation of content type
application/container, is defined to be a URI container. Content type
application/container will use the SiteMap format. Members are listed,
added, or removed from the container by performing actions on
application/container.
The advantage of SiteMaps in this context is that they are designed to
point to other SiteMaps. In this way a hierarchy can be built and when
an operation is performed it will act recursively down the tree.

I should note that my use of SiteMap is preliminary. The specification
is in flux and may or may not eventually meet our needs. For now I am
using it as a placeholder so we can solve the truly hairy problems. In
the worst case we will just come out with our own definition.

				Yaron

>-----Original Message-----
>From:	Judith Slein [SMTP:slein@wrc.xerox.com]
>Sent:	Thursday, October 31, 1996 10:59 AM
>To:	Yaron Goland
>Cc:	w3c-dist-auth@w3.org
>Subject:	Re: Request for Comment
>
>Yaron --
>
>I'll take the action to look at the DMA spec in comparison with our work
>here.  However successful or unsuccessful DMA turns out to be, it provides a
>useful map of the problem space we are trying to cover.  I think that Dennis
>Hamilton, who has contributed largely to the DMA spec, is planning to attend
>our November meeting, so he'll be able to help with any discussion of DMA in
>relation to webdav.
>
>On the subject of containment, section 7 of the spec proposes to use
>SiteMaps as the new content type to represent containers.  I'd like to
>change the name of the mime type to application/container to emphasize the
>fact that it can represent something other than a URL hierarchy.  For the
>case where it's a document management system that stands behind the Web
>server, it may be desirable for the location parameter of a node in the
>SiteMap to be expressible as something other than a URL.
>
>I think it would be very useful to be able to do recursive deletes,
>undeletes, and destroys on resources referenced by a container.  
>
>At 09:29 PM 10/30/96 PST, Yaron Goland wrote:
>>I wanted comment on these ideas before I did anything with them. Note that 
>>the following contains very rough drafts.
>>		Thanks,
>>			Yaron
>>
>>
>>I realize that DMA is about as popular as an Electro Magnetic Pulse but 
>>someone (read: NOT ME) should really go through the DMA spec, 
>>http://www.aiim.org/dma/spec75/index.html, and see how well we measure up.
>>
>>Currently there is no way to delete the contents of a directory. A 
>>directory is really just a sitemap file which allows one to group various 
>>unrelated URIs together. However if one were to want to delete all the URIs 
>>in the directory one would have to send delete requests for each URI. The 
>>logic extends if one wants to delete a directory and all its sub 
>>directories. One of the reasons for this behavior is that many of the 
>>common container commands, such as copy and move, have no meaning in this 
>>context. If I have a container with URLs foo/bar and bar/foo then the only 
>>way to copy them is to specify for each one where they are to go. If I 
>>order "copy foo/bar and bar/foo to foobar" what does this mean? However 
>>delete and undelete are different, they have a very obvious meaning in the 
>>context of our containers. Should we add headers in the mime-type for 
>>delete, undelete, and destroy to allow the command to be applied to the 
>>contents of a directory in a possibly recursive manner?
>>
>>
>>
>Name:		Judith A. Slein
>E-Mail:		slein@wrc.xerox.com
>Phone:  	8*222-5169
>Fax:		(716) 265-7133
>MailStop:	128-29E
>

Received on Thursday, 31 October 1996 17:50:57 UTC