Update: On "Preserving unknown XML-tags and their content" in the Kolab-Format specification

Bernhard Reiter bernhard at intevation.de
Wed Sep 28 15:32:04 CEST 2011

Hi again, 
here is the second post to the topic. Take the introduction from my post
just a minute ago. ;)

Am Monday, 20. June 2011 10:01:19 schrieb Florian v. Samson:
> 1. Kolab-clients SHOULD retain all unknown XML-tags and their embraced (i.e
> embedded within the opening and closing tag) content, regardless of their
> position in the XML-tag-tree and of their content (e.g. sub-tags); But all
> Kolab-clients MUST retain all top-level XML-tags along with their full
> content within an Kolab-object.
> {Some argue, only the latter statement shall be put into the Kolab-Format
> specification.  I do see the hurdles for various clients to implement the
> preservation of *all* unknown XML-tags regardless of their position in the
> XML-tree, but strongly believe that limiting tag-preservation to top-level
> XML-tags only vastly reduces the extensibility of the Kolab-Format, as
> mixed environments with both old and new clients are extremely problematic
> to impossible then.  Hence the rather weak "SHOULD" (for this kind of
> statement), instead of a "MUST", but I think the aim and general direction
> must be made absolutely clear.}

I'm not principally opposed to full tag preservation in general, especially 
not as no client developer stood up with major practical problems. Gunnar had 
one that would partly count for me, hinting up that the GUI-behaviour should 
be part of the "client implementors manual" that we would actually need 
instead of the storage "format" specification. And GUIs cannot know
about upcoming new "attributes".

From my perspective I find the proposed rules a little to complicated as well.
So why not only allow tag-preservation at one level? E.g. within the 
type-defining tag, e.g <task version="1.0" > and then allow "sane" tags only.
("sane" as defined in the email send a few minutes ago.)

Client would then be know exactely one level they need to preserve a number of 
tags and not look into them. If they know something in there, they can use 
it. Otherwise they just carry it through. In addition I would possibly add a 
tag counter, how often the object had been changed, aka rewritten, without 
the preserved tag being touched. This can be an outdated hint towards the 
extending applications.

This would solve the problem that some clients could just add their extra 
information in without waiting for a new format variant. So it is bearable, 
but not comfortable. For getting comfortable they would need to make their 
extension known the the Kolab community and get the format extended.

Best Regards,

Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110928/3f4a3c42/attachment.sig>

More information about the format mailing list