As I pointed out in a previous post, the inheritance in operational QVT is semantically confusing. So yesterday I finally posted an issue in OMG about how the “when” and “where” clauses should work. Next, the full issue:
In operational QVT, it is not clear what happens when the "when" or "where" clause of an inherited mapping does not hold.
Considering inheritance is a type (or, maybe, a synonym) of generalization, it would be expected that the semantics of inheritance mimics the semantics of generalization in MOF. The UML, which defines generalization used by CMOF and EMOF, states: "... features specified for instances of the general classifier are implicitly specified for instances of the specific classifier. Any constraint applying to instances of the general classifier also applies to instances of the specific classifier." (UML Infrastructure 2.4.1, p.51). If the "when" and "where" clauses are considered as features of a mapping, the clauses of the inherited mapping should be implicitly specified. Similarly, if they are considered as constraints applying to a mapping, the clauses defined in the inherited mapping should apply to the inheriting mapping. Therefore, a possible solution in both situations is to consider that the "when" and "where" clauses must hold in the inheriting mapping.
An interesting discussion is if something similar to the Liskov substitution principle should be applied in this situation.
Although I wished to post an issue about the whole inheritance semantics, I could not find a strong argument – based on MOF/UML concepts – defending my viewpoint. Moreover, I did a small research and found some papers discussing inheritance in transformational languages: Model Transformation in the Large, Surveying Rule Inheritance in Model-to-Model Transformation Languages, and Fact or Fiction – Reuse in Model-to-Model Transformations. I’ll read these papers and analyze the semantics proposed by other languages before posting an issue. Maybe I will come up with a paper. Anyhow, the semantics still bothers me…