N1 Grid Service Provisioning System 5.0 XML Schema Reference Guide

Appendix A Component Change Compatibility

This appendix enumerates the kinds of changes that can be made to a component and indicates whether each change is install compatible or call compatible.

The following changes can be made to components:

Changes That Can Be Made To Components

<component> Element Changes

The following table shows the changes that can be made to the <component> element and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

Nonfinal to final 

No 

Yes 

Final to nonfinal 

Yes 

Yes 

Nonabstract to abstract 

No 

Yes 

Abstract to nonabstract 

Yes 

Yes 

More restrictive access 

No 

No 

Less restrictive access 

Yes 

Yes 

Change the value of the description, label, softwareVendor, or author attributes

No [The attribute values are stored in the installed variable settings record.]

Yes 

Change the value of the name or path attributes [This change effectively constitutes a change of the version tree and is only possible in situations where a system service is being updated. In this case, the new component must be an instance of the original component.]

No 

Yes 

Change from a simple component to a composite component 

No 

No 

Change from a composite component to a simple component 

No 

No 

platform Attribute Changes

The following table shows the changes that can be made to the platform attribute and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

More general platform 

Yes 

Yes 

More specific platform 

No 

Yes 

Unrelated platform 

No 

Yes 

A platform is more specific than another if the first platform is a descendant of the second. A platform is more general if the first platform is an ancestor of the second platform.

limitToHostSet Attribute Changes

The following table shows the changes that can be made to the limitToHostSet attribute and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

Any change to the limitToHostSet attribute

No 

Yes 

Unlike the platform attribute, limitToHostSet names a generic, user-specified host set over which there is no explicit control. A host set's membership can change at any time, so you cannot specify more-specific or less-specific host sets.

<extends> Element Changes

The following table shows the changes that can be made to the <extends> element and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

New base component instance of the original component 

No 

Yes 

Original base component instance of a new component 

No 

No 

New base component that is unrelated to the original component 

No 

No 

New base component is install compatible with the original component 

Yes 

Yes 

New base component is call compatible with the original component 

No 

Yes 

Changes to Variables

The following table shows the changes that can be made to a variable and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

Add a new variable 

Yes [A derived component might exist that already defines the variable with a more restrictive access mode. In such a case, a change would make the derived component invalid. A new nonabstract variable can be added to a component type if no derived component has already defined a variable that has the same name, and the default value of the variable can be recomputed for all installed instances of the component.]

Yes 

Remove or rename a nonprivate variable 

No 

No 

Remove or rename a private variable 

Yes 

Yes 

Change the default value of a final variable 

No 

Yes 

Change the default value of a nonfinal variable 

Yes [No reinstall is required because the installed value can be considered an override of the new default value.]

Yes 

Change the prompt attribute

Yes 

Yes 

Nonfinal to final 

No 

Yes 

Final to nonfinal 

Yes 

Yes 

Nonabstract to abstract 

No 

Yes 

Abstract to nonabstract 

Yes 

Yes 

More restrictive access 

No 

No 

Less restrictive access 

Yes

Yes 

<targetRef> Element Changes

The following table shows the changes that can be made to the <targetRef> element and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

Remove <targetRef> element

No 

No 

Add <targetRef> element

No 

Yes 

Modify the hostName attribute

Yes [The attributes of hosts that are associated with existing installed components are not updated as a result of such a change.]

Yes 

Modify the typeName attribute

No 

No 

Add or remove an <agent> child element

No 

No 

Modify the connection attribute of the <agent> child element

Yes

Yes 

Modify the ipAddr attribute of the <agent> child element

Yes

Yes 

Modify the port attribute of the <agent> child element

Yes

Yes 

Modify the params attribute of the <agent> child element

Yes

Yes 

<componentRefList> Element Changes

The following table shows the changes that can be made to the <componentRefList> element and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

Nonfinal to final 

No 

Yes 

Final to nonfinal 

Yes 

Yes 

New type instance of the original  

No 

Yes 

Original type instance of the new  

No 

No 

New type that is unrelated to the original  

No 

No 

New type is install compatible with the original  

Yes 

Yes 

New type is call compatible with the original  

No 

Yes 

<componentRef> Element Changes

The following table shows the changes that can be made to the <componentRef> element and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

Nonfinal to final 

Yes [A derived component might exist that already defines the component reference with a more restrictive access mode or otherwise incompatible difference. In such a case, a change would make the derived component invalid. A new nonabstract component reference can be added to a component type if no derived component has already defined a component reference that has the same name.]

Yes 

Final to nonfinal 

Yes 

Yes 

Nonabstract to abstract 

No 

Yes 

Abstract to nonabstract 

Yes 

Yes 

Change the installMode attribute

No 

No 

Add a new component reference 

