- From: Judith Slein <slein@wrc.xerox.com>
- Date: Tue, 11 Feb 1997 07:29:20 PST
- To: Yaron Goland <yarong@microsoft.com>
- Cc: w3c-dist-auth@w3.org
At 08:43 PM 2/7/97 PST, Yaron Goland wrote: >1. It is impossible to require that the end of a link point back to its >source as this could require a server to server interaction and we do >not wish to involve ourselves in those issues. As has been previously >indicated, server to server issues are a quagmire and we don't want to >get stuck there. It is felt we can provide a useful specification w/out >having to deal w/server to server. Speaking for the document management camp, attributes are centrally important to the services we provide. And probably the most important use of attributes for us is as a way to search for documents. That means that we have to be able to figure out what document a given attributes belongs to. Will Microsoft have an interest in this, too? You can already assign attributes, including custom attributes, to documents created by MS tools. Surely the day is coming when it will be possible to search based on the values of those attributes. Will the Web be part of this picture? This could push us in one of two directions: Either we could bite the bullet and think about server to server interaction, or we could give up the strategy of treating attributes as resources connected to documents by links. (Of course, there are many applications around attributes that do not involve search, like resource ratings. And we could elect to support only these, but I don't like the idea of defining an attribute mechanism that cannot support search -- then somebody else will just have to develop a competing mechanism that can.) > >2. There have been a number of proposals for a mechanism to allow for >the bundling of multiple HTTP messages into a single message. For some >time the spec used to refer to a application/multipart that would allow >for the bundling of messages. This mechanism can be implemented >independently of DAV so I do not believe the DAV group should concern >itself w/it. However this mechanism will solve the problem of setting >multiple link values at once. I agree that somehow using MIME multipart content could solve this problem, but I'm not sure it can be done without making some change someplace in DAV to accommodate it. Did you have in mind that each body part of the multipart message would itself be a SETLINKVAL request? Then what kind of request is the top level message that has the multipart/mixed as its body? I'll send separate mail on the Warwick Framework which tries to do some bundling of attributes, potentially using MIME multipart content to do the bundling. > >3. There is nothing in HTTP or DAV to prevent a server from acting as >you have indicated. The ability to discover this behavior is the basis >of the *HEAD commands. However it is becoming clear that there is not >sufficient interest to justify these commands. > >4. It is up to the server to determine what links it will and will not >allow. Furthermore it is up to the server to create links whenever the >mood strikes. > >The DAV spec does not prevent the server from creating, deleting, and >moving resources/links at any time it so desires. Rather, the DAV spec >describes how clients indicate what it is they wish to have done. The >results of every method, as they apply to links, are largely undefined. >This undefined behavior is required in order to allow servers to perform >as needed. However, we do provide a discovery mechanism, the link names. >Each link name is a token which should be registered and whose >definition will be generally available. This tells the client what to >expect from the server. 3/4 are related to the controversy we had at Irvine about how much flexibility we should allow servers, how much discovery responsibility we want to put on clients, etc. The group needs to come to some agreement on these questions before the next rev of the spec. My own inclination is to keep it simple. But by hiding the complexity of the situation from the client rather than by constraining the server. We might provide a flag on the MOVE, COPY, and DELETE requests so that the client can request that user attributes be / not be moved, copied, or deleted with the resource. If the server cannot comply or has a policy against it, the request fails. If the client doesn't use the flag, the server does whatever it likes. Again I want to point out that without back links from an attribute to its resources, the server cannot implement an intelligent policy. > >5. This information MAY be associated w/the definition of the link >token. OK. Syntax needs to be defined. > >6. It has been assumed that the linkschema return format would indicate >if arbitrary link tokens are supported. OK. Syntax needs to be defined. > >The above are the answers for the link issue. Attributes are more >complex. Links provide the infrastructure for attributes but do not >solve all attribute problems, like search. In the coming weeks I will be >posting a proposed standard for how to deal w/the attribute issues >detailed in your letter. I am currently working on that proposal. Looking forward to seeing it. Thanks for your thoughts on links in the meantime. --Judy Name: Judith A. Slein E-Mail: slein@wrc.xerox.com Internal Phone: 8*222-5169 External Phone: (716) 422-5169 Fax: (716) 265-7133 MailStop: 128-29E
Received on Tuesday, 11 February 1997 10:27:00 UTC