W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2007

Re: [Ietf-carddav] Comments on draft-daboo-carddav-02

From: Cyrus Daboo <cyrus@daboo.name>
Date: Mon, 16 Jul 2007 12:22:54 -0400
To: Julian Reschke <julian.reschke@gmx.de>, "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>
cc: w3c-dist-auth@w3.org, ietf-carddav@osafoundation.org
Message-ID: <6A114647AE869FB6B3252EDC@caldav.corp.apple.com>

Hi Julian,

--On July 16, 2007 5:47:37 PM +0200 Julian Reschke <julian.reschke@gmx.de> 

>> my own project is to implement a CalDAV server that has no DBMS
>> dependency - it's a servlet that uses exclusively the filesystem for
>> storing data. I have repeatedly run into details in the specs that would
>> have been *much* easier to implement had a database been my underlying
>> store; typically these details relate to the blurred distinction between
>> data and properties.
>> ...
> So let's assume that the parts of a vCard resource would be exposed as
> (potentially computed) WebDAV properties -- wouldn't the need for the
> multiget report just go away? PROPFIND would be all that's needed, then...

The problem is mapping vCard "properties" on to WebDAV "properties". We had 
the same problem in iCalendar which is why CalDAV does not do that. One 
issue is how to represent multiple instances of the same property - in 
vCard/iCalendar certainly properties can appear more than once, yet WebDAV 
only allows one property of an element type per resource. Yes you could do 
things with list elements but it starts to get messy - so we avoided it. It 
would also mean inventing an XML representation of the data - we certainly 
did not want to go down that route with CalDAV at the time.

Cyrus Daboo
Received on Monday, 16 July 2007 16:23:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC