Issue 10941: 9.18 The middle direction packages (qvt-rtf)
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity: 
Summary: A Direction defines the packages used by each direction domain.


Nothing defines the (additional) packages used by the middle area. For instance
there is no place to specify the trace class model generated by the RelationToCore
transformation. With many transformations and mappings in a QVTcore it does not
seem appropriate to overload TransformationName or MappingName as a hook to
reference the appropriate middle meta-models; different Mappings may have distinct
middle meta-models; multiple transformations may share the same middle meta-model.
(Core should be a first class programming language, not just one that supports
the eccentricities of a RelationToCore conversion.)


Suggest: a DirectionName between "where" and "(" in Mapping.


This reads very naturally:


map ...
        check left (...
        enforce right (...
        where middle (...


But we also need to fix the Abstract Syntax. As a minimum a Mapping needs a
middle-typed-model property to capture the missing information. With this addition
a Mapping duplicates so much of a CoreDomain/Area, that it is more appropriate
to eliminate Area altogether, merging it into CoreDomain. Area is eliminated
from Mapping, and added as an additional CoreDomain referenced by the middleDomain
property.


So:


CoreDomain extends Domain
        CoreDomain.variables : RealizedVariable [0..*] composed
        CoreDomain.bottomPattern : BottomPattern [1] composed
        CoreDomain.guardPattern : GuardPattern [1] composed


Mapping extends Rule
        Rule.domain : Domain [0..*] composed (must be at least CoreDomain[3])
        Mapping.specification - no change
        Mapping.local - no change
        Mapping.context - no change
        Mapping.middle : CoreDomain [1] (must be in Rule.domain)

Resolution: The suggested changes may be convenient but they are not necessary:
- the middle model can be anonymous
- the middle area can be merged with the overall mapping.
What is needed is a way to bind a middle metamodel to its TypedModel. This can be achieved by an
anonymus direction bindng
Revised Text: In 7.11.1.2 TypedModel change
A typed model specifies a named, typed parameter of a transformation.
to
A typed model specifies a typed parameter of a transformation. Explicit external parameters have a non-null
name. An implicit parameter such as the QVTc middle model may have a null name,
In 9.18 Concrete Syntax change
Direction ::=
DirectionName [“imports” PackageName(“,” PackageName)*]
[“uses” DirectionName(“,” DirectionName)*]
to
Direction ::=
[DirectionName] [“imports” PackageName(“,” PackageName)*]
[“uses” DirectionName(“,” DirectionName)*]
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue
Discussion: 

End of Annotations:=====
s is issue # 10941	From: "Ed Willink" <ed@willink.me.uk>

9.18 The middle direction packages

A Direction defines the packages used by each direction domain.


Nothing defines the (additional) packages used by the middle area. For instance
there is no place to specify the trace class model generated by the RelationToCore
transformation. With many transformations and mappings in a QVTcore it does not
seem appropriate to overload TransformationName or MappingName as a hook to
reference the appropriate middle meta-models; different Mappings may have distinct
middle meta-models; multiple transformations may share the same middle meta-model.
(Core should be a first class programming language, not just one that supports
the eccentricities of a RelationToCore conversion.)


Suggest: a DirectionName between "where" and "(" in Mapping.


This reads very naturally:


map ...
        check left (...
        enforce right (...
        where middle (...


But we also need to fix the Abstract Syntax. As a minimum a Mapping needs a
middle-typed-model property to capture the missing information. With this addition
a Mapping duplicates so much of a CoreDomain/Area, that it is more appropriate
to eliminate Area altogether, merging it into CoreDomain. Area is eliminated
from Mapping, and added as an additional CoreDomain referenced by the middleDomain
property.


So:


CoreDomain extends Domain
        CoreDomain.variables : RealizedVariable [0..*] composed
        CoreDomain.bottomPattern : BottomPattern [1] composed
        CoreDomain.guardPattern : GuardPattern [1] composed


Mapping extends Rule
        Rule.domain : Domain [0..*] composed (must be at least CoreDomain[3])
        Mapping.specification - no change
        Mapping.local - no change
        Mapping.context - no change
        Mapping.middle : CoreDomain [1] (must be in Rule.domain)