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

[Florian v. Samson]

Hi, Christian, all,

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.

On to our conversation:

Am Dienstag, 28. Februar 2012, 01:08 schrieb Christian Mollekopf:
> On Monday 27 February 2012 19.50:11 you wrote:
> > Am Montag, 27. Februar 2012, 15:39 schrieb Christian Mollekopf:
> > > On Monday 27 February 2012 10.23:08 Florian v. Samson wrote:
> > > [...]
> > > > a2. In # 1.4.2.3 Todo
> > > >
> > > >     and # 1.4.2.4 Event
> > > >
> > > > As "show-time-as is one of free, tentative, busy, or
> > > > outofoffice", it is about *how* a free/busy-relevant may be
> > > > displayed in an (extended) free/busy-list. This aspect is
> > > > orthogonal to transp (# 1.4.2.1.7). OTOH, if I remember
> > > > correctly that time-frames explicitly marked as "free" (by
> > > > show-time-as) cannot by differentiated in (X)FBs from
> > > > unallocated "free" times, then there is an some overlap in
> > > > meaning. If my memory was wrong, Kolab3 IMHO should express
> > > > "free" and simply unallocated times differently when generating
> > > > (X)FBs.
> > > > Also, IIRC, transp solely controls relevance of an incidence
> > > > (e.g. event) for generating free/busy-lists, while show-time-as
> > > > also has to be evaluated for automated resource handling. I
> > > > would hope for some information on this in the Kolab Format
> > > > specification v2, but have not taken a look, yet.
> > >
> > > I couldn't find any useful information on the topic in the v2
> > > specification.
> > >
> > > * I still don't really get the concept of a f/b opaque event
> > > which is "free"... how is that different from a f/b transparent
> > > event? Of course you gain the information that the user
> > > explicitly set this time to free (i.e. he's sure that it's free,
> > > and didn't just not enter events there yet), but I don't see a
> > > real usecase here and think it's a bit overly complex.
> >
> > See below.
> >
> > > * Also tentative seems overkill (if it means "I MIGHT be
> > > blocked")
> > >
> > > * busy looks like the same as opaque.
> > >
> > > * outoffice seems to mix with the location of the event, so also
> > > not a really clean solution.
> >
> > Not really IMO.
> > Think of these categories as ...
> > - outofoffice:  Absent, i.e. busy and unreachable
> > - busy:            Busy, but basically reachable in house
> > - tentative:    Likely busy
> > - free:             Not busy (Useful for presence-phases, where one
> > has to be sitting somewhere, but has no task allocated yet; or
> > creating pseudo-events, which do not block the time, as reminders;
> > etc.)
> >
> > Outofoffice does *not* specify any location, it simply states
> > "absent".
> >
> > Historically, I believe, this setting originates from the
> > introduction of XFB-support.
> > Sorry, I would have to research again (as I completely forgot over
> > all those years) all the extra abilities XFBs (Extended Free-Busy
> > Lists) provide compared to the classic, simple FBs.  But AFAIR XFBs
> > can distinguish these subtle differences (FBs sure cannot, as they
> > only know "free" or "busy") (although my memory may play tricks on
> > me). If so, then they should, IMO.
> >
> > How the XFB-data is actually displayed is another, different story.
> >
> > Maybe asking someone else might help, who has not ceased
> > administrating Kolab-Servers more than half a decade ago (like
> > myself), e.g. Bernhard Reiter.  Or finding proper XFB- and
> > FB-specifications, which I have not found immediately on the net.
>
> Ok, good to know.
>
> > > Given that this property doesn't exist in xcal and is nowhere
> > > used (AFAIK)
> >
> > Oh, I missed to also insert this here:
> > > > I am not sure, if that is in line with current
> > > > behaviour, but as this is regularly an area of user complaints
> > > > (often: setting appears to be non-functional and/or
> > > > inconsistent across different Kolab-clients), a proper
> > > > (behavioural) definition in the Kolab Format v3 is a big step
> > > > forward.
> > >
> > > I'd rather leave this property out for now (we can still add
> > > it at a later stage if we see a real need for it)
> >
> > Uh, not really: Once Kolab-Clients implement this altering and
> > adding things in this spec will be a major upheaval.  IMO your "we
> > can still add it at a later stage" is only valid, as long as this
> > KEP#17 ist still in draft-status.
>
> 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?

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

> 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.

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

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.

> - 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).

> 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.

> 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.)

> 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.

Cheers
	Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact-screenshot.png
Type: image/png
Size: 40999 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20120308/3e9a20a9/attachment.png>