[Chandler-dev] Type Definitions for sharing format API

[Phillip J. Eby]

At 09:31 AM 9/28/2006 -0700, Grant Baillie wrote:
>Hi, Phillip
>
>This all makes sense ... I imagine the API would provide typedefs for
>common non-primitive types, like signed integer, or floating-point.
>Out of curiosity: why the restrictions on length of Bytes and Text
>(and the size of Integer)?

Sorry for my month-delayed reply; I somehow missed this message the first 
time through, and just saw it mentioned in Katie's September post summary.  :(

The restrictions were based on the current use cases for Cosmo-Chandler 
integration.  Nothing stops us from adding more types later, should the 
need arise, however.

The Integer definition was chosen because 32-bit signed integers are common 
to most programming languages, especially Python and Java.  The bytes/text 
size requirements were based on the need for efficient relational 
implementation on the Cosmo side.

And yes, we would have typedefs for common non-primitive types.

I just checked in the type and record-level API (osaf.sharing.eim) 
yesterday, so you can see the docs for how to define typedefs and type 
converters and such.  Now, in fact, would be a good time to begin deciding 
what typedefs and converters we would like to have for our domain 
model.  At the moment, I've only defined a converter from 'int' to 
'Integer', and haven't even registered any aliases from schema.* type names 
to any primitive types.  We would also need to assign URIs for any types we 
set up in this fashion.