- From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
- Date: Tue, 29 Nov 2005 13:12:04 -0800
- To: Lisa Dusseault <lisa@osafoundation.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDav <w3c-dist-auth@w3.org>, Cullen Jennings <fluffy@cisco.com>
On Nov 29, 2005, at 11:49 AM, Lisa Dusseault wrote: > I hadn't thought that a client could use weak etags at all for > authoring. I had started from considering the cases of a JPG or a > Photoshop file or a Word document. What does a weak ETag mean for > those documents? If I edit a Word document on a WebDAV server and > all I do is fix a couple inconsistent fonts and a space or two, one > might think that the weak ETag need not change -- but I would not > find the system very usable if these changes were lost on a > subsequent update. As Julian said, the meaning of semantically equivalent is important. The XML rewriting debate with respect to properties we've been having is an example of why it's important to define, and presumably a similar debate could be had as to whether such rewriting of a XML resource body would lend itself to a weak etag match. In the case of CalDAV, the iCalendar spec would be the authority on semantic equivalence. If iCalendar says that the order of iCalendar properties and subcomponents is semantically meaningful, then they need to be preserved. (Presumably the iCalendar parsers, storage, and generators you use would know this and preserve the order.) If not, then for the purposes of iCalendar, changes in order are semantically equivalent, and we could probably agree that for CalDAV such changed in a <calendar-data> element are equivalent by extension. It should be noted that we've already agreed that normalizing out newlines in iCalendar data within XML is OK, and that variation would be semantically equivalent as well as any variations considered equivalent in iCalendar. CalDAV should probably be explicit about both of these equivalence measures as they related to etags. -wsv
Received on Tuesday, 29 November 2005 21:13:22 UTC