On perserving tags (Re: Basic rationale of the KEP #2 design)

[Bernhard Reiter]

Am Mittwoch, 2. März 2011 19:20:09 schrieb Florian v. Samson:
> Am Mittwoch, 2. März 2011 um 16:50:15 schrieb Georg C. F. Greve:
> > On Wednesday 02 March 2011 15.06:34 Florian v. Samson wrote:
> > > Looking at the basic design decisions of the current Kolab Format, the
> > > choice of XML along with the clear statement that any XML-tags unknown
> > > to a client must be ignored was made to allow for easy extension of the
> > > Kolab Format (among many other properties) while retaining backward
> > > compatibility, by specifying new XML-tags.

I believe that the intend of the original authors of the Kolab Storage
format 2 was to have tags in the main part of a Kolab object to be
preserved. The text is not precise in this regards:

"If a client sees a tag it does not understand, this tag must be preserved and 
saved back to the file."

but
a) it makes sense from the view of a format developer to preserve only "main"
   tags and not all subtags. It would be technically and semantically hard.
b) In case of "anything is missing, unclear or contradicting" the well working
   behaviour of the reference clients will fill the gab. I'd say this is a bit
   unclear and contradicting the goal of a well meanin specification and as 
   far as I remember Kontact Proko2 and Toltec 2 both preserve only
   the "main" tags.

> > That requirement exists on paper, yes, but as we found out in the
> > discussions last year, not all clients meet it and it can therefore not
> > be relied upon.

I think we were worring about the two mentioned clients above, 
but understanding the spec as outlined above they are in compliance.
Georg, do you remember if there were there other clients that to not 
at least fulfill the spec as pointed out above?

> Well, it is a usual situation that some implementations of a specification
> fail to fully adhere to it.  The common solution is to fix the broken
> implementation.

Florian, as far as I could tell above, there is a common behaviour to 
preserve "main" tags. We established that this would lead
to an ugly XML structure if we would add a "main" tag there for the tz-id.
In addition the behaviour of old clients would still be quite off and we 
cannot affort this.

Even if there would not be a common behaviour of widely distributed clients, 
I believe Georg is right when he considers this for real world compatibility.

> But KEP#2 pursues the reversal of that: break the specification in order to
> adapt it to a single broken client.  IMO, this is not the right way for an
> initiative to handle their specifications, if losing reputation and
> fairness is something to be avoided.

I saw a sometimes convulted discussion, but well meaning of all parties.
Georg is not a Kolab Client developer, but I am. As you can see, I do not 
agree on all points with him, not for Kontact but also not for other clients.
On the other hand, the Bynari developers welcomed the current KEP.
That show that KEP2 does not prefer any type of client.
The Kolab community, including Kolab Systems, Intevation KDAB,
wants many clients. We go a long way to get consensus here,
but this is also the first time we attempt to do a significant change
to the main storage format.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110303/8c0b06dd/attachment.sig>