9.2. Model Versions and Compatibility
Perspectives parses an ARC text and transforms it into a DomeinFile (a JSON file format). On doing so, it checks the model. The purpose of this check is to prevent runtime errors and to ensure the intended meaning of the model.
As an example of the first category, consider a query that traces a path through the network of role and context instances. On each step, the query interpreter gathers resources from the database. If the modeller wrote a query with two consecutive context steps, the interpreter wrongly assumes it can read a property context from a context resource, which is a runtime error.
As an example of the second category, consider a query with a role-step in it for a role type that is not modelled. Runtime no error will rise, as the role instances getting function returns an empty sequence of instances. However, the program obviously cannot realise the intended meaning.
Of course model checking will never ensure intended meaning completely. In the end, that is the modellers' responsibility. More broadly, a model serves a purpose: to support a group of end users in their cooperation. It is the modellers craft to build a model that achieves that purpose.
In this text, I will reserve the word consistent to refer to a quality that a model is said to have, if and only if:
-
it does not cause runtime errors
-
it does not demonstrably violate the modellers' intended meaning.
This latter concept is, for now, operationally defined as the set of constraints that is checked.
This text needs to be extended with an analysis of changing perspectives. A sketch follows.
Newer model versions may have different perspectives, causing two problems:
-
deltas sent by peers with an older version may be refused because in the receiving peers version the role that authored it, is not authorised to do so;
-
changes are not communicated while peers expect them because they have a newer model where they have a perspective on the change, while the model version of the authoring peer doesn’t.