Release per Februari 24, 2022: InPlace v0.13.0

InPlace Version v0.13.0 delivers the following milestones in the project Practical Tools to Build the Context Web as supported by NLnet:

• Computed Properties (Milestone T14).

This release is being done while working on another milestone, the Context Name System (Mileston T9). Working towards that goal has turned out to be an important way of uncovering deficiencies and other issues. By far most of the work done since the previous release was spent on these issues. We outline some of the most important.

Major changes

• Computed Properties. These properties must not be confused with Calculated Properties (properties defined as a query). Here we mean property values computed by some (Purescript) function external to the core system.

• New execution model. The Perspectives Language is partly declarative. It lets the modeller describe contexts, roles, properties, perspectives and more, on the type level. But it also contains assignment statements to update instances of those types, to track a changing world. The modeller can specify that such statements must be carried out automatically on behalf of some user when the state of a context or role changes. This raises questions about the order in which such statements are executed. Because state changes are pattern-invoked, the modeller has no full control of this order (similar to rule-based languages).

  A new (and better) execution model has been devised and implemented to make the impact of changes as understandable as is possible. Put simply, it boils down to postponing actually removing a resource to the very last moment. This makes it possible to understand all expressions in statements in terms of the situation as it exists prior to modification.

• Improved composition of roles and contexts. On the type level, roles and contexts can be used as building blocks for other roles and contexts. Specifically, the roles of one context can be used as is inside another context. For example, a generic Driver role could be added to both an AmbulanceRide and a TaxiRide.

  However, Perspectives also allows so-called calculated roles. These are expressed as a query: a path through the (type level) network of contexts and roles. These queries are used, among others, to trigger state transitions and to synchronize changes with peers. Up to version v0.13.0, roles were treated as units in such queries. However, it turns out that, in the light of using a role as an aspect (building block) we should consider the combination of a role and a context as a unit. Intuitively, 'Driver in a TaxiRide' is not the same as 'Driver in an AmbulanceRide'.

  Suppose we act automatically on a state change depending on who is the Driver in an AmbulanceRide. If we don't recognize the difference between a generic Driver and the ones in an AmbulanceRide, we're bound to act in situations where it is not appropriate.

  Version v0.14.0 fixes that problem. As roles and queries are very fundamental to the language, however, this required extensive refactoring.

  As a consequence, multiple facets of the language have been adapted. It is, for example, now possible to specify a context of origin in a filledBy step.

• Standard variables. New and better treatment of standard variables. The variables have new names; their scope has been systematically explored; they are added compile time when necessary and have been documented clearly.

