RE: WebDAV Bindings - Issue Yaron.ApplePieToo

The first paragraph doesn't really say anything substantive.  It just
introduces the section, listing the methods to which it applies.  The one
substantive statement that I think we would want to keep is "For these
methods, no new complexities are introduced by allowing explicit creation of
multiple bindings to the same resource."
 
I could be persuaded to reduce the section to just that.
 
But it still might be worth pointing out that BIND will make it much more
common to have multiple bindings to the same resource (even though that was
always possible).  And when there are multiple bindings to a resource, it is
possible for a resource's behavior in response to GET, HEAD, PROPFIND, etc.,
to be sensitive to the URI that was used to make the request.  Maybe we
wouldn't have to discuss the distinction between static and dynamic
resources in order to make that point.
 
--Judy
 

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:28 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.ApplePieToo



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 Tuesday, 18 January 2000 10:31:35 UTC