W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1996

RE: Request for Comment

From: Yaron Goland <yarong@microsoft.com>
Date: Thu, 31 Oct 1996 14:50:52 -0800
Message-ID: <c=US%a=_%p=msft%l=RED-44-MSG-961031225052Z-7731@INET-03-IMC.itg.microsoft.com>
To: "'Judith Slein'" <slein@wrc.xerox.com>
Cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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
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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:14 UTC