- From: Yaron Goland <yarong@Exchange.Microsoft.com>
- Date: Sun, 16 Jan 2000 17:27:55 -0800
- To: w3c-dist-auth@w3.org
- Message-ID: <7DE119D3D0E15543874F7561EECBDBED02619E1D@BEG.platinum.corp.microsoft.com>
Section 9 of the draft attempts to tackle the problem of how to differentiate the behavior of a resource based on its bindings. It attempts to discuss the difference between a static and non-static resource. However the difference between these two types of resources is so unbelievably arbitrary that I fail to see how attempting to differentiate between them enhances interoperability. For example, let us pretend we have the CurrentURI property. The value of the property will be the Request-URI of the PROPFIND method used to retrieve the value of the CurrentURI property. Now let us pretend we have two servers, A and B. A runs a version of WebDAV that automatically generates the CurrentURI property on top of whatever resources it supports. What this means is that even if the underlying data store where the resource is recorded doesn't know about the CurrentURI property, I can still get the CurrentURI property through PROPFIND because A's server will intercept the PROPFIND and insert the data itself. Server B doesn't support CurrentURI at all. I now have a resource R that has bindings into A and B. This means that if I ask for the CurrentURI property through the binding on A, I will get a result with the URI on A. If I ask for the CurrentURI property through the binding on B, I will not even see the property at all. So the question is - Well is this a dynamic resource? Is it not? Can I have the same resourceID on both URIs in this example? How does the language in section 9 help me deal with this? Does it actually clarify anything in a useful way? As far as I can tell the language in section 9 is just motherhood and apple pie language and that always makes for bad standard language. Therefore I move that all the paragraphs in section 9 but the first paragraph be stricken from the BIND spec.
Received on Sunday, 16 January 2000 20:28:49 UTC