Small extension to the annotate proposal

Stuart K. Bingë omicron-list at mighty.co.za
Mon Jul 12 13:33:58 CEST 2004


On Monday, 12 July 2004 13:08, David Faure wrote:
> > > 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).

Well, again, we need to update the format docs then, if this case is to be 
handled.

Personally, I still can't see why you would ever want to have anything except 
a single format (e.g. Kolab XML version 1.0 "Note" objects) in each folder - 
if you can have multiple formats, then what's stopping you from just dumping 
all your groupware objects in a single folder? And in turn, why would we even 
need the /folder-type annotation if all it's doing is misleading us as to 
what is actually stored in the folder?

I can see that if we are to have, for example, "Calendar" folders, then we 
expect all data within that folder to be Calendar data, of some format or 
another. However, if we then need to handle the case that there may be 
multiple calendar formats within that folder when reading, 
then /storage-format really becomes redundant as a client can completely 
ignore it while writing, and still be compliant. And again, having 
a /storage-format of, say, "Kolab XML version 1.0 Calendar" when the contents 
may in fact not be Kolab XML version 1.0 Calendar data, seems to be a pretty 
useless exercise.

Anyway, I think all of this needs to be explicitly mentioned in the format 
docs before they are published - just from the confusion over interpretations 
of the format on this list alone gives an indication that the format needs to 
be revised (luckily it's still in draft).

-- 
Stuart Bingë
Code Fusion cc.

Office: +27 11 673 0411
Mobile: +27 83 298 9727
Email: s.binge at codefusion.co.za

Tailored email solutions; Kolab specialists.
http://www.codefusion.co.za/




More information about the format mailing list