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,
Bernhard
--
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