Creating Composite Rules
The rules for an object type and its subtypes that are set at one context do not replace other rules that are set in the parent context. Instead, all rules are merged to create a composite rule. The merging involves combining rule definitions using the object type and context hierarchies that are in place, where the rule definition from the lowest level in the hierarchy takes precedence over definitions in parent types and contexts. Both the object type specified when the rule was created and the context in which the rule was created are taken into account.
You can view the composite rule that is in effect in a specific context by clicking the download composite icon 
from the Object Initialization Rules table displayed in the context.
from the Object Initialization Rules table displayed in the context.If a default value is not set for an object attribute in the composite rule that is in place and the user creating the object does not specify a value for the attribute, then one of the following occurs:
• If a default is specified, then it is used. For example, if the rule does not set the default life cycle state, then the life cycle service would use its property value to set a default state.
• If a default is not specified, then the attribute value is set to NULL. If the attribute value cannot be NULL because the attribute is a required attribute, then an error occurs.
Managing the creation of parts and CAD documents through the Windchill workgroup managers can affect the use of object initialization rules that are established for the name and number attributes of parts and CAD documents. For details on the managing options that are available through the workgroup managers, see Using OIRs for Naming and Numbering
If no constraints are applied or if empty constraints are applied to an object attribute in the composite rule that is in place, then there are no additional changes to the appearance of the value field when the user interface is displayed. For example, the field presented is empty and is editable.
The examples shown in this topic use rule content that defines default values. The merging of rules that include display constraints is done in the same manner as those that define default values. Both the type and context hierarchies that are in place are used to merge individual rules, creating the composite rule that is used.
Example 1: Rules Involving Context Hierarchy
When all of the rules are defined for the same object type, then merging rules only involves using the established context hierarchy. For example, assume the following:
• A rule for wt.doc.WTDocument numbering and versioning is set at the site context
• A rule for wt.doc.WTDocument folders is set at the product or organization context
Then the composite rule for wt.doc.WTDocument objects created under the product or organization includes both the setting for numbering and versioning, and the setting for folders. If the product rule for wt.doc.WTDocument object type had included setting the numbering scheme, then this rule setting would usually take precedence over the setting made at the site context.
Example 2: Rules Involving Type Hierarchy
When all of the rules that are defined are in the same context, then merging rules only involves using the established type hierarchy. For example, assume the following:
• A rule set at the site context includes content for setting default values for numbering and versioning documents of the type wt.doc.WTDocument
• A rule also set at the site context includes content for default folder values for documents associated with a subtype of wt.doc.WTDocument (such as com.ptc.General)
Then the merged rule for com.ptc.General in the site context would usually include the numbering and versioning definition from the parent type (wt.doc.WTDocument) and the folders definition from com.ptc.General. The composite rule for wt.doc.WTDocument objects at the site context would not include the folders definition because the folders definition is only in the rule defined for the subtype.
The inheritance from the parent to child in both types or contexts can be changed by including the optional final or ignore attributes in an AttrValue, AttrConstraint, or VarDef element for a specific object attribute. Using these attributes is described in Optional AttrValue, AttrConstraint, and VarDef Attributes.
Example 3: Combined Rules with Multiple Contexts
When the rules set for a specific object type include rules for both a parent type and a child subtype as well as rules in multiple contexts, then merging the rules involves both the type and context hierarchy. For example, assume the following:
• A rule for the default folder path and for numbering and versioning of documents associated with the wt.doc.WTDocument type is set at the site context. This rule autogenerates both the number and version of a document and sets the default folder path to /Default (which is the top-level folder in the context where the document is created).
• A rule for the default folder path for documents associated with the com.ptc.General subtype of wt.doc.WTDocument is set at the product context. This rule sets the default folder to /Default/General (which is the General folder in the context where a document using the com.ptc.General type is created).
Using these rules, assume a user creates a document using the wt.doc.WTDocument type in the product context. Then the following is true:
• The document has an autogenerated number and version.
• The default folder location is a top-level folder in the product context.
The composite rule in effect in this case includes content from both of the rules set in the site context and does not use content from the rule set in the product context for the default folder path (as the specified object type is the wt.doc.WTDocument parent type).
If a user creates a document using the com.ptc.General subtype in the product context, then the following is true:
• The document has an autogenerated number and version.
• The default folder location is the General folder in the product context.
In the composite rule that is in effect in this case, the rule content for the default folder path that is set in the product for the com.ptc.General subtype is used because it supersedes the rule content set in the site context for the wt.doc.WTDocument parent type.
Example 4: Combined Rules with Both Type and Context Hierarchy
If both object type and context hierarchy are involved, the object type hierarchy within the current context takes precedence over the context hierarchy. An object initialization rule for a subtype is ignored when the parent type rule exists in the current context. For example, assume the following:
• A rule for the default folder path and for numbering and versioning of documents associated with the wt.doc.WTDocument type is set at the site context. This rule autogenerates both the number and version of a document and sets the default folder path to /Default (which is the top-level folder in the context where the document is created).
• A rule for the default folder path for documents associated with the com.ptc.General subtype of wt.doc.WTDocument is also set at the site context. This rule sets the default folder to /Default/General (which is the General folder in the context where a document using the com.ptc.General type is created).
• A rule for the default folder path for documents associated with the wt.doc.WTDocument type is set at the product context. This rule sets the default folder to /Default/General/Design (which is the Design subfolder in the context where a document using the wt.doc.WTDocument type is created.)
If a user creates a document using the com.ptc.General subtype in the product context, then the following is true:
• The document has an autogenerated number and version.
• The default folder location is the Design subfolder in the product context.
In the composite rule that is in effect in this case, the rule content for the default folder path that is set in the product for the wt.doc.WTDocument is used because it supersedes the folder setting in the rule set in the site context for the wt.doc.WTDocument parent type as well as the folder setting in the rule set in the site context for the com.ptc.General subtype. Though the site-level rule set for the com.ptc.General subtype is of the same object type as the object created, it is ignored by the product-level rule using the object type hierarchy.