• Recompiling models automatically When the shape of the compiled model files (so called DomeinFile's) changes, an installation can no longer access its locally saved models. This is because the PDR expects the new shape. In general, a Repository may be expected to update its published models, and this mechanism complements that for local copies of compiled model files. In the future, when we have version management for InPlace as a WebApp, this mechanism will be part of the update cycle. Currently the mechanism can be activated by a query fragment in the url: ?recompilebasicmodels=true.

• Calling Actions. A modeller can specify an Action for a particular user perspective. It is now possible to call such actions from the user interface of InPlace. We have context actions that can be called by a control from the top menu bar, and role actions that can be called by a control in the toolbar under a form or a table.

• Synchronization checking. Changes made by the user must be communicated to relevant peers. But in order to be able to send such a change to a peer, the user's installation must know she exists. That is, the user must have a perspective on that peer. This is not by default the case. Think of reviewing a scientific article. The author is in contact with an editor and the editor employs a reviewer. However, author and reviewer do not know each other (in those roles, at least). So comments by the reviewer will not automatically be sent to the author.

  Synchronization checking is a new module that is activated on compiling a model. It warns the modeller of situations like this. This is work in progress.

• A system of warnings. We now have a mechanism in place to show warnings to the programmers of the PDR (and, in some cases, to modellers as well). Warnings are not errors and do not break the execution machine.

• Regular expressions. We can now match a string to a regular expression in the Perspectives Query Language.

• Comparing (role) types. If we want to fill a role with another, the latter should comply with the restrictions put by the first. The filler needs not be the exact required type, however; it may be a specialisation of it. This underlines the need to be able to compare types; to say whether one type is a specialisation of another.

  We have two ways of comparing role types, depending on what we think a role is. It can be considered to be a set of properties; but it can also be seen as a tag put on an instance. In the first case we let the semantics of 'role' depend on its structure; in the second case we put it outside the model entirely. Up till version v0.13.0 we used the role-as-property-collection definition. However, since we recognize the fact that the meaning of a(n Aspect) role instance is partly given by the context it is part of, we have switched to the other semantics. We have defined a sound definition of a role type as an Abstract Data Type composed of Sums and Products of simple roles and were able to derive a simple algorithm for comparing them (by reasoning about the normal forms of such ADTs).

Minor changes

The list below is a curated extract of the commit history, from which repairs to functionality that was introduced as new in this release, were stripped.

• getMyType now works for unlinked roles.
• All functions necessary for model:CouchdbManagement (to access a Couchdb Installation).
• We now use https rather than http to connect to Couchdb.
• External module Utilities added.
• It is now possible to have a createRole or createContext expression in a variable binding in a letA statement. Prior to this we could have statements but had no way of 'catching' the created resources.
• Two new models: BodiesWithAccounts and CouchdbManagement now parse and compile completely.
• New and better treatment of standard variables.
• Fixed bug in adding two numbers or strings.
• Fixed a bug in query inversion, for the case that an enumerated property is read from an enumerated role, but that property is present on the binding graph instead of the role itself.
• Fixed inverted order of assignments in AutomaticAction and Action.
• New precedences for operators; added "binds" as operator (rather than as predicate; both work now).
• Improved grammer of 'in state'.
• Queries consisting of indexed roles or contexts cannot be inversed. This situation is now recognized by the compiler, preventing mistakes in runtime.
• Queries were inverted for expressions in statements. That has been corrected.
• Substates of states were ignored. Fixed.
• Fixed a conceptual error in storing inverted queries consisting just of RoleBindersF.
• Fixed SecurityDocuments (better representation and de- and encoding).
• Prefixed names in state transitions are now expanded into qualified names.
• Function interpreter only considered properties defined on the role, not those in Aspects.
• Added a mechanism to serialise contexts and roles when a user role gets an additional perspective due to state change.
• Solved parsing error: comments after a notification were not adequately handled.
• The definition of the view function for roleFromContextView has been extended to produce key pairs for each state of a role instance. This allows us to retrieve an unlinked role instance by Aspect type.
• We now parse multiple states in a context or role. We can also use "on entry" and "on exit" in a role or state directly. All context- and role type now have a root state defined with the same (string) name.
• We don't have to define explicit root states anymore. All affected models have been adapted.
• We can now toggle libraries on and off in the table of models kept in the Repository.
• We now sort the models in topological order and move inverted queries from a model to models it imports.
• Resetting the account is now more robust. If model:System cannot be referred, it still removes all databases and reinstalls them.
• The implementation of logicalAnd and logicalOr was flawed with respect to the intended negation by failure syntax. Has been corrected.
• The role- and context instances that are read from CRL are now added to the Transaction, so their states are evaluated on creation.
• An extra indentation check was required to prevent confusion of 'in' as a context clause for createContext and createRole, with 'in' of letA.
• On reloading a model, we do not re-evaluate the context- and role instances that come with the model.
• We can now use prefixed view names in a perspective.
• Parser now allows states without content.
• We now parse on entry and on exit directly in context.
• We now also accept in subject/object/context state in a role.
• A better mapping of Role Verbs to deltas in handleTransaction.
• Improved SimpleChat. An invitation no longer carries the ChatApp of the Inviter.
• Complete revamp of deleting contexts and roles. Implementation is now in accordance with the new execution model.
• We can now create a context 'bound' in a Database Query Role and remove it again.
• We now have CallDestructiveEffect, that will be called after all constructive actions have been performed (just like remove context/role etc).

Documentation

A collection of short documents describing Aspect Patterns has been added here: Aspect Patterns.

Other new documents have been added:

1. Aspect States. This text describes a future extension. It is about that a modeller might want to extend the state definition of an Aspect of one of her types.
2. Adding Aspect Perspectives. User roles have Perspectives. However, they can also be composed of Aspect (User) roles. What if the latter have Perspectives, too? This text explores the space of meanings we can give to such compositions and it describes the (partial) support we envision for the Perspectives Distributed Runtime.
3. Binder vs Filler terminology. Unfortunately, in the implementation of the PDR we use a different set of terms for connecting roles than in the language definition.
4. Aspects and role filling In this text we explore the consequences of the introduction of Aspect Roles for the role filling relation.
5. Unlinked Roles. The modeller has the opportunity to declare a role unlinked, causing the containing context not to have direct pointers to its instances.
6. Synchronisation edge cases. An exploration of difficult cases of synchronisation.
7. Execution model. Exposition about the way state changing statements are executed during state transitions.
8. Optimizing inverted query application In this text we describe an optimization of the functionality that applies inverted queries.
9. Aspects require refinement of inverted queries. The use of Aspects requires us to rething the notion of the web of context and role types.
10. Technical design standard variables. The modeller can use a number of standard variables in his expressions. The semantics of these variables is given in the text Understanding a Perspective Model Text. In this text I explain how these variables are implemented.

Updated documents:

• The practical guide to writing a module with core external functions
• The Operational Meaning of a Perspective.
• Creating and deleting contexts
• Assignment