[Chandler-dev] Re: Next steps: external information model

[Phillip J. Eby]

At 12:05 PM 9/7/2006 -0700, Brian Moseley wrote:
>wanted to follow up on this with you and bring bobby and ted into the loop.
>
>we're going to have to assume that cosmo's code is never going to be
>able to keep up with chandler's evolution, let alone the evolution of
>third party parcels, so we're going to need some policy for handling
>things that we don't understand.
>
>to use the xml from
><http://wiki.osafoundation.org/bin/view/Projects/ExternalInformationModel>
>for examples:
>
>let's say cosmo doesn't understand the contact namespace. what do we
>do with the <cta:record> that we find in that record stream? we
>certainly don't want to lose the data. i think we could just store the
>record as a generic type name and set of namespaced string attributes,
>so that we could at least send back what chandler gave us, even if the
>web ui doesn't do anything with the data.
>
>also, do we need preserve type information? does cosmo need to know or
>care that <con:createdOn> is a timestamp? probably, since eventually
>the web ui will want to display it as such. but what about for third
>party namespaces that we don't know anything about?
>
>i'm tempted to rely on xml schemas to communicate type information.
>cosmo could look at the content item schema to determine that
><con:createdOn> is a timestamp and store the value as such. this would
>probably require us to package the schemas with cosmo and to require
>schema updates on the client end to be backwards compatible - or again
>for cosmo to have a reasonable way to cope with unexpected schema
>changes.
>
>do you see any problems with using xml schemas? we could alternatively
>encode type information right into the xml, but i don't like the
>verbosity and implied inefficiency.

If we have this kind of meta-information, I'd like to represent it in EIM 
form, rather than having another format.  It means that we don't need to 
have multiple formats for the same information.  An XML schema seems like 
overkill, given that we are talking about essentially relational data here; 
a simple 3-field record structure of the form (table, column, type) 
suffices to encode almost all the meta-information for a transmission, 
assuming that we have some reasonable vocabulary for "type".  The other 
piece of information that might be relevant is uniqueness and inter-table 
constraints; with that information you could literally construct tables in 
your database to store the  exact EIM data.  (Which would also leave open 
the interesting possibility of having query APIs against it.)

Now, there's no reason you can't transform this kind of information into an 
XML schema, but unless it gives some additional benefit vs. just slapping 
together a few basic record types and an initial type vocabulary, I don't 
see a reason to add the XML schema part.

To put it another way, both Cosmo and Chandler are already going to have to 
have code to read, write, and understand EIM records, so why also add code 
to read/write/understand an XML schema too?  :)  So we might as well 
represent any schema information as some additional EIM records that just 
have a hard-coded schema.