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

Synchronization for bodies is also better-defined than  
synchronization for properties.  With the choice of CalDAV bodies  
plus multiget:
  - clients can view just the ETags for a collection to see what  
bodies have changed
  - clients can ask for the bodies of the changed/new resources
  - clients don't have to worry about synchronizing property values  
-- property values are outside the calendaring domain, and the  
server's business

Why not put the content or data in the body of the resource?   For  
calendaring, that's the entire iCalendar object, even though some of  
the iCalendar insides are structured that doesn't mean they're  
metadata -- they *are* the data.  Non-Calendar stuff like ETag is  
true metadata.   It's a confusion in terminology (that WebDAV uses  
"property" for metadata while iCalendar uses "property" for  
structured data) that continually tempts us to use WebDAV metadata  
storage, instead of data storage,  for iCalendar data.

We still don't have the ability to synchronize property values in  
WebDAV.  We could start designing that, but there's not a strong call  
to, unless we start getting confused and put data into the metadata.

Lisa

On Jul 16, 2007, at 9:22 AM, Cyrus Daboo wrote:

>
> Hi Julian,
>
> --On July 16, 2007 5:47:37 PM +0200 Julian Reschke  
> <julian.reschke@gmx.de> wrote:
>
>>> 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:36:19 UTC