Kolab XML Format: Proposal for an XSD friendly update

[Jeroen van Meeuwen (Kolab Systems)]

On 2011-10-19 11:15, Florian v. Samson wrote:
> Hello Christian,
>

Hi Florian,

> Am Dienstag, 18. Oktober 2011 um 18:46:24 schrieb Christian 
> Mollekopf:
>> == 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 
following options:

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

<?xml version="3.0">
<contact>
(...snip...)
   <pgp>
     <preferred>blabla</preferred>
     <sign>blabla</sign>
     <encrypt>blabla</encrypt>
   </pgp>
(...snip...)

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

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

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 
> all
> client's source code?  How do you assess exhaustively, which 
> Kolab-XML
> capable clients do exist?
>

Perhaps we are misaligning the roadmap from the point of having an XSD 
+ bindings.

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

>> - 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)
   save_to_imap('INBOX/Contacts', contact.message())

What exactly the code looks like is speculative at best at this point, 
though.

>> 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 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, 
> the
> developers of the various Kolab clients have vastly different 
> requirements,
> constraints, aims, resources (primarily time and manpower) and 
> vocality.
>

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.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08