Columns are defined in the rsb:info block, a shown below. The attr tags in the schema represent the columns of the table. These should match the attributes that make up the desired object class.

There are a few columns that every table should include, regardless of the object class:

Note: The title attribute of the rsb:info block must match the name of the .rsd file.

Each column requires at least name and xs:type attributes. Additionally, you will need to specify dataFormat to decide how data is returned from the table. For example:

The other:dataFormat attribute has three options:

delimitedData: Return multiple Active Directory attribute values as delimited strings, separated by the delimiter character defined in the Table Settings section of the .rsd file, detailed later.

This is the default format in which to retrieve data and the delimiter defaults to a semicolon.

splitDataByRow: Push multiple Active Directory attribute values for the same DN as separate rows. All other columns will be pushed consistently, and the index in Id will be incremented. Note: Pushing multiple columns like this will exponentially grow the result set, potentially causing performance issues.

splitDataByCol: Push multiple Active Directory attribute values for the same DN with an appended index on the column name. You need to define multiple columns and append an "_n" to the end; for example, ObjectClass_1, ObjectClass_2, and ObjectClass_3. In this example, if there are more than 3 values, the remaining values will not be visible in the table, unless more columns are added.

The code below can be used to split the different values of the ObjectClass attributes into their own rows and Description attributes into their own columns. Notice the column definition now includes multiple columns for the Description attribute. Also note the other:dataFormat attribute for the attr.

An example result will look like:

In addition to data format on inputs, encoding can also be specified. Currently, returning data with UTF8 encoding or BASE64 encoding is supported. In order to retrieve data with a specified encoding, the other:encoding field must be specified for the desired attribute to be encoded. If no encoding is specified, UTF8 is the default.

An example of specifying encoding for an attribute:

Optionally, there are two attributes that can be used to control how filtering is handled when using the driver with SupportEnhancedSQL. The other:ldaptype attribute can be used to set the LDAP syntax of a field. This is used to determine the comparison operators that are supported server-side on a per-field basis. For example, if a field is marked as the type 'DN' and a query filtering for a substring (i.e., CONTAINS), which is not supported server-side, the driver will instead process this part of the filter entirely client-side. The supported type names are found in section 4.3.2 of RFC 2252. If you are unsure of the type or just want to disable server-side filtering for a given column entirely, the other:filterable attribute is also available. Setting this to false for the field will prevent this from ever being sent to the server in a filter, overriding the other:ldaptype attribute entirely.