Re: Why MOVE isn't really defined as a COPY followed by a DELETE

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