9.2.3. Compatibility issues with respect to data received from peers
In the above, we’ve focussed on data created by the end users' PDR. What about data created by the PDR of peers, who may have another version for a particular model?
Let’s first consider the situation where the peer uses a newer model version. Three kinds of potential problem may occur:
-
incoming Deltas may refer to types that are in the new model version, but not in the old model version;
This causes a runtime problem, because the authorisation process will reflect on that type. The problem arises during authorisation. We can catch these problems and choose to ignore the deltas that caused them.
-
incoming Deltas may contain property values whose shape is incompatible with the type in the old model.
This does not cause immediate problems upon handling the delta, but will cause runtime errors later on.
We can add a check to the transaction handling and reject any Property deltas whose data have the wrong shape.
-
a Context Delta arrives that puts a particular role instance in a context while the role type is unlinked in one of the models and linked in the other.
This turns out to cause no runtime problem. The PDR will either add or not add the instance to the context. The new instance will be found by query, or by following a link. Local logic is consistent!
Now let’s consider the reverse case: peer data refers to types from an older version of the model (than that the user himself has installed). All of the problems signalled above may arise. However, all we can say is that the peers' model is incompatible with that of the receiving user; we cannot say which is older.
9.2.3.1. Handling the problems
We can handle both problems, to the cost of ignoring the problematic deltas. This may cause further delta handling problems, but all can be handled to the extent that no runtime error arises.
Semantic problems persist, however. We would like to handle these situations based on knowledge about whose model is older:
-
if the receiving users' model is the oldest, one course of action may be to stop handling deltas and ask the end user if he wants to upgrade his local model.
-
otherwise, we might want to advise the sender to update his model. However, this would require an entirely new form of communication between peers. As an alternative, we might simply wait. As soon as the user modifies a resource governed by this model himself, and the peer has a perspective on the modified resource, its PDR will find that it uses an outdated model.
9.2.3.2. Some special cases
Moving a role type to another context type
A modeller might decide that a particular user role is in a context but would be better of in the context that embeds contexts of the first type. As a consequence, the perspectives of that role would have to change - the model checker will signal any omissions.
Runtime errors can be prevented automatically for such a change, but semantic problems will arise. In this special case, however, a precise modification of the data would mend the semantic problems: move the role instances from one context to another, too. This can be done automatically but the modeller should decide if this action is desired.
Moving a property type to another role type
This case may be more frequent than the previous. It will probably be quite common for a modeller to move properties around in the role graph. As with roles, the required adaptation of the data could, in principle, be done automatically. Again, the modeller should decide whether that should be done or not.
Specialising a role’s binding
There is no automatic solution to this problem. However, we might find all role instances whose binding has become illegal and present the end user with a means to re-bind them.
Change type names
We can change either the namespace (by embedding the type in another context or role) or the local name. These changes are quite important for models, but should be invisible in the end user data.