Kolab XML Format: Proposal for an XSD friendly update
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Wed Oct 19 13:49:45 CEST 2011
On 2011-10-19 11:15, Florian v. Samson wrote:
> Hello Christian,
> Am Dienstag, 18. Oktober 2011 um 18:46:24 schrieb Christian
>> == 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.
It actually does not inhibit anything.
Those vendors or third parties that wish to extend the format have the
- Use the original, upstream Kolab XSD (+ bindings) as the basis and
fork() it, making it easier for said vendors/third parties to extend the
format across all clients they wish / choose to support,
- Circumvent the entire Kolab XSD and read/write XML objects according
to their own specification as they see fit, which naturally is likely to
lose support from "other" Kolab clients not included in the realm of
supported clients with that vendor / third party,
- Propose the extension be integrated in the Kolab Format XSD upstream
through the KEP process.
Note that for example storing "German Tax Authority Codes" in a
contact, may very well be classified -in the context of XSD- as a
"<custom/>" XML tag, with a "label" describing the value stored, and of
course the value, perhaps not so strictly limited to a string,
basestring, integer, or whatnot.
Other fields, such as Kontact's PGP preference storage, may very well
be made a:
as it pertains to virtually every client capable of supporting any sort
of PGP. This is just an example, however, not the case in point.
As a result, by using the XSD, clients can easily be updated to using
the new XML Format, without having to adjust any program specific logic
- it'd be the bindings said program uses that'd be updated, at which
point the program itself isn't necessarily processing and presenting the
associated feature quite yet.
It does, however, as an intentional side-effect, make all client
programs blissfully aware while blissfully ignorant.
Doing so through an XSD (+ bindings) will make it far easier to extend
> E.g. for clients which have to use a different "native" format
> (evolution-kolab, Toltec, etc.) this is necessary for storing
> which cannot be mapped to Kolab XML but must be retained.
There's options to store this information elsewhere, such as in the
client's account state, but naturally the XSD-based format will need to
allow storing this in the Kolab XML object - which it does.
>> - include now used unknown tags into the format
> Which ones? All? How do you plan to find out about them? Reading
> client's source code? How do you assess exhaustively, which
> capable clients do exist?
Perhaps we are misaligning the roadmap from the point of having an XSD
Firstly, there's a relatively small group of current Kolab clients we
know about, that would need to be updated to using the XSD generated
bindings. We will most likely 1) engage the developers of said Kolab
client, and 2) find out about custom, currently unknown tags they wish
to store as part of a Kolab XML object.
Secondly, we are on this list to ensure visibility of what we are
planning on doing.
Thirdly, this major change would have to become a KEP, and be approved
>> - 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.
The client would not have to support XML namespaces.
In fact, the client itself would not have to support XML at all.
The client would use generated bindings, which may be extended to the
tune of a client simply doing (simplest case only storing email address
to a folder);
contact = new Contact(email)
What exactly the code looks like is speculative at best at this point,
>> I believe we can significantly improve the Kolab XML format this
> IMHO that should not be a isolated goal: the Kolab XML format has no
> on its own right, only Kolab-clients utilising it have any practical
> for customers and users.
Hence the Kolab Format inherits value, by allowing these clients to use
and re-use the same information and thus provide option value to
consumers and users.
> Hence companies only can charge customers for
> working software, not for a nice storage format.
Hence the Kolab Format inherits value, as working software can now
abstract handling XML, abstract handling the conditions under which some
or the other element may or may not be written out in such-and-such
format, ultimately improving the bottom-line, features, quality and
sustainability of both the software as well as the format, to both of
which companies today have already made significant investments, as I'm
sure you will agree.
> Surely a well defined Kolab format can ease the job of Kolab client
> developers, but as discussed extensively in the past on this list,
> developers of the various Kolab clients have vastly different
> constraints, aims, resources (primarily time and manpower) and
This, though, I would not consider a blocker necessarily, I would
consider them requirements to fulfil by those seeking implementation of
the aforementioned, like in most other cases.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
pgp: 9342 BF08
More information about the format