- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 6 Nov 2001 12:34:52 -0500
- To: "'Mathias.Picker@virtual-earth.de'" <Mathias.Picker@virtual-earth.de>
- Cc: interop@webdav.org, w3c-dist-auth@w3.org
From: Mathias.Picker@virtual-earth.de I'm not against the source paradigm, but still see some problems there. The very first thing being the completely undefined semantics of it, if it has more than one link per resource. How is the semantics undefined? If you have multiple resources that are used to generate another resource, you need to give the user the option to modify any of them, since only the user knows which one needs to be modified. It's no harder for the user to decide which resource needs to be modified than it is to decide which line of a resource needs to be modified. On 5 Nov, Clemm, Geoff wrote: > My standard response to everyone who suggests that it is > too complicated for a client to make sense of multiple source > fields is: adopt the convention that the first link is the > most important one, and just show that one. I do not think that conventions will solve this problem. If you think its the solution, bring it into the standard. I'm not sure what "problem" you are trying to solve. The notion of "most important" is going to be a fuzzy concept at best, so you won't be able to formally define it in any case. Actually, I don't think it's a solution. When we put that information into the standard, we should a t least formally model this decision, by honoring the "preferred", "true", "i-really-mean-this" link with special markup. And here we have the semantic problem again: what do we _mean_ with multiple source links, and which one ist the "true" link to the source of this property? The whole point is that when there are multiple sources, there never is a well defined notion of "preferred", "true", or any such thing. Just as there is no well defined notion of "the preferred line of the file to change" or "the preferred paragraph to change". This is a bit like a file system, which does not show me mysource.c, but mysource.h, someheader.h, somesystemheader.h, evenmoreheaders.h, someconnectedsource.c,, mysource.c, somelibrary.a, somethingsentirelydiffent.dontknow. Do you find the source in that? Would you _want_ your file system to do that? And that's pretty much the example from the standard. If the thing I had to fix was defined in mysource.h, and not in mysource.c, a client that only showed me mysource.c is pretty useless. The difference between "test.c", "test.exe", and "the output of running test.exe" are all significant, and should each have their own URL. > One very common mechanism for doing Web-based access control > is to base the access control on the URL (i.e. what you can do > to a resource depends on what the URL is). Using any header > (such as the Translate header) breaks any scheme like this. Good point. But we do not control acces by URL, we control it by URL and method, and since some header obviously modify the semantic of methods (e.g. GET with if-modified-since is really a HEAD (=PROPGET?) if the resource has not been modified), so we allready control by URL and method and header implicitly, why shouldn't we officially control by URL and method and header? A header is an "argument" to a method. Normally, you do not base your access control for a method on the arguments to the method. Obviously you could in theory, but in practice the cost outweighs the benefit. > When you do a COPY, should it go against the raw form or > the processed form of the resource? Probably need the Translate > header for that then too. Similarly for any other method that > could reasonably be applied to both the raw and the processed form. Yes, and that's perfectly fine. Where's the problem there? The problem is that "Translate" is only one of many headers that one could think of that redirect to different content (e.g. a Version-Selector header for versioning, and a Variant-Selector header for variants. This means that every method would need to contain the logic for all of these headers, which requires massive reworking of the implementation whenever such a header is introduced. In addition, you now you have to define what happens when you combine these headers (is that the "Translate" of the "Version-Selector", or vica versa). Compare this to the source solution: Just look at the example in 13.10.1, where foo.bar/program has three source links. How do you copy this? Only the user knows the answer here, since it depends on what is being done. The copy operation needs to be well defined, and then the user can make sensible choices on composite copy requests. And, how do you manage the connection source to destination? I mean, if I copy the source or destination, should the corresponding destination or source be copied with it? If I copy the destination, will I create a sort of "binding", since in effect it's the same as the first destination, since it uses the same source link? or do I need to copy the source link, too? What happens if I move one or the other? It depends. There is no right answer here, so forcing one as the only answer is wrong. Nothing of this is defined (I just tried to find it in the standard or in the issues list, correct me if I'm wrong), making the current solution, well, hmmmm, what can I say ...: unusable? Nothing of this is defined because there is no "right" answer. Forcing a trivial wrong answer does not help things. > So all that is needed is for the server to be able to dummy up > some URL that means "the raw form of this resource" to avoid all > these issues. That does not seem like an unreasonable burden on > the server implementor. Similarly, I don't think it is an > unreasonable burden on a client writer to do one extra roundtrip to > retrieve a tree of source images (i.e. one Depth:infinity PROPFIND to > retrieve all the links for a tree). Well, unreasonable burden for the developer or not, I want the source and dest links to be the same, so users can use their favorite html/text-editor to edit the page and include links that actually work, whithout thinking about where the link should go, e.g. source or destination. Different source and destination hierarchy place an unreasonable burden on the _user_, not on the developer. Well, I want my users to be able to modify the right line of the source file without thinking about which line they need to modify. I won't get that either (:-). Cheers, Geoff
Received on Tuesday, 6 November 2001 12:36:37 UTC