- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Wed, 21 Apr 1999 18:59:29 -0700
- To: ejw@ics.uci.edu
- cc: w3c-dist-auth@w3.org
>*snip* (the full message can be found at: >http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0230.html) > >The authoring team for Advanced Collections has debated this approach, and >decided not to adopt it for the following reasons: > >1) It would require an extra discovery step to determine where the >authorable namespace mapping resource is found. So, instead of being able >to directly say "create binding at B to A" by issuing a method directly to >URL B, first a client would need to query a property (most likely on its >containing collection) to discover the authoring location, then go modify >the authoring location. More likely, it would already know what the mapping resource is because it has already retrieved the collection listing, which is certainly capable of indicating that the name is a binding. In any case, such a discovery step is not an undue burden given the need for robustness rather than speed. >2) It would either require extra methods to specifically modify the >authorable mapping resource (ADD_MAPPING, REMOVE_MAPPING, with the >consequence of introducing a new type of resource, the mapping resource), or >it would require the client to understand the syntax (and require the >protocol to standardize the syntax) of the mapping resource (but at least it >would be a plain, generic resource). This would introduce the problem of >how to handle MOVEs on this resource. You would have to define a syntax for one possible media type for exchanging this information, yes. MOVE is not an issue, since the mapping resource is either part of the collection or not (i.e., MOVE is rejected by the server if just the binding is moved, with an indication to edit the mapping resource instead). >It would also confuse the definition >of a collection, since the binding between a URL and a resource would belong >to more than one resource (the collection and the mapping resource). No, the collection resource is a product of a server's configuration, one part of which is the mapping resource. If this wasn't bidirectional, the collection would be unable to list its own members. [I imagine most implementations would allow at most one specially-named mapping resource per collection, just as Apache only has at most one .htaccess file per directory.] The reason I prefer this model is because it is unavoidable in practice. If it isn't defined this way in WebDAV, then all directory-configurable servers will have to implement BOTH the trivial bindings of WebDAV and their own more capable bindings via the indirect configurations. The question is whether the collection is able to denote those bindings within the collection listings, and thus within your precious Save As ... dialogs, and yet give the client a reasonable indication that it can't use BIND/UNBIND to author them, leading therefore to an interoperability requirement. The existence of directory-configurable bindings far predates WebDAV, so you should consider this to be a requirement on the manipulation of http namespaces. If nothing else, you need to at least have a way of distinguishing them within the collection. ....Roy
Received on Wednesday, 21 April 1999 22:00:02 UTC