On "Preserving all occurrences of the same tag" in the Kolab-Format spec

[Florian v. Samson]

Hi Gunnar,

Am Freitag, 15. Juli 2011 um 11:43:37 schrieb Gunnar Wrobel:
> Quoting "Florian v. Samson" <florian.samson at bsi.bund.de>:
> > 
> > The way out is to store all unprocessable / undisplayable information
> > in a covered manner (i.e. protected and somewhat hidden; we called it
> > "Kolab store" as a working name [1]), when converting into the internal
> > data format.  Still this data can be used to differentiate entries by
> > comparing these strings (although uninterpretable), if they differ (or
> > compare hashes of them).  When converting back to Kolab-XML these
> > covered information has to be uncovered by writing them unaltered back
> > to Kolab-XML.
>
> Hm, that sounds somewhat cumbersome. 

It is, and ...

> I would say that you already have that "Kolab store" and don't need 
> to implement it: the XML itself. 

... only necessary, if you do not control the whole client, e.g. when 
extending an existing client to become a Kolab-client.  
Existing PIM-clients do have their predefined internal data format (e.g. 
Outlook, Thunderbird/Seamonkey, Evolution) from which and to which the 
Kolab-XML has to be converted.  The same is implicitly true for clients 
synchronising via SyncML or Active-Sync with Kolab, where at least one, if 
not multiple conversions occur on each way (back and forth). 
So the vast majority of Kolab-clients do have to utilise format-conversions 
somewhere.

> It contains all information and I don't see a need to rewrite the 
> whole document. 

But then you already provided the answer for yourself: wherever possible, 
avoid format-conversions and operate on the Kolab-XML directly.

> The only problem I still have with that approach: the unique 
> ID for each node/tag that may occur multiple times. 

Oh yes, true, we may have to state an exemption explicitly that the ID-tag 
MUST NOT occur multiple times due to the fact that it MUST contain an 
unique identifier.
Or (alternative approach) the only the first (or last) occurrence of the 
ID-tag is valid and that its (of the last ID-tag) ID MUST be used.
I tend to approach #1.

> But I still believe it shouldn't be too hard to generate.

Sorry, can you please rephrase that, I fail to understand its meaning.

Cheers
  	Florian