- From: Jim Whitehead <ejw@rome.ICS.UCI.EDU>
- Date: Fri, 10 Jan 1997 17:29:46 -0800
- To: w3c-dist-auth@www10.w3.org
DESIGN TEAM NOTES First WEBDAV Design Team Meeting December 18-20, 1996 Novell, Orem, Utah In attendance: Stephen Carter, Novell Asad Faizi, Netscape Yaron Goland, Microsoft Del Jensen, Novell Jim Whitehead, U.C. Irvine The first WEBDAV Design Team meeting was held from December 18-20, 1996, at the Orem, Utah campus of Novell. Many thanks to Stephen Carter and Novell for hosting this meeting. Thanks also to Del Jensen, who took meeting notes which were used in the creation of this message. The purpose of the Design Team meeting was to gather a small group who would work intensely for several days to develop and refine the WEBDAV protocol specification. Since this was a closed meeting, the draft protocol specification reflects only the opinions of the participants of the Design Team meeting, who have tried to represent the working group as a whole. However, the decisions made at the Design Team meeting are subject review and acceptance by the WEBDAV working group as a whole, which is the only proper polling point for determining consensus. There were four main topics of discussion during the Design Team meeting: Links/Attributes/Metadata, Locking, Collections, Namespace manipulation. This message describes the results of our discussion on links, attributes, and metadata. LINKS, ATTRIBUTES, METADATA The team began its discussions by reviewing the "light link" proposal. A light link contains only a source URI, a destination URI, and a type token. The source URI is the beginning of the link, the destination URI is the endpoint of the link, and the type describes the relationship between the source and destination resources. A link may be interpreted as a binary relationship between the source and destination resources, which has the meaning, "the destination resource contains information of relation <type> to the source resource." A link may also be interpreted as an attribute-value pair, where the attribute name is the link type, and the value is pointed to by the destination of the link. This proposal was criticized for two reasons. First, when using a link as an attribute-value pair, it requires two HTTP requests to retrieve the value information. This overhead was perceived to be high, especially for small information values, such as a date field. Second, the light link proposal seemed to arbitrarily reject the link method and header described in Section 19.6 of the HTTP/1.1 specification. Surely the HTTP community would object to an arbitrary rejection of an existing proposal for the same functionality. The Design Team then began a detailed consideration of HTTP/1.1 style links, eventually ending up with a link which contained the following fields: Source : URI ; the beginning of the link Destination: URI ; the endpoint of the link type : token ; the type of the link anchor : 1*("(" media-type "," token ")") ; information about where the link ends in the destination resource, by media-type (in case of content negotiation). value : UTF-8 ; the value of an attribute-value pair title : UTF-8 ; the title of the link While initially seeming like a good idea, several questions arose with this formulation of links. What is the difference between a link and a resource when a link contains a title and a value field which may contain arbitrary content? Since value and title may be in any language, how is content negotiation performed on these fields? How should two links be considered identical? How should a link be identified for link removal operations? We struggled to save the HTTP/1.1 style link approach. A user-agent could use content negotiation when requesting the contents of a link to retrieve value and title fields in the desired language. However, this requires adding a language tag to each value field, and specifying the language when setting the value. It also raises the need for a link modification method, so that the value and title can be changed without modifying the rest of the link contents. Adding anchor, value, and title fields, and language tags to value and title fields would also increase the complexity of link searches. Identifying a link for removal or modification was discussed, with two options being fielded. The first was to exactly specify the value of every field, and demand exact matches on every field. However, this is a potentially high-bandwidth solution due to the potential for value and title fields to have entries in multiple languages, and all would need to be exactly specified. The second alternativewas to have a link identifier tag for each link which is assigned upon creation. This approach has the drawback that it is difficult for the server to assign unique link ids, and there was some debate over whether the link ids would need to be globally unique, or could be unique to each resource. We also discussed the possibility that a hash could be used to develop the link identifier, but this was considered undesirable due to the processing required by the server to compute the hash. After considering the HTTP/1.1 style link approach for close to a day, we came to the conclusion that it definitely increased the complexity of our solution. What did we gain from this extra complexity? The anchor, value, and title fields. We pondered whether the tradeoff of extra complexity versus one round trip access of value information was worth making. We considered five alternative link formulations: 1. Src, Dest, Type (original light link proposal) 2. Src, Dest, Type, Anchor (remove all negotiable content) 3. Src, Dest, Type, Value (reduce the amount of negotiable content) 4. Src, Dest, Type, Anchor, Value 5. Full first-class links (which were vaguely defined) We decided to adopt alternative 1, the original light link proposal, due to its simplicity, and the reduction in complexity in link manipulating methods. This type of link is specified as: Source: URI Destination: URI Type: token However, we still wanted to be able to retrieve the contents of the destination resource of a link with a single round trip (one method invocation). This was accomplished be defining a method called GetLinkVal. GetLinkVal is passed a link type and a Request-URI, and it searches the Request-URI for links with matching types. If the source URI of the link matches the Request-URI, and the destination URI is in the HTTP URL scheme, the value of the destination resource is retrieved. The return message body from this method is a multipart/related, which contains a Web Collection which describes the matching links, followed by the contents of the destination resources. To allow for all links on a resource to be easily retrieved, we created a new method called GetLinks. GetLinks returns a Web Collection which lists all of the links defined on the Request-URI, as (source, destination, type) tuples. We also discussed the link search syntax, which we decided to leave mostly as specified in the latest DAV draft. LinkSearch is passed a link search specification, and returns a Web Collection which lists all of the links which match the link search parameters, as (source, destination, type) tuples. A LinkSearch may be performed over a section of the URI space by specifying one or more starting point for the link search (known as Search Points) and the depth of the search (number of levels to search down in the URI hierarchy space). A link search is specified using prefix notation (operator followed by a list of operands). Operators allowed are equals ("="), not equals ("!="), and ("&"), or ("|"), and not ("!"). Equality and inequality can be applied to the source URI, the destination URI, and the type. Also related to links are the DAV specific link types "SupportedLinkTypes" and "SupportedLinkSchemas". The idea of SupportedLinkTypes is to give a location where a user-agent can discover the link types the server will definitely allow to be created on a resource. Since we envision varying levels of server support for enforcing link consistency, being listed in the destination resource of a SupportedLinkTypes link only means that the server will allow the creation of a link with that type. However, the server may also allow the creation of links with types not listed, but this is not guaranteed. Furthermore, the server might automatically perform some consistency maintenance on the listed link types, but this is not guaranteed, and is expected to vary from server to server. The SupportedLinkSchemas link type gives a location where the link schemas supported on the resource can be discovered. Two examples of link schemas are "DAV" for Distributed Authoring and Versioning links, and "DC" for Dublin Core links. The destination of the Source link is where a user-agent can request the unprocessed source representation of the source resource. This provides a way to get HTML source prior to server side include processing, or to retrieve the source of a CGI script.
Received on Friday, 10 January 1997 21:12:39 UTC