modelverse/techreport/conformance_bottom/5-relatedwork.tex

\section{Related Work}
%TODO elaborate
\label{sec:relatedwork}
Three main dimensions of related work exist.

First, our approach builds upon the support for multiple linguistic types.
While we have used our approach~\cite{MultiConformance}, another possible direction is through by a-posteriori typing~\cite{aposteriori}.
In a-posteriori typing, a model is constructed with a single \textit{constructive} type~\cite{constructiveType}, which cannot be changed.
When a model is used in a different context, however, multiple additional types can be added afterwards (\textit{a posteriori}) through the use of concepts~\cite{concepts}.
These additional types don't influence the original constructive type, but can make the model applicable for use in other algorithms.
Supporting our $\mathit{conformance}_\perp$ relation through the use of a-posteriori typing should be similar.
The constructive type could simply be part of $\mathit{LTM}_\perp$, with all ``real'' linguistic types specified as a posteriori types.
Our approach varies a bit though, since we don't make the constructive type a special kind of type: the $\mathit{conformance}_\perp$ is just another relation like any other.
The OCA~\cite{OCA} is rather similar to our approach, as it identified the distinction between two conformance relations.
But whereas the OCA shifts one of these relations to the implementation level, we merge the physical type model into the linguistic dimension.
We therefore still completely comply to the OCA: we have both a linguistic dimension (used for user modelling), and a physical dimension (used during tool building).
Parts of our physical dimension are, however, exposed to the linguistic dimension, such that all operations from the physical dimension also become available in the linguistic dimension.
With the OCA it is not necessary to support multiple linguistic types for a single model, which is a necessary requirement when shifting more parts to the linguistic dimension.

Second, strict metamodelling has been the subject of several debates, both in favor~\cite{StrictProfilesWhyAndHow,ConceptsForComparing}, and against~\cite{LevelAgnostic,XMF-Mosaic}.
People against strict metamodelling argue that strict metamodelling makes specific models impossible, as we have also shown in this paper.
Their solutions, however, often completely throw away all notions of strict metamodelling.
And while we agree that strict metamodelling can be overly restrictive, it certainly has its advantages in protecting ordinary users and simplifying algorithms.
So in contrast to tools like XMF-Mosaic~\cite{XMF-Mosaic}, who completely flatten the modelling hierarchy, we still enforce strict metamodelling, though users can switch to the ``unrestricted mode'' by taking on a different linguistic type model.
Since the unrestricted mode is at a much lower level of abstraction than the usual linguistic metamodels, users will now have more powerful tools at their disposal, and are able to circumvent strict metamodelling in a controlled way.

Third, many tools rely explicitly on the implementation level.
For example, MMINT~\cite{MMINT}, MetaDepth~\cite{MetaDepth}, DISTIL~\cite{DISTIL}, AToM$^3$~\cite{AToM3}, and AToMPM~\cite{AToMPM} all explicitly allow users to inject code, for example as parts of models, or to extend the capabilities of the tool.
This code is not explicitly modelled, and is simply injected in the actual application code that is being executed.
There is thus no checking as to what is happening and if the inserted application code is actually valid code, since it is only treated as mere text by the tool.
This code is subsequently only checked by the compiler or parser of the language that is being used, further delaying user feedback.
And since this code is dependent on both the application interface (API), and the implementation language, and the internal data structures, the code is not portable at all.
Furthermore, it does away with the notion of ``model everything explicitly'', as it introduces unmodeled aspects in the models and even in the tool.
The importance of the physical dimension was previously highlighted~\cite{TechnologicalSpaces,TechnologicalSpaces2}, where the physical storage was mentioned as a technological space.
Different ways of representing this data were presented, though each of these can, with our approach, be abstracted away as an implementation detail.

Similarly, megamodel management~\cite{MegamodelManagement} is often implemented purely at the implementation level instead of explicitly modelled.
And while there is some work on making generic model management possible~\cite{TypingModelManagement,GenericityForModelManagement}, these approaches often remain specific to the problem under study.