- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Wed, 19 Jan 2000 10:39:55 -0500
- To: "'ccjason@us.ibm.com'" <ccjason@us.ibm.com>, Yaron Goland <yarong@Exchange.Microsoft.com>
- Cc: w3c-dist-auth@w3.org
Here's some text that doesn't mention static / dynamic. It doesn't make the simple, idealized statement that we wanted for static resources, but maybe it says enough to be useful: "This section describes the interaction of bindings with those HTTP methods not yet explicitly discussed. The semantics of the methods GET, HEAD, PUT, POST and OPTIONS are specified in [HTTP]. The semantics of PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV]. "For these methods, no new complexities are introduced by allowing explicit creation of multiple bindings to the same resource. However, the introduction of the BIND method will make it more common for multiple URIs to map to the same resource. As a result, the introduction of the BIND method may point up complexities that were already possible, but occurred only rarely in the past. "In particular, when there are multiple URI mappings to the same resource, it is possible for the resource's behavior in response to GET, HEAD, PROPFIND, etc., to be sensitive to the URI that was used to make the request. For example, the Request-URI may appear in the response entity body for GET on a particular resource, in which case the response entity body produced by that resource will differ depending upon which URI was used to make the request. "The only way for a client to determine whether two URIs map to the same resource is by retrieving and comparing the DAV:resourceid property defined in the following section." Or we could keep the current text, but add some remarks about the static / dynamic distinction, along the lines that Jason suggests: "This section describes the interaction of bindings with those HTTP methods not yet explicitly discussed. The semantics of the methods GET, HEAD, PUT, POST and OPTIONS are specified in [HTTP]. The semantics of PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV]. "For these methods, no new complexities are introduced by allowing explicit creation of multiple bindings to the same resource. However, the introduction of the BIND method will make it more common for multiple URIs to map to the same resource. When these methods are applied to the same resource using different Request-URIs, the rules for their behavior depend upon whether the resource is static or dynamic. "A static resource is one that always produces the same response to the same method with identiical parameters. "A dynamic resource is one that may produce different responses for different submissions of the same method with identical parameters. "In reality, a single resource may respond statically to some requests, but dynamically to others. However, for a pure static resource, these methods obey the folowing rule: "o A method submitted through one URI mapping, on success, MUST produce the same results as the same method, with the same headers and entity body, submitted through any other URI mapping to the same resource. "When applied to dynamic resources, it is not possible to state any such rule. For any method, a dynamic resource may be sensitive to the URI mapping used to access it. The resource may produce different results depending upon which URI mapping was used to submit the request." --Judy > -----Original Message----- > From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com] > Sent: Tuesday, January 18, 2000 5:26 PM > To: Yaron Goland > Cc: w3c-dist-auth@w3.org > Subject: RE: WebDAV Bindings - Issue Yaron.ApplePieToo > > > > I suspect my problem with the language in the section > derives from the > differentiation made between static and dynamic resources. In my > experience > one can not really make the distinction because even if a > "resource" is > just > a file in a file system, there is always a server on top of > it that may > or > may not alter its presentation. If the language in section > 9 were to be > re-written with the assumption that ALL resources are dynamic then I > suspect > we would find the resulting language mutually acceptable. > > I agree that there is a perspective that there are no truly static > resources in the world, > but if we get hung up on that, we're verging on a > meta-physical discussion > that will > distract from the point of this section. And if we tried to write > something that works > for all dynamic resources, there truly wouldn't be anything > meaningful said > in that > section. That section is very readable right now and does a > good job of > conveying a fuzzy concept/behavior: > > There are a range of resources. From the ideal static > resource to the most > dynamic resource > you could imagine. One will probably never encounter a > resource at either > extreme. Where > a given resource lies between these two extremes is in the eyes of the > beholder... but the > platonic ideal of a static resource acts in this fashion... > > That being said, feel free to write up a new version of that > section, but > please don't get overly > distracted trying to convey the fact the the nominal "static > resource" is > only an ideal. > I do feel if one's focus is too much on that, they will write > something > less effective > than the current text. As I said, the current text seems to > do a good job > conveying > a fuzzy topic. > > >
Received on Wednesday, 19 January 2000 10:40:11 UTC