Kolab XML Format: Proposal for an XSD friendly update

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Wed Oct 19 10:39:37 CEST 2011


On 2011-10-19 9:19, Tobias Koenig wrote:
> Hej,
>

Hi Thomas,

> On Tuesday 18 October 2011 18:46:24 Christian Mollekopf wrote:
>> === Preserving of undefined tags ===
>>
>> Preserving unknown tags is far from trivial and a rather big
>> development effort. I understand the use of an extensible format as 
>> it
>> makes it very easy for vendors to implement their own special 
>> features
>> using extensions (aka unknown tags). Also the idea that old clients 
>> can
>> still make use of a subset of the data of
>> newer versions of the format is intriguing. However I think there 
>> are a
>> couple of severe drawbacks which make me think unknown tags are not 
>> a
>> good idea after all.
>
> While XML schema supports the definition of undefined child
> elements/attributes on an element (see <any>), the autogenerated 
> parsing/assembling code
> might not be able to handle them... However that's more a technical 
> problem
> (that can be solved) than a design problem.
>

The use of <any> would negate the value of being able to generate the 
bindings that are to be used by applications and other libraries for the 
purpose of cross-platform and cross-application consistency.

Please note that many implementations of the specification today do not 
preserve unknown tags either, so the loss here is minimal.

For those applications and libraries to be able to use the bindings for 
any XML tags that they would like to add, they would basically have to 
fork the XSD, and generate a (thus also forked) set of bindings.

At this point, other applications would yet not know about the extended 
format, but since the XSD is already forked we recon the other 
applications within a deployment are just as easily updated with the new 
bindings from the forked XSD.

In this scenario, *not* allowing unknown tags actually helps us to let 
the XSD + bindings become the one-throat-to-choke still providing (to be 
clearly outlined?) opportunity for vendors and third parties to extend 
the format outside of Kolab.

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




More information about the format mailing list