Kolab XML Format: Proposal for an XSD friendly update

[Florian v. Samson]

Hello Christian,

Am Dienstag, 18. Oktober 2011 um 18:46:24 schrieb Christian Mollekopf:
>
> Because the various implementations of the Kolab XML Format are
> difficult to maintain and are very error prone, the idea of a library to
> read/write the XML objects came up. Till and Volker from KDAB pointed
> out that using databindings based on an XML Schema (XSD) would be the
> ideal tool to develop such a library. The process of writing this schema
> brought up several problems with the format which I'm going to outline
> here.
>
> == Why do we need a schema ==
>
> The current format specification is not very explicit about some
> details and up to interpretation in these parts. A schema would give us
> a much stricter specification which also allows XML files to be
> validated against the spec.

IIRC, that was the reason, why the Kolab developers crated a Relax-NG schema 
6 years ago: 
<http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/kolab-formats/validation/>
(BTW, this is linked on Kolab.org's frontpage.)
It may be a useful starting point.

> ...
>
> == Conclusion ==
>
> Because of these reasons I propose to change the Kolab XML Format in
> the following ways:
>
> - disallow unknown tags

Not allowing any tags undefined by the Kolab format goes way too far, as it 
inhibits any client-specific extensions.
E.g. for clients which have to use a different "native" format internally 
(evolution-kolab, Toltec, etc.) this is necessary for storing information 
which cannot be mapped to Kolab XML but must be retained.  Hence 
disallowing any unknown tags would either render these clients non-working 
or these wrapper-tags would have to be defined in the Kolab format.  
There are a couple of other reasons, some of which already have been pointed 
out, e.g. by Thomas.

> - include now used unknown tags into the format

Which ones?  All?  How do you plan to find out about them?  Reading all 
client's source code?  How do you assess exhaustively, which Kolab-XML 
capable clients do exist?

> - make the order of the elements a requirement

Ack.  This has limits, though.

> - introduce a Kolab namespace

This is scarce use of namespaces, in the light of the fact, that this is a 
new fundamental requirement for clients to support XML namespaces.

> I believe we can significantly improve the Kolab XML format this way.

IMHO that should not be a isolated goal: the Kolab XML format has no value 
on its own right, only Kolab-clients utilising it have any practical value 
for customers and users.  Hence companies only can charge customers for 
working software, not for a nice storage format. 
Surely a well defined Kolab format can ease the job of Kolab client 
developers, but as discussed extensively in the past on this list, the 
developers of the various Kolab clients have vastly different requirements, 
constraints, aims, resources (primarily time and manpower) and vocality.

Cheers
	Florian