In a Notes names and address book, each document contains a
field as well as a field. The field supports the LDAP Server on Notes by providing a class name. The field is a standard Notes document field that indicates which form should be used to display the document. The item is not required, and if it is not present, the Notes client uses a default form.Identity Manager does not provide the ability to map a single DS attribute to multiple target application attributes. This means that the Schema Mapping policy can't be used to map the object class to Form and Type. To handle this, the Driver Configuration asks if the directory database is really a Notes directory. If it is, the class name on DSEntry (translated into the Notes namespace) is used as the value for Type.
The object-class attribute on the DSAttribute object can be used to update the Form item if specified in the Schema Mapping policy. This provides a way to set both of those attributes, as well as providing mappings to allow the Type and Form values to differ. If the Schema Mapping policy contains a mapping between an eDirectory attribute and Form, it might be necessary to translate the content of the eDirectory attribute. This can be done by using an Output Transform policy. Conversely, an Input Transform policy is used to translate content from the Notes namespace to the eDirectory namespace.
If the directory source is not a Notes directory, the driver writes no Type item and the Class Name attribute is written to the Form item. If a Form item appears in the filter, the driver and ndsrep ignore it.
If the driver is configured against the Notes directory, the translated values for classname are written to a Type item in the Notes database, and Form can be included in the Schema Mapping policy. If the driver is configured against a Notes database other than the directory, the translated values for classname are written to a Form item in the Notes database, and Form might not be included in the Schema Mapping policy.