Issue 11825: Inconsistent Rule.transformation multiplicity/composes for Mapping (qvt-rtf)
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity: 
Summary: Mapping is a Rule and Rule.transformation has unit multiplicity and is a container.
Therefore Rule.context can never be a container.


This could be fixed in a number of ways:


Fix 1: Change Rule.transformation to 0..1
        --> allow hierarchical Rule containment
        --> all Transformation rules are distinctly named
        -- no representation change
        -- minor semantic relaxation for QVTr/QVTo
        -- minor semantic surprise for QVTc - composed mapping has null Mapping.transformation.


Fix 2: Change Rule.context to not composes
        --> require flat Rule containment
        --> Transformation can have multiple unnamed rules
        -- no change for QVTc/QVTo
        -- representation change for QVTc


Fix 3: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.context[1]
        Redefine Rule.transformation[1] as a derived property
        Remove mapping.context (inherited from Rule)
        -- Doesn't work: context needs to be NamedElement to be either Rule or Transformation


Fix 4: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.owningTransformation[0..1]
        Redefine Rule.transformation[1] as a derived property
                Rule.transformation := owningTransformation
                Mapping.transformation := if context then context.transformation else owningTransformation endif
        -- no representation change
        -- minor semantic relaxation for QVTr/QVTo


Recommend 4.

Resolution: 
Revised Text: 
Actions taken:
December 17, 2007: received issue
Discussion: 

End of Annotations:=====

m: "Ed Willink" <ed@willink.me.uk>
To: <issues@omg.org>
Subject: MOF-QVT 1.0 Section 7 and 9: Inconsistent Rule.transformation multiplicity/composes for Mapping
Date: Mon, 17 Dec 2007 08:28:54 -0000
X-Mailer: Microsoft Outlook, Build 10.0.6822
Thread-Index: AchAhtxGQjHHa/SXQBWJQXiMRrBLkw==


Hi


Mapping is a Rule and Rule.transformation has unit multiplicity and is a container.
Therefore Rule.context can never be a container.


This could be fixed in a number of ways:


Fix 1: Change Rule.transformation to 0..1
        --> allow hierarchical Rule containment
        --> all Transformation rules are distinctly named
        -- no representation change
        -- minor semantic relaxation for QVTr/QVTo
        -- minor semantic surprise for QVTc - composed mapping has null Mapping.transformation.


Fix 2: Change Rule.context to not composes
        --> require flat Rule containment
        --> Transformation can have multiple unnamed rules
        -- no change for QVTc/QVTo
        -- representation change for QVTc


Fix 3: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.context[1]
        Redefine Rule.transformation[1] as a derived property
        Remove mapping.context (inherited from Rule)
        -- Doesn't work: context needs to be NamedElement to be either Rule or Transformation


Fix 4: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.owningTransformation[0..1]
        Redefine Rule.transformation[1] as a derived property
                Rule.transformation := owningTransformation
                Mapping.transformation := if context then context.transformation else owningTransformation endif
        -- no representation change
        -- minor semantic relaxation for QVTr/QVTo


Recommend 4.


    Regards


        Ed Willink