W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2003

Version Controlled Collection , PostConditions

From: Vikram_Roopchand <Vikram_Roopchand@infosys.com>
Date: Wed, 5 Feb 2003 12:38:34 +0530
Message-ID: <426C1E9EBA27D411839000D0B74752F807F243F4@punmsg02.ad.infosys.com>
To: <ietf-dav-versioning@w3.org>

Hi All,

The Postconditions in case of Version Controlled Collection

"14.11 Additional UPDATE and MERGE Semantics

   Additional Postconditions:

      (DAV:update-version-controlled-collection-members): If the request
      modified the DAV:checked-in version of a version-controlled
      collection, then the version-controlled members of that version-
      controlled collection MUST have been updated.  In particular:

      -  A version-controlled internal member MUST have been deleted if
         its version history is not identified by the DAV:version-
         controlled-binding-set of the new DAV:checked-in version.
      -  A version-controlled internal member for a given version
         history MUST have been renamed if its binding name differs from
         the DAV:binding-name for that version history in the
         DAV:version-controlled-binding-set of the new DAV:checked-in
         version.
      -  A new version-controlled internal member MUST have been created
         when a version history is identified by the DAV:version-
         controlled-binding-set of the DAV:checked-in version, but there
         was no member of the version-controlled collection for that
         version history.  If a new version-controlled member is in a
         workspace that already has a version-controlled resource for
         that version history, then the new version-controlled member
         MUST be just a binding (i.e., another name for) that existing
         version-controlled resource.  Otherwise, the content and dead
         properties of the new version-controlled member MUST have been
         initialized to be those of the version specified for that
         version history by the request.  If no version is specified for
         that version history by the request, the version selected is
         server defined."

In the last point, it is written "...then the new version-controlled member
MUST be just a binding".

I am unclear about this "binding" , since the term "version-controlled member" has been used alongwith it,  does it mean that another VCR having DAV:checked-in the same as that of already existing VCR should be created (which violates workspace semantics ?) or will there be a non versioned member created (having the content and dead properties of the already existing VCR )?

If it is the first case , then how will checkouts/checkins/merge be handled on both VCR's ?

warm regards,
Vikram
Received on Wednesday, 5 February 2003 02:05:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:44 GMT