W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1999

Re: New status code: unordered collection

From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
Date: Thu, 13 May 1999 07:24:57 -0400
Message-Id: <9905131124.AA02024@tantalum>
To: yarong@microsoft.com
Cc: w3c-dist-auth@w3.org

I will be very boring here, and just agree vigorously with everything Yaron
said.  In particular, I believe Yaron's preference (choice three) is far
superior to the alternatives.  As for the default root name, I'd probably
tend towards <body> myself (after all, it is the body of the response).

Cheers,
Geoff

   From: Yaron Goland <yarong@microsoft.com>

   There are relatively few error codes and we should be very hesitant before
   handing out new ones. I think 409 is a good error code for this situation
   but obviously more data is needed. We should provide that additional data
   either as a header in the 409 response or in the body.

   If we are going to use the body then we do the world a great favor if we can
   come up with a single format so that multiple, independent, error conditions
   can be described. The most likely choice is XML but XML has a problem. It is
   illegal for an XML document to have more than one root. This means that if I
   want to return two error conditions in a single response which were created
   by two unrelated groups I can't return them in a single XML document because
   they have different roots. Therefore we seem to have three choices:

   1 - Don't use XML.
	   Nice thought but probably impractical for reasons that market
   marketoids heart's glow bright red.

   2 - Use MIME Multipart to include multiple independent XML documents
	   This will work but doesn't it just seem such a waste to have to
   throw in MIME multipart processing just because the XML guys made a silly
   mistake?

   3 - Invent a global root element
	   I'm a big fan of this solution. Let's just invent some universal
   root element (how about <root>?) and declare that ALL XML returned in WebDAV
   error codes MUST go inside this element. Now we can throw in as many
   independent XML documents as we want and not have to worry about the single
   root problem. If we feel like being really neighborly we can even present
   this solution to other groups and maybe get all IETF XML to be put inside
   this element.

	   Just a thought,
			   Yaron	


   > -----Original Message-----
   > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
   > Sent: Wednesday, May 12, 1999 12:27 PM
   > To: w3c-dist-auth@w3.org
   > Subject: Re: New status code: unordered collection
   > 
   > 
   > 
   > 
   > sounds OK to me.
   > 
   > 
   > 
   > 
   > Jim Whitehead <ejw@ics.uci.edu> on 05/12/99 02:08:43 PM
   > 
   > Please respond to ejw@ics.uci.edu
   > 
   > To:   WEBDAV WG <w3c-dist-auth@w3.org>
   > cc:    (bcc: Jim Amsden/Raleigh/IBM)
   > 
   > Subject:  New status code: unordered collection
   > 
   > 
   > 
   > 
   > In the current Advanced Collections specification, the 409 
   > (Conflict) status
   > code is used for cases where the server cannot perform the 
   > client's request
   > to place a resource at a specific position in a collection because the
   > collection is unordered.  In my opinion, this is a good case 
   > for introducing
   > a new status code, say 425 (Unordered Collection).
   > 
   > 409 is a sub-optimal choice because this status code is used by many
   > existing WebDAV methods, as well as new methods in the 
   > advanced collections
   > specification, for non-ordering related problems.  Since a 
   > client can, if it
   > knows the error is the result of the collection not being 
   > ordered, simply
   > re-submit the request without the Position header, having 
   > this case clearly
   > separated from other 409 cases would give the client this option.
   > 
   > I'm not sure whether this code should also be used for other 
   > positioning
   > errors (such as trying to place a resource after one that 
   > doesn't exist).
   > I'm tending to think it should not.
   > 
   > - Jim
   > 
   > 
   > 
   > 
   > 
   > 
   > 
Received on Thursday, 13 May 1999 07:25:02 GMT

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