- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Tue, 2 Feb 1999 09:59:35 -0500
- To: ccjason@us.ibm.com
- Cc: w3c-dist-auth@w3.org
- Message-Id: <9902021459.AA24777@tantalum>
I hate to snip out all the sections where we agreed (:-), but for the sake of brevity, I'll just skip to the one section which raised a question: From: ccjason@us.ibm.com GMC> The expected semantics of COPY is that I end up with a different GMC> object, so that I can modify one copy and have it not affect the other. Yup. I agree. OK, I left in one "I agree", but I need this one for context (:-). GMC> But now let's look at what a COPY on a reference should be. GMC> If you just make a copy of the reference, then any PUT to tthe GMC> source object will cause a modification visible in a GET to the GMC> destination object, and vica versa. This is the opposite behavior GMC> from what one would expect from a "copy", and seems to violate GMC> the whole point of differentiating a "MOVE" from a "COPY". I don't necessarily agree here. What I expect (or at least want) depends on what I'm doing at the time. My turn to agree (:-). I think I'd tend to expect the reference to be copied. The problem with copying just the reference shows up especially vividly in a downlevel client (that doesn't even know about references). If I say "COPY", the key expectation that I can now modify the copy-target without affecting the copy-source is violated. The general rule I try to apply in these situations is: If there are two reasonable things to do, so you need an extra parameter (e.g. a header) do indicate which one you want, then have the default be the one that does what a downlevel client would expect, and have the presence of the header mean to "do the other thing". In the case of "COPY" applied to a reference, this would seem to say that the reasonable thing that the downlevel client would expect (i.e. a copy of the reftarget of the reference) should be the default, and the other reasonable thing (i.e. a copy of the reference itself) should be indicated by a header. The "no-pass-through" header immediately springs to mind. Cheers, Geoff
Received on Tuesday, 2 February 1999 09:59:44 UTC