W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

RE: WebDAV Bindings - Issue Yaron.ApplePieToo

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Wed, 19 Jan 2000 10:39:55 -0500
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2456C@crte147.wc.eso.mc.xerox.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:53 GMT