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
>