Pseudo-properties in reports, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}

Hi,

this is somehow related to a discussion we had in July 2007 
(<http://lists.osafoundation.org/pipermail/ietf-carddav/2007-July/000018.html>):

> Property model
> 
> The specs avoid exposing the content of their data objects as WebDAV 
> properties. This leads to lots of workarounds, such as introducing 
> "pseudo-properties" containing the actual content 
> (CARDDAV:addressbook-data), and abuse of DAV:prop for something that is 
> not a WebDAV property. Don't do this, it requires generic WebDAV servers 
> to use lots of special cases. (WebDAV SEARCH started with pseudo 
> properties but got successfully rid of them, so this can be done).

As far as I recall, the feedback I got was that making them full-blown 
WebDAV properties would be both expensive, and lose flexibility. I am 
still not sure that I buy that.

But, accepting this for now, then CardDAV should really stop pretending 
that these pseudo properties are WebDAV properties in reports - it is 
really confusing, and makes implementing a generic server hard if 
something appears as a property only in specific contexts. Furthermore, 
the current specification makes it harder to re-use generic code, as it 
overloads not only the semantics, but also the syntax of DAV:prop.

Consider the use of DAV:prop in:

<C:addressbook-query xmlns:D="DAV:"
                   xmlns:C="urn:ietf:params:xml:ns:carddav">
   <D:prop>
     <D:getetag/>
     <C:address-data>
       <C:prop name="VERSION"/>
       <C:prop name="UID"/>
       <C:prop name="NICKNAME"/>
       <C:prop name="EMAIL"/>
       <C:prop name="FN"/>
     </C:address-data>
   </D:prop>
   <C:filter>
     <C:prop-filter name="NICKNAME">
       <C:text-match collation="i;unicode-casemap"
                     match-type="equals"
       >me</C:text-match>
     </C:prop-filter>
   </C:filter>
</C:addressbook-query>

-- <http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-8.6.3>

Here, DAV:prop contains both a true WebDAV property, and a pseudo-property:

   <D:prop>
     <D:getetag/>
     <C:address-data>
       <C:prop name="VERSION"/>
       <C:prop name="UID"/>
       <C:prop name="NICKNAME"/>
       <C:prop name="EMAIL"/>
       <C:prop name="FN"/>
     </C:address-data>
   </D:prop>

That pseudo property though needs special treatment, it's *not* just an 
identifier, but an identifier augmented with parameters. There's really 
no point in putting it into a DAV:prop, as generic WebDAV XML handling 
code is not capable to use it.

So, IMHO, the right thing here is to make C:address-data a top-level 
element in the request, as in:


<C:addressbook-query xmlns:D="DAV:"
                   xmlns:C="urn:ietf:params:xml:ns:carddav">
   <D:prop>
     <D:getetag/>
   </D:prop>
   <C:address-data>
     <C:prop name="VERSION"/>
     <C:prop name="UID"/>
     <C:prop name="NICKNAME"/>
     <C:prop name="EMAIL"/>
     <C:prop name="FN"/>
   </C:address-data>
   <C:filter>
     <C:prop-filter name="NICKNAME">
       <C:text-match collation="i;unicode-casemap"
                     match-type="equals"
       >me</C:text-match>
     </C:prop-filter>
   </C:filter>
</C:addressbook-query>

This also means that the response format needs to be extended; but 
again, this is a good thing - generic code handling multistatus/propstat 
will be confused anyway, so it's *good* not to overload DAV:propstat 
with things that do not belong there.

Note that during the development of WebDAV SEARCH (RFC 5323), 
pseudo-properties were used both for request (DAV:iscollection) and 
responses (DAV:score), but fortunately we got rid of these problems 
(see, for instance, 
<http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.16.1>).


Best regards, Julian

Received on Friday, 13 March 2009 16:56:58 UTC