[NEW KEP] KEP #17: Kolab XML Format 3.0

[Christian Mollekopf]

On 2012-03-08 19:28, Florian v. Samson wrote:
> Hi, Christian, all,
>

Hey Florian,

> first of all, I forgot to mention the RelaxNG schema for the
> Kolab2-Format, along with associated tests; you may already be aware 
> of
> it:
> 
> <http://www-old.kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/kolab-formats/validation/>
> Not really important any more, but it may be still helpful in order 
> to
> clarify linguistically imprecise terms in the prose-form 
> Kolab2-Format.
>

Yes, I'm aware of it, thanks.

> On to our conversation:
>

>>
>> We can add this at a later stage as a new optional property of the
>> format.
>
> No, not realistically!
> Technically you sure can, practically each change to the Kolab-Format
> will leave most of its clients behind for a long time.
> Or is Kolabsys planning to take care of patching ~10 Kolab-Clients 
> (see
> <http://www-old.kolab.org/about-kolab-clients.html>) each time the
> Format changes?
>

With libkolabxml we make it very easy for every vendor to update his 
implementation.
We maintain our main clients (Kontact, Roundcube, ....).

> So practically I suggest: Take your time, aim well, you got a single
> shot.
>

Not really, but we also shouldn't change the format ever week, to that 
extend I agree.

>> Of course all clients need to be upgraded if the new format
>> is used in a Kolab environment, otherwise the property would of
>> course be deleted again. (if the client overwrites an object with a
>> newer version of the format, which is bad behavior)
>>
>> > > and map free to
>> > > "TRANSPARENT" and the other three to "OPAQUE" (for the 
>> conversion
>> > > of existing properties of this type).
>> >
>> > As stated: these two setting are IMHO and memory mostly unrelated,
>> > as they express different things.
>> > You can employ such a mapping between them, but to me this is like
>> > mapping a small set of pretty different colours (e. g. red, green,
>> > blue, yellow) to black & white (no shades of grey): feasible, but
>> > the outcome may be surprising.
>>
>> I get your point and can see the additional information expressed by
>> this setting, but:
>>
>> - The setting is only valid if the opacity is set to OPAQUE,
>
> Yes.
>
>> and we
>> should try to avoid such conditional settings as far as possible,
>> because they add a lot of complexity to the format.
>
> While I agree to the "try", I do not to the "as far as possible" and
> especially not to "they add a lot of complexity to the format".
> There are far more complex things in the format.
>

Not if we're talking about the writing/reading of the format. That 
interpreting recurrences is more complicated is clear.

>> - Kolab Format v2 used this as a replacement for the OPACITY 
>> setting,
>> so the potential for conflicting use of the property is high.
>

I have that information from the Kontact implementation (master, not 
e3).

> I am not sure that is correct, as I cannot find any such statement in
> chapter 4 of the Kolab2-Format.  Maybe I just did not find it?
>
> Even if so, it is clearly a misuse, which regularly confuses users.
>

It's not a misuse, it's just a reduced use as this property is not 
actually mappable to iCal,
which is what Kontact is based on.

>> - I don't know of any real usecase of the setting. I understand that
>> there is a potential usecase, but I don't believe it's overly useful
>
> Oh, there is, definitely: I can note some, if I have time to properly
> think them through, again, and to write them down, if that really is
> helpful for you (please say so, then).
>

I don't doubt that there are usecases. I just think we can do without.

>> and don't know of any user-interface where this setting is actually
>> exposed.
>
> In Kontact, and other PIM-clients.
> That is actually causing the confusion: People expect both settings 
> to
> do something, but in practise they seem to influence things not at 
> all,
> or rather erratic ways. Too many things are broken around F/B-lists 
> to
> easily test that.
>

So I suppose we're better off removing that "feature".

>> It's not in Kontact or Roundcube for sure.
>
> That is definitely not true: It has been in all Kontact versions, 
> which
> are or have been productively usable (Proko2, E35).
> (See also attached Kontact-E35 screenshot.)
>

Ok, I was talking of the current KDE version (KDEPIM 4.8.1). So no 
client which will be upgraded to the new format in the near future will 
have a UI for this,
and I don't expect that to change anytime soon as this is a Kolab-only 
feature (it's not in iCal).

>> So I reckon it has been used as a replacement of OPACITY anyways.
>
> No.
>
>> > > > b. # 1.4.1.6 Classification
>
> My comments were just some thoughts on this topic; maybe I should 
> have
> tried to express that more clearly.
> Hence I do not disagree with anything you replied.
>

Cool.

Cheers,
Christian