Text Remarks

[David Faure]

On Thursday 07 October 2004 16:29, Bernhard Reiter wrote:
> In the train on the 4th I could browse the full kolab-format spec.
> Here are a couple of remarks, somebody who implements
> this should be the keeper of the scrolls. (David?)
Yes.

> section 1.2. Proposed fix: add <type version=""> and a description...
Done.

> 2.1. IMAP requirements
> 
> It says:
>      The INBOX will have the IMAP resource subfolders (like we do today in the clients),
> This seems to be not very precise, especially the part in brackets.
> Proposed fix: elaborate a bit and/or reference another document
Done.

> Should this be "k-" and "h-" or so, because this is how it is done in the 
> example?
Done.

> Proposed fix: Remove the paragraph.
Removed.

> 4.1. Common In All Types
> uid
>  shouldn't we describe further what could be an UID,
> string would also allow newlines and spaces and we probably do not
> want them in the UID. Or do we?
> Proposed fix: Describe more rules for "uid", beyond string.
OK, 7-bit would avoid causing encoding problems, but other than that I 
see no reason for further restrictions (we just store the uid as a string....).
Joon: do you have restrictions on the characters used in the uid? I vaguely
remember a discussion about that (on irc) but I don't remember the outcome.

Anyway, Toltech and Kontact seem to stick to [a-zA-Z0-9.-] currently.

> Later:
>     The categories is a comma separated list.
> What did that sentence want to say?
> Proposed fix: Rephrase.
It looks clear to me: <categories> contains a comma-separated list of categories.
(is that way better than the way in the document, because of "the categories is"?)

> 4.2. Common In Tasks and Events
> It says:
>      In the case of a all days event (floating event) ...
> how to we distinquish between a "floating" and a 24 h event?
This seems clear to me too: floating events have no time information,
a 24h event would have  time information, as the spec says.

> 4.2.1. Recurrence
> 
> The strings "Daily", "Weekly" habe a capital letter, but they 
> are probably meant lower case. Tag names are case sensitive
> says 1.2, but does this also hold for the list of possible attribute values
> and the attribute names itself?
> Proposed fix: Add statement about case sensiticity to 1.2 and 
Done.

> write Daily as "daily" if it was meant lower case.
> Also with Weekly, Montyly and Yearly.
Fixed.

> 4.2.3 Examples
> 
> It might be good to have one example with attendees,
> there is none.

I disagree - this is the examples section that details the various recurrence
rules. All other sections do not have actual examples with fake data,
since the beginning of every section *is* a kind of example already.

We would end up with even more duplication if we repeated the whole
structure of an e.g. event with all the fields yet again.

[For more examples with fake data there is the validation/tests directory]

> 5. Format of Notes
> There is no reference to 4.1 Common In all Types.
> This is the same with 6., 7., 8. and  9.
Added a link in the description.

> If we have a common field section, there is no need to specify
> it several times. 
You mean we shouldn't have the fields? Well the whole idea was (AFAICS)
to have self-contained "examples" of how an event looks like.
It's not practical if, in order to look for the fields of an event, you have to consult
3 sections. Hence the repetition.

> Also <product> seems to be missing from 5.6.7.8. 9.
> which is in 4.1.
You mean product-id I assume? Added.

> 6. Format Of Contacts
> beside the issues mentioned under 5.
> It would be interesting to add how many addresses of which
> type need to be displayed at least to the user to be compliant.
"type" is home or business or other. Do you mean the spec should
say "Clients should be able to display at least one address of each type"?
If you want, but I thought clients supported more than one address of each
type anyway - for sure kontact loads and displayed all addresses.
Unlike the phone stuff, this isn't a "one of each kind" type of data,
it's a list of addresses, with a flag (the type) on each.
Joon: is that different in outlook?

> 8. Format Of Events
> This seems to be a largely duplication of Chaper 4.2.
Well, yes, but this is in order to provide a full "example" of how an event looks like.
You requested examples, didn't you? :)

> We also need to specify somewhere how a categories
> of "personal" will be handled as this would be interesting
> for freebusy list creation. So maybe we need a few fixed
> categories that can get translated.
OK this is something I know nothing about - was it discussed already?
<categories> is pretty generic in the format currently. Do you really want
to abuse that one, or shouldn't this rather be done in a separate field?
What's the relation to freebusy-list-creation?

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