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

Re: DAV:checked-in

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sat, 20 Jan 2001 01:34:40 -0500 (EST)
Message-Id: <200101200634.BAA07613@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Tim_Ellison@uk.ibm.com


   <tim>
      2.2.1 DAV:checked-in
	'This URL can be used to retrieve this particular
	state of the version-controlled resource after the
	version-controlled resource itself has been modified.'

	 Given that this is a property of a checked-in version-
	controlled resource, I fail to see how the version-
	controlled resource itself can be modified.
   </tim>


   <tim_2>
	Well it seems that Chuck and I were equally confused by this sentence.

	However, I think that I understand where you are coming from -- namely
   that a client can take a copy of that DAV:checked-in URL and use it later
   to refer to the previous state of vcr when the DAV:checked-in value has
   been overwritten.
   </tim_2>

Changed the text so that it is less misleading.

   From: Tim_Ellison@uk.ibm.com

   <tim>
	7 Server-Workspace Option

	para. 4
	Unless the URLs are relative, the workspace name will get in the way
   of testing.
   </tim>

   The how about we delete that paragraph?  Rationale has alredy been given
   earlier.

Done.

   From: Tim_Ellison@uk.ibm.com


   <tim>
      5.4 Additional OPTIONS Semantics
	  Is it required that the history for the resource reporting the
   OPTIONS
      MUST be in the version-history-collection-set?  Probably unnecessary
   since
      clients can get to the history via properties.
   </tim>

   So why would a client want to know where some (indeterminate) version
   histories are stored?

So that it can find version histories that no longer are referenced
by any version-controlled resource.

   From: Tim_Ellison@uk.ibm.com

   <tim>
      6.5 Additional CHECKOUT Semantics
	  Additional Marshalling:
	  'The response MAY include a Location header.'
	  How else would you find a working resource URL?  Consider MUST.
   </tim>

The additional marshalling applies to all forms of CHECKOUT,
including a CHECKOUT of a version-controlled resource, but the
Location header is only required if a version is being checked
out.  The postcondition states that the Location header is
required if a version is being checked out.

Cheers,
Geoff
Received on Saturday, 20 January 2001 01:35:34 GMT

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