The NDS schema is extensible. Developers can define new object classes and attributes. In fact, the NetWare operating system and Novell utilities and applications extend the schema.You can perform the following operations on the NDS schema:
Create, read, and delete attribute type definitions
Create, read, and delete object class definitions
List containable classes
Modify class definitions
Read attribute syntax definitions
Read attribute syntax IDs
However, you cannot create or modify an attribute syntax. The attribute syntaxes are the most fundamental building blocks of NDS and cannot be altered.
To extend the NDS schema, you must have Admin equivalent rights to a server containing a Read/Write replica of the root partition. In addition, if you are extending the schema from a workstation client, you must initialize the Unicode tables.
Before creating a new object class, you must make the following decisions:
What should you call the new object class? To register the name with Novell, see Registering Attribute Types and Class Definitions. For naming rules, see Valid Class and Attribute Names.
Which class flags does the object class require? For a list, see Section 1.7, Object Class Flags.
Which class or classes will you assign as the super classes? For information, see Section 1.6, Super Classes.
Do you need to define containment for the class? For information, see Section 1.5, Containment Classes.
Do you need to define naming attributes for the class? For information, see Section 1.4, Naming Attributes.
Does the class require any mandatory attributes that cannot be inherited from its super classes?
Does the class require any optional attributes that cannot be inherited from its super classes?
Your code should create new attributes before the new class so that the attributes can be assigned when the class is created. Otherwise, you will have to modify the class after the attributes are created. Mandatory attributes cannot be added later; they must be added to the class when the class is created.
The schema can be extended with many of the interfaces in the NDK such as NDS Libraries for C, LDAP Service Provider for JNDI, NDS Service Provider for JNDI, Novell Controls for ActiveX, Beans for Novell Services, and Novell ConsoleOne.
When you define new attribute types or new object class definitions, you must register them with Developer Support to ensure uniqueness. To register, you should go to the Novell Developer Support Web site, fill out the form, and submit the information.
If you cannot use the form, call Developer Support at 1-800-REDWORD (1-800-733-9673). If you cannot use an 800 number, the international number is 1-44-801-861-5588.
When you register, you receive a unique prefix that you prepend to the names of your new attribute and class definitions. You also receive two ASN.1 (Abstract Syntax Notation One) identifiers: one for object classes and one for attribute definitions. These IDs can be expanded to include as many unique IDs as you need for object classes and attributes.
In NetWare 4.11 and below, object class and attributes can have, but are not required to have, an ASN.1 ID. In NetWare 5.x, ASN.1 IDs are required for applications to pass Novell certification. NDS 8 verifies that the ASN.1 is BER encoded. ASN.1 IDs serve as a common syntax for transferring information between two end systems.
The prefix, which can be from 3 to 8 characters long, serves two purposes. It guarantees that your attribute and class names are unique. We keep a database of registered prefixes to ensure that no two companies select the same prefix. Since no two class definitions can share the same name, the unique prefix ensures that the name is unique.
The prefix also identifies which attributes and classes belong to your application. In the past, we used a convention that separated the prefix from the descriptive name with a colon. Since LDAP does not support colons in schema definition names, we are now using a convention which lowercases the prefix and capitalizes the first letter of each word in the descriptive part of the name. Don't use spaces between words because LDAP naming rules do not support spaces.
For example, if you registered the ABC prefix with Novell and used it to create a Reading Group class definition, we would recommend the following name which conforms to both NDS and LDAP naming conventions:
When you register for a prefix and an OID, we assign you a number similar to the following:
2.16.840.1.113719.2.888.4.12.1
These numbers have the following meanings:
After the subarc number, you are free to assign and subdivide the OID as best fits your application. However, we recommend that you use the format described above for the next few subdivisions. If you want to conform to standards and supply meaningful OIDs, the type identifier is important and needs to be used according to established conventions.
We also recommend starting the attribute and class count with 1 (not 0) and leaving the version number for first release blank (don’t use zero). For the next release, use 1 for the first revision and increment the version number with each subsequent release. Add the version number to the classes that are modified and to the classes and attributes that are new for that version. The version number of previous classes and attributes which have not been modified should not be incremented to the new version.
For a new class name or attribute name to be valid NDS name, it must fit two criteria:
The name cannot exceed 32 characters. Spaces are allowed but are counted in the 32-character limit. Spaces are not recommended since they are not allowed in LDAP schema names.
The name must be unique in its level of hierarchy in the NDS tree. Names are case insensitive, although case can be used for easier visual discrimination.
For example, “Accounting” and “accounting” would be considered as duplicates and not allowed as two class names or two attribute names, although differences in capitalization would appear on the screen. However, NDS allows the same name to be used for a class name and an attribute name. Thus Accounting could be the name of a class, and accounting the name of an attribute.
NDS has defined a number of classes and attributes with the same name, for example User (Class) and User (Attribute), Queue (Class) and Queue (Attribute), and Resource (Class) and Resource (Attribute).
If you want your application to work with LDAP (Lightweight Directory Access Protocol) applications, your schema extensions should conform to the LDAP naming conventions, which are more restrictive than NDS schema naming conventions. LDAP schema names must conform to the following rules:
Use alpha-numeric characters. LDAP allows one hyphen in a name, the only non-alpha-numeric character allowed, and it cannot start the name. The hyphen can be used only once in the name. We recommend that names contain only alpha-numeric characters without a hyphen.
Start with an alpha character. Numeric characters cannot start a name.
Do not include spaces.
Create a unique name for the type (class or attribute). Names are not case sensitive.
Do not create a name with more than 32 characters. This is an NDS restriction. LDAP allows longer names, but NDS does not currently support names longer than 32 characters.
We recommend that you lowercase the prefix, and then capitalize the initial word of the attribute's or class's descriptive name. For example, if we assigned you the prefix of adb for an address book application, the following object class names are possible:
Below is a list of rules that regulate the construction of new object classes. If you need to define new classes, pay close attention to these rules.
Object class definitions cannot be recursive. An object cannot have itself as a super class.
Only classes with complete structure rules can be flagged effective and used to create objects. That is, the super classes, containment, and naming attributes must be complete.
An effective class can be constructed in three ways:
The class defines its own structure rules.
The class inherits structure rules from its super classes.
The class defines part of the structure rules (such as naming) and inherits the other part of the structure rules (such as containment) from a super class.
For a class that defines its own structure rules, any structure rules that might be inherited from its super classes are ignored.
If structure rules of an effective class are inherited, they must be nonambiguous (for more information, see Effective and Noneffective Classes).