This chapter details the data types supported by TIBCO EBX®.
The table below lists all the simple types defined in XML Schema that are supported by EBX®, along with their corresponding Java types.
XML Schema type | Java class | Notes |
|---|---|---|
| The default strategies defined for string fields are detailed in the section Default strategy for string fields. | |
| ||
| A | |
| ||
| The date portion of the returned Date is always set to '1970/01/01'. | |
| The time portion of the returned Date is always the beginning of the day, that is, '00:00:00'. | |
| ||
| ||
|
| |
|
| This mapping does not comply with the XML Schema recommendation. Although the XML Schema specification states that xs:integer has no value space limitation, this value space is, in fact, restricted by the Java specifications of the java.lang.Integer object. |
The mapping between XML Schema types and Java types are detailed in the section Mapping of data types.
Named simple types can be defined when designing a data model for redefining an existing built-in simple type. A named simple type can be reused in the data model.
Restrictions:
In the data model, only the element restriction is allowed in a named simple type, and even then, only derivation by restriction is supported. Notably, the elements list and union are not supported.
Facet definition is not cumulative. That is, if an element and its named type both define the same kind of facet, then the facet defined in the type is overridden by the local facet definition. However, this restriction does not apply to programmatic facets defined by the element osd:constraint. For osd:constraint, if an element and its named type both define a programmatic facet with different Java classes, the definition of these facets will be cumulative. Contrary to the XML Schema Specification, EBX® is not strict regarding the definition of a facet of the same kind in an element and its named type. That is, the value of a same kind of facet defined in an element is not checked according to the one defined in the named type. However, in the case of static enumerations defined both in an element and its type, the local enumeration will be replaced by the intersection between these enumerations.
It is not possible to define different types of enumerations on both an element and its named type. For instance, you cannot specify a static enumeration in an element and a dynamic enumeration in its named type.
It is not possible to simultaneously define a pattern facet in both an element and its named type.
Complex types can be defined when designing a data model. A named complex type can be reused in the data model.
Restrictions:
In the data model, only the element sequence is allowed. Notably, attribute definition is not supported.
Type extensions are not supported in the current version of EBX®.
EBX® provides pre-defined simple data types:
XML Schema type | Java class |
|---|---|
|
|
|
|
|
|
|
|
|
|
| internal class |
|
|
|
|
|
|
The above types are defined by the internal schema common-1.0.xsd. They are defined as follows:
| This type represents textual information. Its default user interface in EBX® consists of a dedicated editor with several lines for input and display. The use of this data type is intended for very long texts; this is why the <xs:simpleType name="text"> <xs:restriction base="xs:string" /> </xs:simpleType> |
| This represents a character string with HTML formatting. A WYSIWYG editor is provided in EBX®. <xs:simpleType name="html"> <xs:restriction base="xs:string" /> </xs:simpleType> |
| This represents an email address as specified by the RFC822 standard. <xs:simpleType name="email"> <xs:restriction base="xs:string" /> </xs:simpleType> |
| This represents a hashed or encrypted password. A specific editor is provided in EBX®. <xs:element name="password" type="osd:password" /> The default editor performs a hash computation using the SHA-512 algorithm. This encryption function is also available from a Java client using the method It is also possible for the default editor to use a different encryption mechanism by specifying a class that implements the interface <xs:element name="password" type="osd:password"> <xs:annotation> <xs:appinfo> <osd:uiBean class="com.orchestranetworks.ui.UIPassword"> <encryptionClass>package.EncryptionClassName</encryptionClass> </osd:uiBean> </xs:appinfo> </xs:annotation> </xs:element> It is possible to specify some salt by referencing a path to another field, and by using a class the implements the interface <xs:element name="password" type="osd:password"> <xs:annotation> <xs:appinfo> <osd:uiBean class="com.orchestranetworks.ui.UIPassword"> <encryptionClass>package.HashClassName</encryptionClass> <saltPath>../login</saltPath> </osd:uiBean> </xs:appinfo> </xs:annotation> </xs:element> |
| This represents a geographical, political or cultural location. The locale type is translated into Java by the class <xs:simpleType name="locale"> <xs:restriction base="xs:string"> <xs:enumeration value="ar" osd:label="Arabic" /> <xs:enumeration value="ar_AE" osd:label="Arabic (United Arab Emirates)" /> <xs:enumeration value="ar_BH" osd:label="Arabic (Bahrain)" /> <xs:enumeration value="ar_DZ" osd:label="Arabic (Algeria)" /> <xs:enumeration value="ar_EG" osd:label="Arabic (Egypt)" /> <xs:enumeration value="ar_IQ" osd:label="Arabic (Iraq)" /> ... <xs:enumeration value="vi_VN" osd:label="Vietnamese (Vietnam)" /> <xs:enumeration value="zh" osd:label="Chinese" /> <xs:enumeration value="zh_CN" osd:label="Chinese (China)" /> <xs:enumeration value="zh_HK" osd:label="Chinese (Hong Kong)" /> <xs:enumeration value="zh_TW" osd:label="Chinese (Taiwan)" /> </xs:restriction> </xs:simpleType> |
| This represents a character string with hexadecimal RGB color formatting. A color picker <xs:simpleType name="color"> <xs:restriction base="xs:string" /> </xs:simpleType> |
| This represents a resource packaged in a module. For more information, see Packaged resources. This type requires the definition of the facet FacetOResource. <xs:simpleType name="resource"> <xs:restriction base="xs:anyURI" /> </xs:simpleType> |
| This type represents a reference to a dataspace. <xs:element name="dataspaceField" type="osd:dataspaceKey" /> A specific editor is provided in EBX® that displays the dataspaces that can be referenced. It is possible to specify the dataspaces that can be referenced using the element <xs:element name="dataspaceField" type="osd:dataspaceKey"> <xs:annotation> <xs:appinfo> <osd:dataspaceSet> <include> <pattern>a pattern</pattern> <type>all | branch | version</type> <includeDescendants>none | allDescendants | allBranchDescendants | allSnapshotDescendants | branchChildren | snapshotChildren</includeDescendants> </include> <exclude> <pattern>a pattern</pattern> <type>all | branch | version</type> <includeDescendants>none | allDescendants | allBranchDescendants | allSnapshotDescendants | branchChildren | snapshotChildren</includeDescendants> </include> <filter osd:class="com.foo.MyDataspaceFilter"> <param1>...</param1> <param2>...</param2> </filter> </osd:dataspaceSet> </xs:appinfo> </xs:annotation> </xs:element>
It is also possible to customize validation messages and the control policy associated with this type using the element |
| This type represents a reference to a dataset. <xs:element name="dataset" type="osd:datasetName" /> A specific editor provided in EBX® displays the datasets that can be referenced. It is also possible to specify the datasets that can be referenced using the element <xs:element name="datasetField" type="osd:datasetName"> <xs:annotation> <xs:appinfo> <osd:datasetSet> <branch>productsBranch</branch> <version>productsVersion</version> <dataspaceSelector>../dataspaceField</dataspaceSelector> <pattern>a pattern</pattern> <filter osd:class="com.foo.MyDatasetFilter"> <param1>...</param1> <param2>...</param2> </filter> </osd:datasetSet> </xs:appinfo> </xs:annotation> </xs:element>
One of the elements It is also possible to customize validation messages and the control policy associated with this type using the element |
EBX® provides pre-defined complex data types:
XML Schema type | Description |
|---|---|
| User Defined Attribute: This type allows any user, according to their access rights, to define a value associated with an attribute defined in a dictionary called a UDA Catalog. |
| Catalog of User Defined Attributes: This type consists of a table in which attributes can be specified. This catalog is used by all |
| A User Defined Attribute (UDA) supports both the <xs:element name="firstUDA" type="osd:UDA" minOccurs="0" maxOccurs="unbounded" osd:UDACatalogPath="//insuranceCatalog" /> <xs:element name="secondUDA" type="osd:UDA" minOccurs="1" maxOccurs="1" osd:UDACatalogPath="/root/userCatalog" /> <xs:element name="thirdUDA" type="osd:UDA" minOccurs="0" maxOccurs="1" osd:UDACatalogPath="//userCatalog" /> In the manager, when working with a UDA, the editor will adapt itself to the type of the selected attribute. |
| Internally, a catalog is represented as a table. The parameters Several catalogs can be defined in the same data model. <xs:element name="insuranceCatalog" type="osd:UDACatalog" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation xml:lang="en-US">Insurance Catalog.</xs:documentation> <xs:documentation xml:lang="fr-FR">Catalog assurance.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="userCatalog" type="osd:UDACatalog" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation xml:lang="en-US">User catalog.</xs:documentation> <xs:documentation xml:lang="fr-FR">Catalogue utilisateur.</xs:documentation> </xs:annotation> </xs:element> Only the following types are available for creating new attributes:
|
The following features are unsupported on UDA elements:
Facets
Functions using the osd:function property
UI bean editors using the osd:uiBean property
The osd:checkNullInput property
History features
Replication
Inheritance features, using the osd:inheritance property
As UDA catalogs are internally considered to be tables, the restrictions that apply to tables also exist for UDACatalog elements.
In XML Schema, the maximum number of times an element can occur is determined by the value of the maxOccurs attribute in its declaration. If this value is strictly greater than 1 or is unbounded, the data can have multiple occurrences. If no osd:table declaration is included, this element is called an aggregated list. In Java, it is then represented as an instance of the class java.util.List.
The following is an example of an aggregated list that defines the pricing of a loan product, depending on the amount borrowed.
<xs:element name="pricing" minOccurs="0" maxOccurs="unbounded" osd:access="RW"> <xs:annotation> <xs:documentation> <osd:label>Pricing</osd:label> <osd:description>Pricing grid </osd:description> </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="amount" type="xs:int"> <xs:annotation> <xs:documentation> <osd:label>Amount borrowed</osd:label> </xs:documentation> </xs:annotation> </xs:element> <xs:element name="monthly" type="xs:int"> <xs:annotation> <xs:documentation> <osd:label>Monthly payment </osd:label> </xs:documentation> </xs:annotation> </xs:element> <xs:element name="cost" type="xs:int"> <xs:annotation> <xs:documentation> <osd:label>Cost</osd:label> </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element>
Aggregated lists have a dedicated editor in EBX®. This editor allows you to add or to delete occurrences.
The addition of an osd:table declaration to an element with maxOccurs > 1 is a very important consideration that must be taken into account during the design process. An aggregated list is severely limited with respect to the many features that are supported by tables. Some features unsupported on aggregated lists that are supported on tables are:
Performance and memory optimization;
Lookups, filters and searches;
Sorting, view and display in hierarchies;
Identity constraints (primary keys and uniqueness constraints);
Detailed permissions for creation, modification, deletion and particular permissions at the record level;
Detailed comparison and merge.
Thus, aggregated lists should be used only for small volumes of simple data (one or two dozen occurrences), with no advanced requirements. For larger volumes of data or more advanced functionalities, it is strongly advised to use an osd:table declaration.
For more information on table declarations, see Tables and relationships.
Including another data model in your current model allows you to use the reusable types that are defined in that data model. You can thus use the inclusion of external data models to share data types between multiple XML Schema Documents.
To include another XML Schema Document in your model, thereby including the data types that it defines, specify the xs:include element as follows:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:osd="urn:ebx-schemas:common_1.0" xmlns:fmt="urn:ebx-schemas:format_1.0"> <xs:include schemaLocation="./schemaToInclude.xsd"/> ... </xs:schema>
The attribute schemaLocation is mandatory and must specify either an absolute or a relative path to the XML Schema Document to include.
The inclusion of XML Schema Documents is not namespace aware, thus all included data types must belong to the same namespace. As a consequence, including XML Schema Documents that define data types of the same name is not supported.
EBX® includes extensions with specific URNs for including embedded data models and data models packaged in modules.
To include an embedded data model in a model, specify the URN defined by EBX®. For example:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:osd="urn:ebx-schemas:common_1.0" xmlns:fmt="urn:ebx-schemas:format_1.0"> <xs:include schemaLocation="urn:ebx:publication:myPublication"/> ... </xs:schema>
To include a data model packaged in a module, specify the specific URN defined by EBX®. For example:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:osd="urn:ebx-schemas:common_1.0" xmlns:fmt="urn:ebx-schemas:format_1.0"> <xs:include schemaLocation="urn:ebx:module:aModuleName:/WEB-INF/ebx/schema/myDataModel.xsd"/> ... </xs:schema>
See SchemaLocation for more information about specific URNs supported by EBX®.
If the packaged data model uses Java resources, the class loader of the module containing the data model will be used at runtime for resolving these resources.