# Presentation: 625231

## Mentor Guides

***Primitive Datatypes***

## Agenda

**Acknowledgements**
**Issue**
- It has been recommended that caBIG applications not use Java primitives since data is moved around on the gird via XML Documents
- The schema used by the Grid to move data use XML Schema Datatypes and thus valid XML schema datatypes are needed
**Background**
- Current mappings in caBIG applications submitted for registration using Java primitives are mapped to java.lang.X  datatypes in caDSR
- Developers have a valid need to use primitives when processing the data after retrieving it from a Grid service
**Solution**
- Implement the caDSR Datatypes white paper recommendations
**Next Steps**
- Priorities for implementation
**Questions**

## Acknowledgements

**Mentor Guides**
- Robert Freimuth
- Lewis Frey
- Tahsin Kurc
- Patrick McConnell
- Salvatore Mungal
**caGrid**
- Scott Oster
**Mentors**
- Baris Suzek
- Quan Chen
- Dong Fu

**VCDE Workspace Lead**
- Brian Davis
**Architecture Workspace Lead**
- Mike Keller
**NCICB**
- George Komatsoulis
- Denise Warzel

## Issue

**caBIG applications are supposed to use Java primitives**
- Java primitives represented in UML diagrams are mapped to their object counterparts on caDSR.
- This was an initial decision made early in the evolution of caBIG
**There are 8 Java primitives:**

| Primitive | Object |
| --- | --- |
| byte | java.lang.Byte |
| short | java.lang.Short |
| int | java.lang.Integer |
| long | java.lang.Long |
| float | java.lang.Float |
| double | java.lang.Double |
| char | java.lang.Character |
| boolean | java.lang.Boolean |
|  |  |

## Concern

**caBIG applications using Java primitives and their corresponding Objects would lead to an interoperability issue when shared across the grid**
- For example, the way the current implementation exist, two applications trying to share data with one using “**int”** and the other “**java.lang.Integer” **would lead to a interoperatibility issue because their datatypes do not truly match.
- caDSR would incorrectly show the application with “**int”** as “**java.lang.Integer”** datatype, but the schema datatype on the Grid will be an XML Schema Datatype

## Need

**Need to use Primitive Datatypes in caBIG applications**
- Developers have very good reasons why they need to use Java primitives in their applications. For example, in the case of RBioconductor:
- They use primitives for intense computing (with higher performance) as they move data between R, Java and C code.
- Recommending not using these primitives has not been effective because of the greater need.
- They quickly point out that they would now have bloated code (as they translate between primitives and data objects) with less performance.
- They point out that - wasn't caBIG moving toward language agnosticism?

## Current Situation

**For XMI “int” and “java.lang.Integer”**
**The caCORE SDK XSD Utility generates XML Schema dataype “xs:Integer“ **
**The caCORE SDK Code Generator generates “java.lang.Integer”**
**The UML Loader  default behavior for attributes without an explicit Value Domain mapping: **
**Uses an external “mapping table” to determine which Value Domain to use for each Datatype in the model**
**e.g. map “int” to Value Domain named “java.lang.Integer”**
**Map “CHAR” to Value Domain named “java.lang.Sting”**
**etc**

## Partial Solution?

**Implement the caDSR whitepaper recommendations (using XML primitives) ****(https://gforge.nci.nih.gov/frs/?group_id=133)**
- The caDSR currently contains nearly fifty datatypes. These are needed to support non-grid applications who are describing the data in a specific implementation
- The Grid moves data as XML Schema Objects, the datatype of the original application is not relevant as Grid users are not directly querying a data repository, the grid services do that for you
- If you are writing your own service and XSDs, you can use whatever datatype you want to use
- Does a new feature need to be added to caCORE SDK to allow model owners to specify which datatype they want to use when generating the services:  “int” or “java.lang.int”?
- Or, is it acceptable to ask model owners to modify the generated service code manually?

## Partial table of the XML Schema Datatypes 

| caDSR | Datatype Description | XML Schema Datatype |
| --- | --- | --- |
| ALPHANUMERICA | A mix of numeric and alphabetic characters | string |
| BINARY OBJECT | A binary large object such as a document or image. | See section 7.3.5 of the whitepaper |
| BOOLEAN | The mathematical datatype associated with two-valued logic. | boolean |
| CHARACTER | A character string of letters, symbols, and/or numbers | string |
| DATE | A date specifying month, day, and year | See section 7.3.7 of the whitepaper |
| Date Alpha DVG | Oracle Clinical datatype-contains alphanumeric and Date data (Discreet Value Groups) | string and see section 7.3.7 of the whitepaper |
| DATE/TIME | A date (month,day,year) and time(hours,minutes,seconds). | See section 7.3.7 of the whitepaper |
| DATETIME | A date (month,day,year) and time(hours,minutes,seconds). | See section 7.3.7 of the whitepaper |
| java.lang.Boolean | A local java datatype - TreeNode. | boolean |
| java.lang.Byte | Java primitive - byte-length integer. | byte |
| java.lang.Character | Java primitive - single character. | string |
| java.lang.Double | Java primitive - double-precision floating point number. | double |
| java.lang.Float | Java primitive - single-precision floating point number. | float |
| java.lang.Integer | Java primitive – Integer. | int |
| java.lang.Integer[] | Java datatype - array of integers. | See section 7.3.1 of the whitepaper |

## How does the XML Datatype Work?

**Data Transfer across the grid:**
- Using XML documents. Users of grid services and other web services don't exchange data between the two actual programs. They use XML documents to translate the data to the specific programming language between the applications. To expound, working from the recommended caDSR Datatypes white paper (XML primitives were recommended):
- The programmer finds an Object he/she is interested in using (e.g. if the programmer is interested in using "int" in their UML model and code/API).
- In the Object of interest there is an element of XSD datatype "int".
- Developer writes program to unwrap the Object and picks an appropriate datatype that is mapped to XSD "int". One programmer could define the         attribute as "java.lang.Integer" for use in their program while a different programmer could define an attribute as an "int" in their program. To fulfill the                 language agnostic goal of caBIG, a Perl programmer would define their program with the Perl equivalent of XSD "int".** **

## Priorities for Implementation

**Priorities for Implementation**
- Create the new datatypes in the caDSR
- Start with the simpler datatypes
- Implement them in the SIW and UML loader with mappings from Java types (table is in the whitepaper). This requires a change to the mapping table that both the SIW and UML loader use.
- Migrate some existing projects (table is in the whitepaper)
- Implement more complex datatype issues (e.g. arrays)

## Next Steps 

**Discussions are underway**
**Request NCI Content Team to make the following modification to caDSR metadata:**
**Review the Datatype Mappings in the white paper outlining the XML Schema recommendations**
**Create the necessary XML Schema Datatypes in caDSR (Using Admin Tool  Datatype maintenance UI)  e.g. xs:Integer**
**Update the existing caDSR Datatype Descriptions that were used as defaults: java.lang.String, java.lang.Long, etc to clarify intended usage**
**Create new Non-enumerated caDSR Value Domain with the new XML Schema datatypes to use as Defaults for attributes not explicitly mapped to caDSR Value Domains**
**Provide a mapping between expected XMI datatype and XML Schema based caDSR Value Domains to the NCICB Help Desk**
**Update caBIG Guidelines/SOP so model owners understand the new policy**
**Determine whether a global change to the caDSR metadata is needed to reassign CDEs to the new XML Schema based Value Domains?**
**Versioned?**
**Or, change the existing Value Domains? **

## Questions?