Perspectives Technical Documentation

A user role might have different perspectives in various states. Let’s revisit our first example:

What is the current state in the lexical position perspective on Wishes? Its narrowest enclosing state giving scope is the body of the user Guest definition, so it is the Root state of Guest. The implication is that this perspective on Wishes is always valid.

Why always? Would Guest not lose the perspective on the very first state transition? No, because whatever state Guest would transition to, it must be a substate of its Root state. This means that Guest then would be in both the substate and the Root state. In other words, perspectives for the Root state are always valid.

In contrast, in this model:

Guest would only acquire a perspective on Wishes in state Accepted. That is, the state Accepted of the role Guest.

We might call this subject state: the perspective depends on the state of the subject. It is also possible to define a perspective dependent on object state:

Now Guest can only see the Wishes when they are published. The perspective no longer depends on the state of Guest.

As of yet, we cannot make a perspective dependent on both object and subject state.

Obviously, we can also define a perspective to be valid in some context state. That means, in this case, that we can actually make the perspective depend on both object and subject state:

Subject role state Accepted now has a substate called WishesPublished. Its definition depends on the same property Finished of role Wishes as the Published state of Wishes itself (but we need a path via the context to reach it). So, whenever Wishes transitions to Published, a Guest user role instance in state Accepted will transition to its substate WishesPublished and thus be in both states at the same time. So we succeed in mimicking the effect of making the perspective depend on both object and subject state.

This works, however, only because Wishes is a functional role (roles are by default functional: only by adding the qualifier Relational (in parentheses) we can make it have more than one instance). Obviously, Guest is not a functional role and this means we cannot mirror this solution by reaching out from the role Wishes:

Look at the declaration of GuestAccepted: exactly what Guest are we talking about? The expression context >> Guest >> Accept will return as many Boolean values as there are Guests. As a matter of fact, the Perspectives compiler will reject this state definition because the expression is not functional (can result in more than one value).

Summing up: only as long as at least one of subject and object are functional, can we mimic the effect of making a perspective depend on both object and subject state.