Release per July 16, 2021: InPlace v0.11.0

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

• The selfonly modifier (Milestone T19).
• Creating Contexts in Rules (Milestone T18).
• Model Versioning (Milestone T1).

Major changes

• selfonly. Think of a dinner party. The host asks her guests to indicate a preference for meat, fish or a vegetarian option. Consequently, the Guest role needs a perspective on himself to set the corresponding property value. However, a perspective of the user role Guest on the user role Guest would allow each Guest to change the properties of all other Guests! Clearly not what we want to model. The modifier 'selfonly' restricts the perspective to oneself.
• Creating Contexts in Rules. Rules have no longer a place in the Perspectives Language since version v.0.10.0, but the new createContext and createContext_ assignment operators can be used in the automatic actions on entry or on exit of a state. This makes no difference to their semantics. These operators are constructed in such a way that the invariant that a context instance is always bound in another context, is preserved.
• Model Versioning. A modeller describes types and perspectives in a model. Such models evolve, leading to the need for an installation to be able to update a particular model in use to a more current version. Updating models turns out to be quite an involved process, however.

On model updating. A model is a source text written in the Perspectives Language. Such a source must be parsed and compiled into an internal format containing a machine-executable version of the various types described by the model. The result is an artefact that can be read by the PDR/InPlace. It will be read whenever an instance of one of its types is handled by the PDR. The PDR reads it from a local store of compiled model texts.

Parsing/compiling is a model-time activity (executed by the modeller). However, taking a model in use is not just a matter of copying the compiled model from some remote repository to the local store. A compiled model must be integrated into the existing set of models. This means that any type in another model that it references, gets annotated with a kind of back reference. This is crucial for the PDR to be able to sychronize with peers, as part of the query inversion technique (see: Query Inversion).

On updating a model, these annotations must be updated, too. Some may have disappeared in the new version; others may have been added or changed. This requires careful unthreading and rethreading of the models involved.

Second, a model comes with some basic instances. These must be replaced as well, preserving their relations with other instances outside the model.

The new functionality is simple and straightforward, albeit somewhat limited. Waiting in the wings is a new model of servers, repositories, models and their versions, and the various types of user roles involved such as repository managers, authors and end users. This model requires the context name system to function adequately, however, so it has to wait for that milestone.

Minor changes

• Views for Calculated Roles. A View is a list of Property types. Perspectives can be refined with Views and the user interface components use them to interact with the core. Calculated Role types could not have views, reasoning from the fact that they cannot have properties. Nevertheless, it is a convenience if the modeller can create a collection specifically on a Calculated Role.
• Bug with name qualificaton Mostly a local name used in the model can be traced automatically to a fully qualified name, but not always. In that case, the modeller has to prefix segments until the result is unambiguous, like: SomeContext$Arole. In a do for <UserRole> clause, however, such local names will be combined with the current context to disambiguate. This ran into trouble when more than one segment is used. Solved.
• Bug: prefix expansion omitted in state conditions. A state condition is an expression; one can use prefixed names in such expressions, such as sys:Me. In state conditions, the prefixes were not expanded, leading to errors.
• False compile time type comparison error warnings. When using a relation in an expression (usually to compute a boolean value), the types both operands must be compatible (often meaning: be equal). Also, both sides must be functional (have just one instance). However, for some property types errors were generated. These originated in compiler reasoning that one of the sides was not functional, where, in fact, with a little extra reasoning the cardinality could be established. Solved.
• Incorrect deduction of the type of the sequence >>= operator. The sequence operator is used to perform a calculation on a Monoid (such as summing numbers). Suppose we want to establish that the values of a particular boolean property for a collection of roles are all true, we would and all values like this: <role> >> <property> >>= and. The result type of these expressions was incorrectly computed.
• Forward reference error in state conditions 'Forward reference' is the phenomenon that a source text contains the name of a definition that only occurs later in the text. For roles, forward reference was not taken care of in state condition expressions. Fixed.
• Design flaw in screens. InPlace depends on the functional reactive pattern. This means that screens are data-driven. If role- or context instances change, the PDR sends those changes to the InPlace client. Being build using ReactJS, the screens (React components) re-render automatically to reflect the new data. While this works beautifully, it did not mesh well with the design of nested screens. When the user navigates from a context to a sub context, the latter's screen is nested inside the former's. However, when a data change is propagated from the PDR to the containing screen, it re-renders - effectively destroying any nested screens. This may not happen often (as it mainly depends on changes brought about by peers) but obviously could not be maintained. It has been fixed by another design of opening contexts from contexts, more in line with the way that a browser opens a page from another.
• Bug: no form update after rolebinding. On dropping a role on a form, property values of that role must appear for types that the form displays. This did not happen, due to a programming error that caused dependencies not to be tracked. Fixed.
• Binding of specialised types not detected. A model details the type of roles that can be bound to a role. When, in runtime, a user fills an instance, this change must be propagated to peers with the right perspective. While this worked well for instances of the specified type, it did not for instances of specialised types. Fixed.
• Focus of dropzones and cards. The browser's default style sheet contains some complicated logic to detect what screen elements should be shown as having focus. It turned out that this did not do for some types of navigation we've built into InPlace, so we have added explicit focus style rules to compensate.

Documentation

The following documents have been updated:

• Introduction to the perspectives language
• Perspectives on Bindings
• The practical guide to writing a module with core external functions