Yes, [Adding a nested component is technically possible. An existing installation would be treated as if it had been installed without the nested component. Because any functionality that might depend on the installation could break, this change should only be made if the component can function safely without the nested component. Otherwise, it should be treated as being a change that is not install compatible.]

Yes 

Remove or rename a nested <componentRef>

No 

No 

Remove or rename a top-level <componentRef>

No 

No 

Add, modify, or remove arguments from a nested component's <argList>

No 

Yes 

Add, modify, or remove arguments from a top-level component's <argList>

Yes [You cannot determine whether this component was the component that actually installed the top-level component. Therefore, this component cannot rely on the top-level component having variables that correspond to the <argList> values.]

Yes 

New type instance of the original  

No 

Yes 

Original type instance of the new  

No 

No 

New type that is unrelated to the original  

No 

No 

New type that is install compatible with the original  

Yes 

Yes 

New type that is call compatible with the original  

No 

Yes 

New nested component instance of the original  

No 

Yes 

Original nested component instance of the new  

No 

No 

New nested component that is unrelated to the original  

No 

No 

New nested component that is install compatible with the original  

Yes 

Yes 

New nested component that is call compatible with the original  

No 

Yes 

Changes to Resources

The following table shows the changes that can be made to a resource and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

Nonfinal to final 

No 

Yes 

Final to nonfinal 

Yes 

Yes 

Nonabstract to abstract 

No 

Yes 

Abstract to nonabstract 

Yes 

Yes 

Modify the installPath, name, group, or user attributes

No 

Yes 

Modify the rsrcName or rsrcVersion attributes

No 

Yes 

<install>, <control>, and <uninstall> Block Changes

The following table shows the changes that can be made to an <install>, <control>, or <uninstall> block and indicates whether each change is install compatible or call compatible.

Type of Change 

Install Compatible 

Call Compatible 

Nonfinal to final 

Yes [A derived component might exist that already defines the block with a more restrictive access mode or otherwise incompatible difference. In such a case, a change would make the derived component invalid. A new nonabstract block can be added to a component type if no derived component has already defined a block that has the same name.]

Yes 

Final to nonfinal 

Yes 

Yes 

Nonabstract to abstract 

No 

Yes 

Abstract to nonabstract 

Yes 

Yes 

More restrictive access 

No 

No 

Less restrictive access 

Yes

Yes 

Add a new nonprivate block 

Yes

Yes 

Add a new private block 

Yes 

Yes 

Remove or rename a nonprivate block 

No 

No 

Remove or rename a private block 

Yes 

Yes 

Change the body of a block 

Yes [The plan run history of prior runs of this block are not updated. Therefore, they might not directly coincide with the new block contents.]

Yes 

Add, modify, or remove local block variables 

Yes

Yes 

Add, modify, or remove private block parameters 

Yes 

Yes 

Add a required parameter to a nonprivate block 

No 

No 

Add an optional parameter 

Yes 

Yes 

Remove an optional or a required parameter 

Yes [Extra arguments that are passed from the caller are ignored, making this change possible.]

Yes

Rename an optional parameter 

Yes [This change is equivalent to removing and adding an optional parameter. However, the callers might see unexpected results as the originally passed parameter value is now ignored and replaced with the default value.]

Yes

Rename a required parameter from a nonprivate block 

No 

No 

Change a parameter from being optional to being required in a nonprivate block 

No 

No 

Change a parameter from being required to being optional 

Yes 

Yes 

Change the displayMode attribute of a parameter

Yes

Yes 

Change the prompt attribute of a parameter

Yes 

Yes 

Changes to <snapshot> Blocks

The following table shows the changes that can be made to the <prepare>, <cleanup>, or <capture> child elements of the <snapshot> element and indicates whether each change is call compatible or install compatible. <snapshot> blocks generally have the same compatibility matrix as the other blocks, except when dealing with their <prepare>, <capture>, and <cleanup> blocks.

Type of Change 

Install Compatible 

Call Compatible 

Add, modify, or remove a <prepare> or <cleanup> block

Yes 

Yes 

Add, modify, or remove a <capture> step

Yes [The contents of the snapshot <capture> block are evaluated only one time. The evaluation takes place when the snapshot is taken during initial installation. At comparison time, the stored capture contents are used to drive the comparison, ignoring any changes that might have occurred to the <capture> block. Thus, the existing snapshot is not affected by such a change. If the intent of the change was to affect the contents of the existing snapshot, this change must be modeled as a change that is not install compatible.]

Yes 

Changes to <ignore> Child of <diff> Element

The following table shows the changes that can be made to the <ignore> child element of the <diff> element and indicates whether each change is call compatible or install compatible.

Type of Change 

Install Compatible 

Call Compatible 

Add, modify, or remove an <ignore> element

Yes 

Yes 

The <ignore> element is only considered when you run the comparison and does not affect the state of existing snapshots.