Issues for MOF QVT 1.2 Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 10646: Missing explanations in BNF
Issue 10947: 7.13.1 Multiple transformation extension
Issue 10948: 7.13.1 Qualified query name
Issue 11341: QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles
Issue 12173: Section: 8.2.1.6
Issue 12198: Section: 8.2.1.7
Issue 12362: Section: 8.4.7
Issue 12373: Section: 8.2.2.22
Issue 12374: MOF QVT 1.0, 8.2.2.22, Unclear specification of Unpack notation shorthand
Issue 12375: Section: 8.1.14
Issue 13331: QVTo Standard Lybrary and typedefs Issue. Extending OCL predefined types

Issue 10646: Missing explanations in BNF (qvt-rtf)

The OCL 2.0 spec has a 32 page section on concrete semantics.
QVTr has 1.5 pages of BNF but no explanation.

In particular:
What are the semantics of 'import' which has no abstract counterpart?
Where is the explanation of the role of [ '{' <oclExpressionCS> '}' ] in a <domain>?
Where is the instruction on how to treat the "_" identifier?

Resolution: Deferred

Comment: 
Specifying more formally the mapping between the concrete syntax and the metamodel - as it was achieved for the OCL language - could be interesting. However it is a very time expensive task. Also, may be difficult to maintain. We prefer defer such decision to a future RTF.

The concrete syntax for transformation supports multiple extension.
The abstract syntax supports only single extension.


Suggest: change the concrete syntax.

The concrete syntax for a query uses a pathNameCS, yet the query is defined
within the scope of a transformation.


How should a scoped name be interpreted?


? is a scoped name only applicable for declaring externally definedc queries ?

Issue : QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles


UML models drawn with Rose allow an opposite role to be defined for a
uni-directional role. This practice is common but haphazard in UML Infrastructure,
EMOF, OCL and QVT specification diagrams.


However EMOF provides only the (run-time) usage of the model and so any
EMOF (or Ecore) model generator must strip non-navigable opposite roles.


QVT matches models at compile-time and matching has no inherent need to
observe navigation constraints. This is amply demonstrated by the Rel2Core
transformation that makes extensive use of, for instance, the inverse Key to Class
relationship.


----------------------------------


Problem: some QVT transformations require names for non-navigable opposite roles,
but those names cannot be present in layered multi-package EMOF meta-models.


The Rel2Core transformation of Section 10.3 cannot be implemented with QVT 1.0.


----------------------------------


Abandoning EMOF (or Ecore) compliance in favour of perhaps CMOF seems unacceptable.


Changing EMOF (or Ecore) to incorporate opposite roles is not possible because
an EMOF specification cannot be extended to include the opposite role of every
meta-model that will ever exist.


Even if it was, there would be a substantial delay until meta-modelling tools
adopted the change and a problem with poor standardisation and global
non-interference of opposite rolenames.


QVT must therefore support definition of non-navigable role names as part of a
transformation. ModelMorf provided a very practical concrete syntax solution,
whereby the reserved operation opposite(qualified-role-name) could be used as
the missing opposite role-name wherever a forward role-name could be used.


An upward compatible abstract syntax requires an additional is-opposite qualifier
for each referred property.


So for


QVTCore::PropertyAssignment add isOpposite:Boolean[0..1] default false.


QVTTemplate::PropertyTemplateItem add isOpposite:Boolean[0..1] default false.


QVTRelation::Key add oppositeParts:Property[0..*] { composed } 
and possibly relax the lower bound for
QVTRelation::Key add parts:Property[0..*] { composed }
with the constraint that parts.size() + oppositeParts.size() > 0 


Perhaps QVTOperational::Module needs an additional oppositeConfigProperty and
QVTOperational::ContextualProperty needs an additional isOpposite too.

Agree with the suggested extensions to the key and property template parts of the relations language. As for a more general support in other expressions, we should perhaps wait until the next OCL revision. 

Sometimes it may be necessary to use a non-navigable opposite role in the specification of a key. For instance, an attribute is identified by a combination of its name and the owning class. Suppose we have a meta model in which the 'Class' to 'Attribute' association 'attribute' is only navigable from Class to Attribute. We should still be able to use this association in the key specification of Attribute.
E.g.
	key Attribute {name, opposite(Class.attribute)};
This specifies that an attribute is uniquely identified by its name and the class it belongs to.

Similarly, it is useful to be able to specify object templates in terms of opposite properties.
E.g.
domain myModel a:Attribute {name = n, opposite(Class.attribute) = c:Class{}};
This specifies that the pattern will only match if the class the attribute belongs to is equal to 'c'. This is equivalent to the following template definition with condition:
domain myModel a:Attribute {name = n} {c.attribute.includes(a)};
But the 'opposite' notation allows this to be specified in the template itself, leading to more compact specifications.

The extraCondition association needs revision: 1. The name does match with the diagram. 2. The cardinality is incorrect. Suggestion: Change the text with the following line: additionalCondition: OclExpression [*] {composes, ordered} 

That's true. The class description is obsolete in respect with the role naming found in Figure 8.1.

