- From: Ron Daniel Jr. <rdaniel@acl.lanl.gov>
- Date: Tue, 18 Mar 1997 12:07:03 -0700
- To: Yaron Goland <yarong@microsoft.com>, w3c-dist-auth@w3.org
At 01:04 AM 3/18/97 -0800, Yaron Goland wrote: Yaron gave some very good reasons why headers were not a good way to handle metadata. He mentioned namespace collisions, processing load, wasted bandwidth, etc. Despite understanding these problems, he goes ahead and recommends that headers be used for dealing with metadata in order to keep the model "light". He cites the example of small pieces of information such as modification dates to justify this decision. I agree with Yaron to a limited extent. Handling *all* metadata as resources is inappropriate. However, it is my considered technical opinion that handling *all* metadata as headers is just as inappropriate as handling *all* metadata as separate resources. Some descriptions, such as Content-length, Last-modified, Content-type, ... are best carried as headers. Other descriptions, such as detailed revision histories, provenance tracking, and bibliographic descriptions, are best carried as separate resources. WEB-DAV needs a metadata architecture that accommodates both. Furthermore, it is not that difficult. When we send resources (original or "metadata") between clients and servers we can use MIME headers for the "light" metadata about particular resources, while still allowing separate metadata packages to carry descriptions that are too heavyweight for headers. We can send those resources in multipart message bodies, and can use message/external-body if we want the client to know of the existence of some big package but don't want to clog the lines by actually sending it. If we can agree on an architecture that isn't all one way or the other, then we can advance to more meaningful arguments, like just what new headers (if any) we need to define, what packages (if any) we initially want to support, how (or whether) their elements can be used in both contexts, and how we can do queries on them. It seems to me that to make progress, this group needs to agree on a few simple points and stop arguing over them. Can we start by agreeing on two things: 1) Neither headers or separate resources meet all the requirements on metadata in WEB-DAV, so we will need a combined solution. 2) All communications between clients and servers will take the form of MIME messages, and frequently those messages will be multipart/related? The last seems uncontroversial to me, but then I have been accused of being an optimist :-). I hope that the former is also uncontroversial given the last few messages on this list. >In order to handle the assignment, modification, discovery, and removal >of meta-data I propose adding three new methods - METAPOST, METAGET, and >METADELETE. Assuming we agree that some metadata is handled by headers and some by separate resources, we can now discuss ways of editing it. For metadata held as resources, the GET, DELETE, and PUT (or POST) methods should suffice. For the smaller info carried as headers we may need methods such as you describe. I think the essential functionality of METAGET is already handled by the HEAD method. Something like METAPOST and METADELETE seems necessary. I'll skip detailed comments on the methods at this time, but there is one I just can't let go without remarks: >5 Link Attribute > >If META* is adopted then links become attributes. I propose they be >defined as follows: [...] >I also >propose removing the rule that either the source or destination must be >equal to the Request-URI. This will enable annotation facilities. I think that redefining existing parts of the HTTP spec, such as LINKs, is beyond the bounds of this WG. Furthermore, annotations can be handled under the existing constraints on LINKs. Later, Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545
Received on Tuesday, 18 March 1997 14:09:00 UTC