Re: nameForms and dITContentRules

[Jim Sermersheim <JIMSE@novell.com>]

>In fact, if I read your definition correctly, it also contains Dit 
>Structure Rules as well as name forms and content rules.

Oops, I got my wires crossed.  I meant to say structure rules, not content rules.

>The reason for having these separate buys you flexibility. An object 
>class is defined once and once only, and given a unique OID. If the 
>object class definition is changed, then it should be given a new OID 
>(so that everyone is singing from the same song sheet). Your 
>extended construct requires the object class definer to define the 
>DIT structure and entry contents all at once, and if these 
>subsequently change (as surely they will, since directories are 
>dynamic and administrators do find new objects and structures that 
>they need to add from time to time) then your mega-object class 
>definition will need to be updated and given a new OID. 

From our experience, people occasionally want to change (add optional) attributes.  They rarely want to change the naming or structure rules.  In fact, we've only recently entertained adding new naming attributes and structure rules.

What does it buy us to make the object class static but allow modifications to content, naming, and structure rules?  The goal behind a static object class seems to be interoperability. To me, we're saying, you can count on the OID of an objectclass to represent that object class, but this isn't true, you have to also look at its content, naming, and structure rules.  If an entry of objectclass 1.2.3.4 is exported from DIT A, and imported to DIT B (which also supports objectclass 1.2.3.4), the export/import process must be aware of the three X.500 subschema attributes in order to ensure the entry will look/behave the same on both DITs.

>But I guess 
>you break this latter rule as well dont you, by changing the definition 
>and keeping the same OID.

We do break this rule by allowing people to add more optional attributes to an object class. To fix that, I suppose we would need to either make use of content rules, or just make people subclass or use aux classes.. Currently, we don't allow the naming attributes to be changed, nor do we allow the containment (structure rules) to be changed (only specified when the object class is created).  To allow those features, we'd have to support name forms and structure rules (or be 'bad' and just allow them to change our existing object class definition).

Jim