String Representations of Datatypes

When data must be represented in the input or output of an activity, the data is represented as a string. This section explains the string representations of various datatypes. TIBCO BusinessEvents follows the XPath 1.0 standard for representing all numeric datatypes. TIBCO BusinessEvents follows the XML Schema canonical format for all other datatypes.

Numeric Datatypes

Numeric datatypes include all types derived from xs:integer, xs:decimal, xs:float, and xs:double.

All decimal, float, and double numbers are compressed to an integer when represented, if there are only zeros following the decimal point (for example, "1.000" is represented as 1). Scientific notation is never used to represent a floating point number as a string (for example, "xs:double(’1.234E05’)" is represented as 123400). Data is truncated if the number of digits exceeds the maximum precision for the datatype (for example, "xs:float(’1.23456789’)" is represented as 1.2345679).

Both zero and negative zero are represented as 0. Positive and negative infinity are represented as Infinity and -Infinity. Not a number is represented as NaN.

Boolean

The boolean datatype is used to indicate a true or false state.

xs:boolean(’true’) and xs:boolean(’1’) are represented by true. The XPath function true() is also represented as true.

xs:boolean(’false’) and xs:boolean(’0’) are represented by false. The XPath function false() is also represented as false.

Date Datatypes

TIBCO BusinessEvents Function Argument Wizard (also known as the function argument mapper) implements dates in one of two ways. Either a date is stored as the number of milliseconds since January 1, 1970, or the date is implemented according to the XPath 2.0 or XQuery 1.0 standards as a set of normalized components (xs:date, xs:time, xs:dateTime, and so on) with an optional time zone offset. Activities that are associated with Java (for example, Java Code, Java Method, and so on) use the first implementation. Activities that are associated with XML (for example, Mapper, Parse XML, and so on) use the second implementation. The second implementation supports arbitrary precision of the seconds component.

Conversion between these representations may result in a loss of information either because of the difference in time zone representation or the precision of the seconds.