- From: <ccjason@us.ibm.com>
- Date: Sun, 14 Feb 1999 16:55:16 -0500
- To: w3c-dist-auth@w3.org
Yaron, Cool. Then we are all basically in agreement and just need to reword the spec. The current wording looks pretty tight. I quickly tried to come up with something that was less "subtle" without wrecking the current wording. I've not come up with anything that I'm really happy about though. I believe the current spec says... 8.9.1 MOVE for Properties The behavior of properties on a MOVE, including the effects of the propertybehavior XML element, MUST be the same as specified in section 8.8.2. Perhaps this could be enhanced via... 8.9.1 MOVE for Properties The behavior of properties on a MOVE, including the effects of the propertybehavior XML element, MUST be ****basically**** the same as specified in section 8.8.2. ****This does allow for differences due to differences in the basic semantic model of MOVE vs. COPY. For example, a live unique_resource_id property might retain the same value at the destination as at the source for a MOVE; whereas, have a new unique value after a COPY. The same would usually be expected of properties like getlastmodified.**** I'm not even sure if that applies to getlastmodified. My uncertainty suggests that we need to specify up front it's MOVE behavior. Does getlastmodified apply to the underlying resource... or the URL? (I know what my browser prefers. :-)) Which gets me to... rfc2518 doesn't say what happens if one sets the value of getlastmodified... but now I'm off on a tangent. Anyway, that was my shot. I hope that someone can come up with a better wording... BTW, I notice that section 8.8.2 doesn't actually say what happens with dead properties during a COPY. Perhaps that's too obvious though. :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com
Received on Sunday, 14 February 1999 16:52:30 UTC