A clarification is needed in the text because it says "A variable parameter is an abstract concept..." and it can lead to confussion. A variable parameter can not be abstract because we could not create VarParameters for Helpers or Constructors (We could just create ModelParameters or MappingParameters). Suggestion: Remove the word "abstract". 

The grammar rule used to produce a forExp doesn't coincide with the notation specified in the abstract syntax section for it (Pag 89, Section 8.2.2.6). The rule production in the grammar is wrong. Suggestion: Change the production rule: <for_exp> ::= ('forEach' | 'forOne') '(' <iter_declarator_list> ('|' <expression> )? ')' <expression_block> 

The intent of syntax rule: 
<for_exp> ::= ('forEach' | 'forOne') '(' <iter_declarator_list> (';' <declarator>)? ('|' <expression>)? ')' <expression_block> 
was to allow shorthand with the computeExp 
compute (x:X) mylist->forEach(i|cond) { … } 
<==> mylist->forEach(i;x|cond) { … } 
Similarly with what happens with While expression. 
However the explanation was missing in the notation sub-section. 

UnpackExp should not compose targetVariable There are a lot of issues in this section: 1. name of Variable association was not updated to targetVariable. 2. {ordered} is missed. 3. variable should not compose. They should refer for instance a previously defined VarInitExp::referredVariable. 4. Parenthesis are missed in the first example (notation section). 5. Remember to update the diagram in figure 8.6 (pag 86). Note: These proposed changes are needed if you want to allow unpacking OrderedTuples using previously defined variables (which makes sense). Another (worst) alternative is forcing to declare new variables . In this case, the notation section should be changed. 

Section 8.2.2.22 provides no guidance on the meaning of:


var x:X;
var y:Y;
var z:Z;
...
var (x:X,y,z) := self.foo();


[If one of the variables in the left hand side, does exist ...]


Possible interpretations


a) x:X is always a syntactical shorthand.


Therefore the above is a shorthand for:


var x:X;
var y:Y;
var z:Z;
...
var x:X; var (x,y,z) := self.foo();


and consequently there is duplicate variable definition to be
reported as a semantic error.


b) x:X is a convenience type check assertion


Therefore the above is a shorthand for:


var x:X;
var y:Y;
var z:Z;
...
var (x,y,z) := self.foo();


with a successful validation of type consistency.


c) x:X is not available as a shorthand


Therefore the above is a syntax error.


------------------------------------


Interpretations b) and c) require semantic knowledge to resolve syntactic
sugar.


Interpretation a) is an unambiguous syntax shorthand that could be more
clearly
described by:


"The following example demonstrates a shorthand in which variables are both
declared
and assigned.


        var (x:X,y:Y,z) := self.foo();


Any variable name qualified by a type name is both a declaration and an
assignment,
with all declarations proceding the unapack assignment. 
The above example should therefore be analyzed as:


        var x:X; var y:Y; var (x,y,z) := self.foo();"


---------------------------------------------------------------------


Recommend interpretation a) with the above textual clarification.

QVT Operational Mappings claims in the overview section, the use of ListLiteralExpression (for instance to initialize a list), as in the section 8.1.14 (Pag 55) is shown. However, there is no way to represent this literal expression in the abstract syntax, due to: 1. There is no ListLiteralExp in the imperativeOCL package. 2. CollectionLiteralExp (from EssentialOCL) can't be used. There is a way to initialize lists, making use of the asList operator which appears in the Standard Library section (8.3.85 / Pag 112), however this should be clarified. Therefore, two possible solutions could be taken: Suggestion 1: Create a ListLiteralExp which should extend CollectionLiteralExp (From EssentialOCL). Suggestion 2: Update the overview examples, to properly ilustrate how to initialize lists. Besides, the grammar ( Pag 124) )should be consequently changed as well. (List { 1, 2, 3, } literal expressions wouldn't be supported). 

As interpretation from the especification (pag 104), the way of adding new operations to OCL predefined types is creating new Typedef instances
which must have the OCL predefined type as the base type. The new operations are added to this new typedef. However there are several problems:
1. The specification doesn't provide any name for these typedefs.
2. The specification doesn't specify which type (QVT typedef or OCL predefined type) should be used when referencing such OCL predefined types in a QVTo transformation.


Solution for 1).
Suggestion a: Name the typedef with the same name of the base type. This provokes name's clash with the predefined type's name, due to there are two different types from two standard libraries
which have the same name. A possible solution, would be expliciting that typedefs (aliases) will never clash its name with its base type.

Suggestion b: Name the tpyedef with a different name, such as QVToXXXXXX or XXXX_Alias.

Solution for 2).
Suggestion a: Taking the typedef as the referenced type in QVTo transformations.
Suggestion b: Taking the OCL predefined type as the referenced type in QVTo transformations.
Suggestion c: Considering resolution of issue 13168, so that only OCL predefined exists, and therefore, the only type which can be referenced.

It's a little bit weird having 2 different types (a type, and its alias typedef) which represent just the same type, specially when they are related by a reference. 
My solution's preference in order are:
c) Just having one type to refer.
a) Since the typedef "extends" the behaviour of the predefined type (adding new operations), the former must be the referred one.
b) The OCL predefined type is referenced, but we must taking into account that operations added to the typedef are available.