Schema modification rules help you avoid breaking existing tool adapter software (as in configuration 2 and in part of configuration 4). Schema evolution rules also allow newer versions of tool adapters to work with older versions of the SmartPlant schema (as in configuration 3 and the other part of configuration 4).
When you decide to modify—or extend—the schema, consider the impact any modifications could have.
-
If you make a conforming change (for example, you add a new, optional property definition), what will happen?
-
If you make a non-conforming change (for example, you add a mandatory interface definition), what will happen?
-
How will you resynchronize your extended schema with a new schema from Hexagon?
-
Do schema files and data files have to be forward-compatible and backward-compatible in order to be useful?
Changes that might break existing publish or retrieval logic are not allowed, because those changes would break configurations 2 and 4. However, you can create explicit rules for the adapter to follow to avoid these problems.
Tool adapters must be written to work with old versions of the SmartPlant schema. Additions made to the SmartPlant schema after initial release must not be hard-coded into a tool adapter unless the coding will allow the adapter to continue working with older schema versions that do not have the additions (for example, using If statements). Likewise, any changes made to the map file after initial release must be delivered as a differential set of instructions rather than as a new map file. The version of the SmartPlant schema then drives the loading of these differential instructions.