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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
