- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Mon, 4 Dec 2000 11:47:57 -0500 (EST)
- To: w3c-dist-auth@w3.org
I highly recommend that WebDAV clients not depend on any ordering of the immediate children of the top level XML element in a method response body. In the versioning spec, all of the request and response body top level XML elements will be declared as ANY, to provide for extensibility. The only constraints will be of the form "at most one element of type XXX must appear", so a client will not be able to assume any particular ordering. Cheers, Geoff -----Original Message----- From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] I think mod_dav is quite clean regarding that problem. But, for instance, IIS sends a status tag first and then a prop tag in a propstat although the DTD states: <!ELEMNENT propstat (prop, status, responsedescription?)> There are a few other samples like this one but I think the main problem is that the server and the client must be implemented in a way that they are able to handle requests and responses which are *not* correct regarding the DAV-DTD in RFC2518. I think the whole situation would be much easier and cleaner if clients and servers *must* use that DTD. Moreover it is maybe possible to get rid of some of the "ANY"s in that DTD. Best, Hartmut Greg Stein wrote: > On Fri, Dec 01, 2000 at 11:21:45AM +0100, Hartmut Warncke wrote: > >... > > I totally agree! If you look, for example, at implementations of RFC2518 you will > > come to the conclusion that a lot of problems of the "realworld" WebDAV client > > server communication are caused by the fact that a lot of clients and servers do > > *not* implement the DTD of RFC 2518 exactly because they don't have to. > > Do you have some examples of infractions like this? > > Or more close to home :-), have you seen any problems like this with mod_dav? > (because I'm unaware of them at this time, but would love to correct them if > they exist!) > > thx, > -g > > -- > Greg Stein, http://www.lyra.org/
Received on Monday, 4 December 2000 11:48:43 UTC