Kolab XML Format: Proposal for an XSD friendly update

Christian Mollekopf mollekopf at kolabsys.com
Wed Oct 19 12:43:30 CEST 2011

On 19.10.2011 10:19, Tobias Koenig wrote:
> On Tuesday 18 October 2011 18:46:24 Christian Mollekopf wrote:
>> Hi,
> Hej,
>> === 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.

Yes, with the use of namespaces and with the unknown tags in a specific 
place this is technically possible. Otherwise you'll render the schema 
quickly non-deterministic which is not allowed in XSD.

>> === Undefined order of elements ===
>> This is mainly a technical problem for XSD. It is not feasible to
>> implement an XSD Schema with an undefined order of the elements.
> If the number of child elements is fixed, the <all> tag can be used
> instead of
> <sequence>, so this specific case of undefined order is supported by
> XML schema.

Because we have optional tags and sequences in the format we cannot 
make use of the <all> tag.

> But require a order of elements in the kolab format sounds like a 
> good idea
> anyway.
>> === No defined namespace ===
>> Because the current format lacks a namespace it is not suitable to 
>> be
>> used together with other XML technologies such as XSLT. The lack of 
>> a
>> namespace increases the chance of nameconflicts with other formats 
>> such
>> as ICAL. The design with a namespace is also more robust should we 
>> once
>> want to extend the format.
> ACK. Please use namespaces in the kolab format.
> Ciao,
> Tobias

More information about the format mailing list