Kolab XML Format: Proposal for an XSD friendly update
Florian v. Samson
florian.samson at bsi.bund.de
Wed Oct 19 12:15:52 CEST 2011
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
> == 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:
(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.
More information about the format