The data types you use when defining data mappings are organized in type clusters. Each cluster contains semantically similar XSD types. One or more of the XSD types in a cluster defines the XSD type of the whole cluster.
At runtime, data mappings that you have defined are checked for compatibility based on these type clusters. When you define data mappings between data types contained in different clusters, you need to know to which type cluster the target data type belongs, and the type of the whole cluster. The following table lists the type clusters and the XSD types contained in a cluster. The emphasized types define the type of each cluster:
Type Name |
XSD Types |
---|---|
finite-integer |
xsd:byte, xsd:int xsd:long , xsd:short xsd:unsignedByte, xsd:unsignedInt, xsd:unsignedShort |
infinite-integer |
xsd:integer , xsd:negativeInteger, xsd:nonNegativeInteger, xsd:nonPositiveInteger, xsd:positiveInteger, xsd:unsignedLong |
fuzzy-real |
xsd:double , xsd:float |
precise-real |
xsd:decimal |
text |
xsd:ID, xsd:IDREF, xsd:language, xsd:Name, xsd:NCName, xsd:NMTOKEN, xsd:normalizedString, xsd:NOTATION, xsd:string , xsd:token, xsd:gDay, xsd:gMonth, xsd:gMonthDay, xsd:gYear, xsd:gYearMonth, xsd:ENTITY, xsd:duration, xsd:anyURI (?), QName (?) |
boolean |
xsd:boolean |
binary |
xsd:base64Binary , xsd:hexBinary |
time |
xsd:date, xsd:dateTime , xsd:time |
You want to transform xsd:integer to xsd:int. The two types belong to different type clusters. The target xsd:int belongs to the finite-integer type cluster, where xsd:long defines the type of the cluster. You use the xsd:long to transform xsd:integer to xsd:int in the following way: long( yourIntegerRef ) .
We recommend that you check the data type compatibility according to the World Wide Web Consortium hierarchy too. It is possible even for data types contained in the same type cluster to cause problems during process execution if they are not compatible according to the hierarchy. The mapping editor does not show problems during process modeling, but depending on the concrete values, there might be problems at runtime.
For example, if you map xsd:long to xsd:int, the mapping editor does not show errors at design time. However, there might be a loss of precision in the result at runtime if the value of xsd:long is greater than the maximum value that xsd:int supports.
In other cases, an exception might be thrown at runtime if you try to assign an invalid value to a target node. For example, the expected value after the mapping is executed, is a date of type xsd:gYearMonth in "YYYY-MM" format. You provide at design time the value "2003-13" and the mapping editor does not show errors, because this is a valid string. However, you get an exception at runtime, because the month part is out of range.
For more information about the data type hierarchy, see http://www.w3.org.