RE: Clarification of DAV:update-merge-set when rerunning MERGE

Change #1 has been made in draft-19.  Change #2 is also very reasonable,
and there just happens to be an extra blank line on that page, so I can
squeeze in the extra sentence.  

Cheers,
Geoff

-----Original Message-----
From: Roy Seto [mailto:roy.seto@oracle.com]
Sent: Monday, September 17, 2001 1:43 AM
To: ietf-dav-versioning@w3.org
Subject: Re: Clarification of DAV:update-merge-set when rerunning MERGE


Geoff,

Thanks for the clarification. What about making the following two edits?

1. I agree that moving the "must be in a DAV:response" sentence up into
the first or second sentence of the DAV:update-merge-set postcondition
would make the intent clearer.

2. I think I was confused by the text in the opening of Section 11.2, "The
response to a MERGE request identifies the resources modified by the
request, so that a client can efficiently update any cached state it is
maintaining." I got confused because DAV:update-merge-set doesn't actually
change the target's state when MERGE is rerun. After reading your
clarification, I understand this text is non-normative and the
DAV:update-merge-set postcondition is normative, but other readers might
make the same mistake I did.

Would it be possible to modify the introductory text above to something
like "The response to a MERGE identifies resources which a client must
modify to complete the merge. It also identifies resources modified by the
request, so that a client can efficiently update any cached state it is
maintaining."

Thanks,
Roy

"Clemm, Geoff" wrote:

>    From: Roy Seto [mailto:Roy.Seto@oracle.com]
>
>    I'm looking at the behavior of the MERGE method when it is
>    rerun. I'd like clarification of the DAV:update-merge-set
>    postcondition in Section 11.2 for this scenario.
>
>    Specifically, if a merge target was already checked out
>    before the second or later MERGE, and its DAV:merge-set or
>    DAV:auto-merge-set already includes the merge source, does
>    the merge target appear in a DAV:response XML element in the
>    response body?
>
> Yes, this is required by the last sentence of the DAV:update-merge-set
> postcondition.
>
>    I feel this is ambiguous in draft-18. The
>    DAV:update-merge-set postcondition does apply to this merge
>    target, because it was already checked out before the MERGE,
>    and its DAV:checked-out version is not a descendant of the
>    merge source (assuming a client has not moved the merge
>    source from DAV:merge-set to DAV:predecessor-set between the
>    MERGE requests). However, the state of the merge target does
>    not actually change in the second MERGE request, since
>    adding a source to a DAV:merge-set which already contains it
>    doesn't change the DAV:merge-set property.
>
> The last sentence of DAV:update-merge-set applies to any
> target that matches this postcondition, i.e.:
>
>  If the merge target was checked out by the MERGE (or was already
>  checked out before the MERGE), and if the DAV:checked-out version of
>  the merge target is not a descendant of the merge source ...
>
> There is no dependency on whether or not the the merge source
> is already in the DAV:merge-set or DAV:auto-merge-set.
> If this is not clear, I could move the "must be in a DAV:response"
> sentence up into the first sentence of this precondition, if you
> think that would be clearer.
>
> [restart example omitted]
>
>    Alternative options I considered for supporting restart:
>
>     - The client could do a PROPFIND Depth:infinity
>       and look for resources which have nonempty
>       DAV:merge-set or DAV:auto-merge-set properties,
>       but it seems difficult to make this efficient.
>       It also requires the client to detect the restart
>       case and implement it with a different code path.
>
> Well, a client has to do this anyway, if the user doesn't
> remember what MERGE they performed.  But I agree that this
> would be a challenge to make efficient.  One approach is
> to play a little fast'n'loose with the PROPFIND semantics,
> and only have the PROPFIND return results with non-empty
> DAV:(auto-)merge-set properties, and just use an index
> on those properties to optimize the speed of the PROPFIND.
>
>     - The client could do a DASL query to optimize
>       the PROPFIND above if DASL were standardized.
>
> Yeah, that would be nice (:-).
>
> And of course, option 3 is to just use the DAV:merge-preview
> report to get the info you need.
>
>    --
>
>    I have a similar question about the behavior of the
>    DAV:merge-preview REPORT after the corresponding MERGE has
>    already been done. If a merge target requires a merge, and
>    its DAV:merge-set or DAV:auto-merge-set already includes the
>    merge source, does the response body include it in a
>    DAV:conflict-preview element? (For reasons similar to the
>    DAV:update-merge-set case, I prefer that it must.)
>
> The merge-preview element contains all resources that "need
> to be merged".  Whether or not something needs to be merged
> is not changed by that version already being in the
> DAV:merge-set.  So DAV:merge-preview definitely works the
> way you want (and was intended to do so).
>
> Cheers,
> Geoff

Received on Thursday, 27 September 2001 14:25:07 UTC