On preserving unknown XML-tags and their content in the Kolab-Format specification
Florian v. Samson
florian.samson at bsi.bund.de
Thu Jun 16 14:23:25 CEST 2011
Thoughts and suggestions on preserving unknown (i.e. future) XML-tags and
their content in the Kolab-Format specification:
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, 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, but strongly believe that limiting
tag-preservation to top-level XML-tags only vastly reduces 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"
instead of a "MUST", but I think the general direction must be clear.}
1b. If a XML-tag appears multiple times within one Kolab-XML-object, ALL
occurrences of this XML-tag MUST be preserved.
{Currently some clients only preserve their first occurrence, discarding all
other occurrences. Explicitly allowing this behaviour simplifies some
things. More detailed reasoning can be requested from Hendrik.)
2. {Bernhard pointing out semantic issues, when old clients hit newly
defined XML sub-tags (unknown to them) embedded in existing, known
XML-tags, and such a client alters the known fields. Yes, this issue does
exist, the content of the unknown (hence untouched) XML-tags my become out
of sync relative to the known tags which may be altered by the old client,
but I think ...
I. ... it is easily overcome by defining the XML-tags and their content
properly, so they do not contain duplicate or dependent information,. In
case of orthogonal (i.e. completely unrelated/uncorrelated information,
this is a non-issue.
II. ... furthermore, that is a minor issue even without such carefully
specifies XML-tags, compared to limiting the extensibility of the
Kolab-Format to top-level XML-tags only, when rule 1 (above) is mandatory.}
3. The maximal depth of nesting XML-tags MUST be limited to 7 levels.
{A suggestion from Bernhard in order to limit the size of and parsing
efforts for Kolab-objects, which otherwise may be used for
Denial-of-Service attacks.}
a. Please discuss!
b. Do we need similar, but separated statements for XML-attributes?
Cheers
Florian
More information about the format
mailing list