Small extension to the annotate proposal

[David Faure]

On Monday 12 July 2004 12:46, Stuart K. Bingë wrote:
> On Tuesday, 29 June 2004 10:41, David Faure wrote:
> > To make the proposal more precise:
> > We currently have
> >  /vendor/kolab/folder-type where value.shared is set to mail, event,
> > journal, etc.
> 
> I'd like to see the format updated to include client-specific annotations, as 
> sub-annotations of /vendor/kolab, e.g. /vendor/kolab/o-blah for 
> Outlook, /vendor/kolab/k-blah for Kontact and /vendor/kolab/h-blah for Horde 
> (as we do for additional client-specific XML tags).

Sounds good to me.

> As an aside, would it make more sense to use "vendor.kolab.blah" 
> sub-attributes of the /vendor/kolab annotation, instead of an annotation tree 
> under it? Both schemes seem pretty interchangable, however it may make more 
> logical sense to use attributes of an annotation to describe whatever 
> variables need describing, rather than storing them all in an annotation tree 
> (I'm thinking in terms of XML - /vendor/kolab describes the parent object, 
> and each vendor.kolab.XXX attribute describes a property of the parent 
> object).

I wondered too, but since cyrus-imap doesn't support this, we don't have a choice :)
It only supports a set of well-known attributes (like value.shared, value.priv, etc.),
no vendor attributes at all. So the only pragmatic solution (which isn't too bad
anyway), is /vendor/kolab/<annotation-name> and value.priv or value.shared as
the attribute.

> This is definitely being picky, but it seems rather redundant of the 
> ANNOTATEMORE extension to include provisions for both schemes.
I agree, it's a bit confusing due to being too flexible :)

> > I like the idea of adding
> >  /vendor/kolab/storage-format where value.shared would be "xml 1.0"
> > (referring to the kolab xml storage version 1.0". This would allow to set
> > it to 2.0 in case of major changes later, and it would also allow values
> > like "ical 1.0" or "vcard 1.0".
> 
> I would have to agree to this being added. More descriptive annotations are 
> good, in that if I don't know how to handle a specific folder I can then 
> simply ignore ("preserve") it, rather than making (possibly incorrect) 
> assumptions as to the folders' contents.

I thought we said that such an annotation would only help _writing_ to the folder.
When reading from it, the contents make it clear how to handle them (either by
looking at the mimetype of the attachments or by looking at the extra header
discussed in the other thread).

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions