Much of the bx literature, especially that couched in terms of consistency restoration, presupposes a work ow 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.
Introduction
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 di erent proposition from bidirectional transformation. 2
Points for discussion 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 lesystem in more than one place, or when we collaborate on papers. 3. It is confusing because it tempts us to think in terms of \con ict", a very unhelpful notion for bx (to be deliberately provocative). The very notion of \con ict" between your model and mine presupposes that our models are supposed to be identical (at least in the part where we can observe con ict). 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 quanti ed over pairs of models, such as continuity. Essentially the strong form considers concurrent editing of the models, while the weak form does not. 8. In MDD, if I am working on a model which is connected via a bx to your model, what kind of control do I want over when consistency is restored, and what can I have in principle? What are the implications for a usable tool? 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 con icts by always doing svn up (get) before you svn commit (set)), but we know that this will not always avoid con ict. 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 a ect 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 e ort ; and, I don't want my ow 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? [AC07] [HPAN15] John Hughes, Benjamin C. Pierce, Thomas Arts, and Ulf Norell. Mysteries of dropbox, October 2015. Downloaded January 2016.
Sanjeev Khanna, Keshav Kunal, and Benjamin C. Pierce. A formal investigation of di 3. In Arvind and Prasad, editors, Foundations of Software Technology and Theoretical Computer Science (FSTTCS), December 2007.
Lambert Meertens. Designing constraint maintainers for user interaction. Unpublished manuscript, available from http://www.kestrel.edu/home/people/meertens/, June 1998.
Lambert Meertens. Designing constraint maintainers for user interaction. In Shin-Cheng Mu, editor, Third Workshop on Programmable Structured Documents, pages 1{3, PSD Laboratory, Tokyo University, 2005.