[Chandler-dev] Type Definitions for sharing format API

[Grant Baillie]

On 1 Nov, 2006, at 10:12, Phillip J. Eby wrote:

> 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.

Ah, cool.

> 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.

I have a couple of things I'm busy with this week, including writing  
up some domain model documentation, which should help, indirectly,  
with this, but I'll take a look next week.

--Grant