Much of the bx literature, especially that couched in terms of consistency restoration, presupposes a workflow based on strict sequentialisation of model updates, and in some cases explicitly via a centralised broker of shared state. Put another way: the underlying mathematical semantics of bx take little account of the deployment context for such artefacts, which, from a user's perspective, are typically concurrent and distributed. This discussion proposal invites discussion of the bx deployment context.
This "short paper" is a proposal that the workshop have a space for discussing the following issue which we think needs more attention than it has had so far. We include some points for discussion, and a non-exhaustive list of relevant references; we hope that other points and references can be added during discussion, and perhaps a full paper may be produced in response.
Going back to Meertens [Mee98,Mee05], a bidirectional transformation or bx can be considered to be an artefact which embodies both a specification of consistency between two or more models, e.g. as a relation on a pair of model spaces, and a specification of how consistency should be restored. The latter is often -by Meertens, in the lens literature, in MDD settings including by the authors -presented via pure functions, the consistency restorers, which take one or more models as arguments, and return a result which is understood as a modified version of one of the arguments, intended to replace it. In other approaches, invoking a consistency restorer may directly edit the user's model, or may return an edit that could be applied to a model, rather than a full model.
We have in recent years developed approaches to such bx which make explicit the side-effecting -effectful -nature of the consistency restorers [ACG + 15, ASMG15]; in our approach, the user of the bx is presented with a monadic interface allowing get and set operations, instead of with pure functions such as − → R and ← − R . In particular, the monadic interface allows us to model explicitly the use of effects such as I/O or non-determinism in computing model revisions. Interestingly, our models seem, for mathematical tractability, to oblige us to consider each model as a derived view of a "central" -shared (even if hidden) -state space, similar to Johnson and Rosebrugh's recent work on spans of lenses [JR14].
All such approaches, however, change rather than solve the problem: when (if ever) does the user of the bx invoke these operations and what (if anything) do they have to do before they can continue with their real work? Suppose a bx engine implemented bx as presented in any of these ways; how should it be used? Perhaps this issue has not had as much attention as it should have done because of the connections with bidirectional programming, a rather different proposition from bidirectional transformation.
1. The connection between bx and related concepts including version control systems, synchronizers and collaborative working systems can be both helpful and deeply confusing.
2. It can be helpful because most of us have extensive experience working with the latter, whether it is when we maintain copies of parts of our filesystem in more than one place, or when we collaborate on papers.
3. It is confusing because it tempts us to think in terms of "conflict", a very unhelpful notion for bx (to be deliberately provocative). The very notion of "conflict" between your model and mine presupposes that our models are supposed to be identical (at least in the part where we can observe conflict). We mean by the term something like: things that should be identical are not identical, must be made identical, and it is not clear which of the current things should "win".
4. Implicit or explicit is the presence of some kind of archive: the basic picture of consistency restoration has been augmented with auxiliary machinery such as generalised diff3 [KKP07].
5. But neither the "to be consistent is to be identical" view, nor the presence of an archive, is essential to talking about concurrent editing of two models.
6. People sometimes assume that in evaluating, say, − → R (m, n), we may assume that n is a model that was consistent with some earlier version of model m. No: nothing in the formalism requires this.
7. [CGMS15] discussed the distinction between strong and weak versions of properties universally quantified over pairs of models, such as continuity. Essentially the strong form considers concurrent editing of the models, while the weak form does not. 9. In version control systems we are used to explicitly invoking operations, and we are familiar with the ways in which this can fail (e.g., minimise conflicts by always doing svn up (get) before you svn commit (set)), but we know that this will not always avoid conflict.
10. In cloud systems such as Dropbox, we do not explicitly invoke operations, but the systems' behaviour can be perplexing even when not broken [HPAN15].
11. If the bx is not history ignorant -and we know it is unlikely to be -then exactly when consistency is restored may materially affect the result. So perhaps we don't want it done invisibly in the background.
12. There is a tension between: I don't want to work for a long time on a model that is now inconsistent with your model, in case I am wasting effort; and, I don't want my flow broken by my tool telling me that something has changed in your model.
13. Is it acceptable for the bx engine to change part of my model that I'm not actually looking at right now, without telling me, in order to restore consistency?
14. What can be learned from categorisations such as [DGWC16, AC07]? Or from available (bx or roundtripping) tools?
15. There is a distinction between models having been concurrently edited, and the user requiring both models to be changed in order to restore consistency, studied in [XSHT09] for example. What are the implications, for practical scenarios, of our choices?