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

Re: WEBDAV-06-PROTOCOL Comments ( Contd..)

From: Surendra Reddy <SKREDDY@us.oracle.com>
Date: 22 Jan 98 17:59:26 -0800
Message-Id: <199801230227.SAA11742@mailtst1>
To: <w3c-dist-auth@w3.org>
	Thanks for your explanation. Your argument makes sense and It's
	ok to me to leave these method names as it as. 


Surendra K Reddy         Tel.   +1(650) 506-5441 
                         Fax.   +1(650) 506-7421
                         Email.	skreddy@us.oracle.com
"It is unwise to be too sure of one's own wisdom. It is healthy to be
 that the strongest might weaken and the wisest might err."  

Warning: Statements and opinions stated herein may not be those of Oracle

attached mail follows:


Thank you for taking so much time to comment on the protocol draft!  More 
comments below:

On Thursday, January 22, 1998 2:19 PM, Surendra Reddy 
[SMTP:SKREDDY@us.oracle.com] wrote:
>    Jim,
> 	Thanks for your pointers on Dublin Core references and other discussions
> related to adding properties
> 	Author etc. After dwelving into those pointers, I agree with your 
> and inclusion criteria for adding any other properties.
> 	One more issue: Why collections are unordered collections only. It is
> useful to have ordered collections. I am not
> 	sure whether this issue had already been discussed at length and 
> not to support ordered collections? (
> 	I am still reading through years worth of mailing archives). If there no
> consensus reached on this topic yet,
> 	I would like to hear comments from other members of this group.
> 	Jim what is your judgement call on this?

I have not yet seen consensus on this issue on the list.

> 	 Do you agree with me renaming PROPFIND and PROPPATCH to GETPROP and
> SETPROP? I know you may not
> 	agree with as this  not critical for successful implementation of 
> but i see that GETPROP and SETPROP
> 	coveys the purpose of these methods ( again it may go back to an 
> of HTTP methods are opaue token)/

I think it's a bad idea to change method names this late in the game 
because the discussion of the working group has centered around these 
names, and thus although they are just opaque identifiers to the silicon 
computer, the carbon-based brain computer isn't so easily reprogrammed. 
 People get used to discussing functionality lumped under a given name, and 
changing the names of the methods causes problems when discussing the same 
functionality under the new, not so well known name.

Roy Fielding had the best rationale for this when discussing another method 
name change recently:


My summation of the arguments concerning this other name change can be 
found at:


A second, less compelling reason not to change PROPFIND to GETPROP is that 
some HTTP servers apparently see a method name beginning with "GET" and 
assume it is the GET method.

The rationale for the choice of these method names is as follows.  Since 
the state of a resource is now divided into the body (retrieved with a GET) 
and the properties, we decided to have some symmetry with the name of the 
PATCH method (which was in previous drafts, recently removed, will reappear 
in future versioning drafts) which is used to modify the state of the body 
of a resource.  So, we named the method which modifies the state of the 
properties of a resource PROPPATCH.  The name PATCH is a holdover to older 
HTTP 1.1 drafts, which also had a definition of PATCH before it was 
removed.  (PATCH has had a checkered history.)

Since we couldn't use a method name that began with GET, we decided to 
stick with a name that began with PROP for the property retrieval method 
name.  Although we could have named the method PROPGET, we didn't like that 
name, because it connoted, with its use of the name GET, that the entire 
property state of the resource is returned, rather than just selected 
properties based on a selection criteria. FIND was a good substitute, hence 

- Jim
Received on Thursday, 22 January 1998 21:28:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:12 UTC