[Cosmo-dev] sharing update 12/19

Phillip J. Eby pje at telecommunity.com
Tue Dec 19 16:52:34 PST 2006


(I should qualify the following statements by saying that I'm going off of 
the *examples* in the EimmlSpec page, not the actual schema docs.)


At 04:07 PM 12/19/2006 -0800, Brian Moseley wrote:
>i've finished updating the eimml spec based on my conversations with
>morgen and grant from last week and today:
>
><http://wiki.osafoundation.org/bin/view/Projects/EimmlSpec>

eim:uuid is not a universal attribute and shouldn't be namespace-prefixed 
on either recordsets or records.  EIM itself has no native notion of the 
concept of a UUID for records; it's just another field, that might happen 
to be named uuid, and is unrelated in any way to other records that might 
have an attribute named 'uuid'.

(Meanwhile, the uuid field on EIMML recordsets is also unrelated to any of 
the other fields named "uuid", and it's also not part of EIM but rather a 
transmission-level artifact for EIMML.)

So, be sure not to code any assumption that a "uuid" field has to exist on 
any given record type, or that it's necessarily the primary key field for 
that record type.  Such assumptions will break as soon as we allow 
third-party parcels to define arbitrary EIM records.

(Of course, by the time we do that, we should have standardized on an EIM 
representation for EIM schemas, in which case you'll be able to know what 
the field types and key fields are for any record types in a 
transmission.  So, as long as you highlight where such assumptions are for 
future removal, you might be okay in the short run.)


>i'm continuing to work on rounding out cosmo's eimml implementation,
>including handling of unknown record types, and checking spec
>conformity by writing unit tests. i expect to be done with this by the
>end of the week.

FYI, Morgen has tests for the current Python EIMML implementation here:

http://svn.osafoundation.org/chandler/trunk/chandler/parcels/osaf/sharing/EIMML.txt

They include some EIMML samples that should make it easier to see where the 
spec is out of sync w/Morgen and my vision of how EIMML works.  (They also 
demonstrate the generic sync/diff algorithms, although not in terms of XML 
effects.)



More information about the cosmo-dev mailing list