[Cosmo-dev] simplifying eimml

[Phillip J. Eby]

At 01:40 PM 11/30/2006 -0800, Brian Moseley wrote:
>  <note:record>
>    <core:uuid>d1dd801c-f682-4bcb-b187-46b8c427e77f</core:uuid>
>    <note:body>Cosmo status meeting</note:body>
>    <note:icalUid>1e2d48c0-d66b-494c-bb33-c3d75a1ba66b</note:icalUid>
>  </note:record>

The above looks incorrect to me, btw; the elements should be item:uuid, 
note:uuid, etc., as there's no "core:uuid" in the EIM, nor do record type 
namespaces ever overlap.


>is there any benefit to using xml namespaces in this way?

Yes; it means that Chandler (and Cosmo) can write a single EIM<->XML 
mapping whose code will remain unchanged for all future transport schemas, 
and for all parcels developed in the future.  The transmission format is 
supposed to be a serialization of EIM, so that code on both sides simply 
reads and writes EIM records.

The *interpretation* of EIM records is a higher-level operation, and is an 
explicit part of Chandler's technical requirements.

Why?  Well, for example, yesterday Morgen and I hashed out an all-purpose 
diff-processing, attribute-filtering, *and* conflict-detecting sync 
algorithm for processing *arbitrary* EIM records for *arbitrary* parcels 
and schemas.  It seems a waste to have to reinvent all those wheels for 
one-off static formats.

The whole idea of the EIM model was to allow this sort of thing to be done 
on both sides.


>i would like to move rapidly on discussing this so that we can either
>accept or reject the proposal in the next couple days. the
>implementation changes on the cosmo side would not be that drastic,
>but i'd like to avoid forcing morgen to throw away code that he might
>have already written.

What about forcing Morgen to write two different sharing formats during 
a5?  :)  Because it seems to me that that's what you're 
proposing.  Chandler needs a general EIM exchange format for database dump 
and reload support, schema evolution, and sharing interop with multiple 
client versions.  The idea of having an general EIM transport format is 
that it allows the transmission schema to be varied independently of the 
transport format, so we're coding serialization and deserialization once -- 
and only once.