The abstract syntax of QVTr allows a rule to be an override of another rule.

Rule::overrides: Rule [0..1]
The rule that this rule overrides.

The concrete syntax of QVT allows it too:

<relation> ::= ['top'] 'relation' <identifier>
['overrides' <identifier>]
'

'

However, the only semantics I can see for 'overrides' is in clause 7.11.1.4 that says:

"A rule may conditionally override another rule. The overriding rule is executed in place of the overridden rule when the overriding conditions are satisfied. The exact semantics of overriding are subclass specific. "

Questions:

1- What are the overriding conditions? are they implied or specified and if so how?

2- I have not seen any other discussion of overriding in a subclass or Rule so not sure what is meant by "The exact semantics of overriding are subclass specific"?

3- I have not seen any example of using 'overrides' what so ever in the spec, shouldn't there be one?

4 - What is the semantics of overriding? is it related to inheritance in the OO sense ? I think QVTr needs a good "inheritance" model where you can relations can be called polymorphically.

a production rule seems to be missing: <module_element> ::= <modeltype> Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified).

Section 8.7.1a production rule seems to be missing

a production rule seems to be missing: <module_element> ::= <modeltype> Since, a transformation file can define several transformations and libraries (modules), it is desirable having the possibility of defining modeltypes exclusively to a module. These "local" modelTypes should belong to the scope of a module, and it shouldn't be accessible to the remaining defined modules (unless the use of extension mechanisms is specified).

Discussion

A transformation is a major programming element so multiple transformations per file seems as unusual as multiple Java classes per file.

But we do already support

transformation X(...) {...}
transformation Y(...) {...}

so perhaps we need per transformation modeltypes.

But if we provided them as suggested: we would have

transformation X(in q : Q) {
modeltype Q uses ....;
}

allowing an outer declaration to depend on an inner.

If a user really wants many transformations per file with many distinct conflicting modeltypes, then the user has the option to use distinctive names for each modeltype.

Much more sensible to use multiple files in the first place.

Similarly we don't want or support per-transformation imports.

The EBNF:

<modeltype> ::= 'modeltype' <identifier> <compliance_kind>?
'uses' <packageref_list> <modeltype_where>? ';'
<modeltype_where> ::= 'where' <expression_block>

allows only a single where which may be a BlockExp, so ModelType.additionalCondition should be [0..1] rather than [*].

Incorrect ModelType.additionalCondition multiplicity

The EBNF:

<modeltype> ::= 'modeltype' <identifier> <compliance_kind>?
'uses' <packageref_list> <modeltype_where>? ';'
<modeltype_where> ::= 'where' <expression_block>

allows only a single where which may be a BlockExp, so ModelType.additionalCondition should be [0..1] rather than [*].

Discussion

Yes, but

<expression_block> ::= '{' <expression_list>? '}'

which allows for the multiple expressions.

The multiple expressions could be shown more clearly by flattening as:

<modeltype> ::= 'modeltype' <identifier> <compliance_kind>?
'uses' <packageref_list> ('where' '{' <expression_list>? '}')? ';'

But in the absence of a CS2AS mapping, implementations are not obliged to create the inappropriate BlockExp.

Issue 19146 removed most of the erroneous matchXXX arguments but omitted to do so for String:: matchIndentifier

Redundant argument on matchIdentifier

Issue 19146 removed most of the erroneous matchXXX arguments but omitted to do so for String:: matchIdentifier

Discussion

Yes

AssignExp to an Collection should make clear that the results is

target->including(source)->excluding(null)

which should exploit an OCL definition of OrderedSet::including to be add at end if necessary.

AssignExp unclear for OrderedSet

AssignExp to an Collection should make clear that the results is

target->including(source)->excluding(null)

which should exploit an OCL definition of OrderedSet::including to be add at end if necessary.

The Issue 19146 resolution is not sufficiently clear for Collection::deepclone.

Any nested mutables must be deepcloned, so the specification should require a recursive deepclone that the return decides between self or the clone according to whether any elements need to change

Clarify deepclone on Collections

The Issue 19146 resolution is not sufficiently clear for Collection::deepclone.

Any nested mutables must be deepcloned, so the specification should require a recursive deepclone that the return decides between self or the clone according to whether any elements need to change

Discussion

Yes

There is no mention of extent in Section 8.1 where one might hope to find an overview of the utility.

The proposed resolution of Issue 13103 clarifies the ability of ObjectExp to (re-)define the extent residence of a pre-existing object.

MappingParameter has some contradictory indications that an extent is bound by the callee rather than the caller.

Is this a consequence of the need for a MappingOperation to have a 1:1 correspondence to a QVTr Relation requiring the domain to be determined solely from the declaration? How is the inability of a Relation to have more than one parameter per domain accommodated when there can be more than one parameter per extent?

Specify the utility of an extent

There is no mention of extent in Section 8.1 where one might hope to find an overview of the utility.

The proposed resolution of Issue 13103 clarifies the ability of ObjectExp to (re-)define the extent residence of a pre-existing object.

MappingParameter has some contradictory indications that an extent is bound by the callee rather than the caller.

Is this a consequence of the need for a MappingOperation to have a 1:1 correspondence to a QVTr Relation requiring the domain to be determined solely from the declaration? How is the inability of a Relation to have more than one parameter per domain accommodated when there can be more than one parameter per extent?

Discussion

A section on Extents is sadly lacking; write it.

The confusing fiction that there is a correspondence between QVTo Model Parameters and QVTr Domains is best eliminated.

When mapping/relation refinement is used, it should be possible to specify via the abstract keyword that a mapping/relation is only intended for use in a refined form.

Thus in A.3.1, declaring classAttributes abstract could determine whether the execution needs to consider matches not covered by the classPrimitiveAttributes and classComplexAttributes refinements.

Support abstract mappings/relations

When mapping/relation refinement is used, it should be possible to specify via the abstract keyword that a mapping/relation is only intended for use in a refined form.

Thus in A.3.1, declaring classAttributes abstract could determine whether the execution needs to consider matches not covered by the classPrimitiveAttributes and classComplexAttributes refinements.

Discussion

A simple enhancement

The second example contains

"if result then return;"

which has a non-boolean condition expression and a missing endif.

In the first example, it is not clear that the revisit adds rather than overwrites.

In the third and fourth examples it is not clear why the second pass reuses the context for the first rather than creates new objects.

8.1.10 Errors in Examples

The second example contains

"if result then return;"

which has a non-boolean condition expression and a missing endif.

In the first example, it is not clear that the revisit adds rather than overwrites.

In the third and fourth examples it is not clear why the second pass reuses the context for the first rather than creates new objects.

Discussion

The examples are much worse than suggested; verging on the diabolical.

The resolution for Issue 12375 specifies that ListLiteralExp has
CollectionLiteralExp
as a superclass.

This leaves the behaviour of the inherited kind and part attributes
unspecified and
rather embarrassing.

ListLiteralExp (like DictLiteralExp) should inherit directly from
LiteralExp.

Inappropriate ListLiteralExp inheritance (Correction to issue 12375 resolution)

The resolution for Issue 12375 specifies that ListLiteralExp has CollectionLiteralExp as a superclass.

This leaves the behaviour of the inherited kind and part attributes unspecified and rather embarrassing.

ListLiteralExp (like DictLiteralExp) should inherit directly from LiteralExp.

Discussion

The lack of specification of ListLiteralExp::kind and ListLiteralExp::part is indeed a problem.

CollectionLiteralExp::kind is inextensible bloat that OCL could usefully eliminate, so no ListLiteralExp::kind is needed in QVTo.

ListLiteralExp::part is needed if QVTo is truly an extension of OCL. Unfortunately the QVTo BNF omits the ".." operator and support for CollectionRanges.

Therefore we need to introduce the missing CollectionRange parsing. ListLiteralExp can inherit LiteralExp adding CollectionLiteralExp::part but not CollectionLiteralExp::kind. ListLiteralExp::element is misguided; ListLiteralExp::part replaces it.

In operational QVT, it is not clear what happens when the "when" or "where" clause of an inherited mapping does not hold.

Suggestion:
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.

Commentary:
An interesting discussion is if something similar to the Liskov substitution principle should be applied in this situation.

Undefined semantics for unsatisfied "when" and "where" in inherited mapping

In operational QVT, it is not clear what happens when the "when" or "where" clause of an inherited mapping does not hold.

Suggestion:
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.

Commentary:
An interesting discussion is if something similar to the Liskov substitution principle should be applied in this situation.

Discussion

The suggestions regarding constraint inheritance and LSP are appropriate for a declarative language; they are not appropriate for a pragmatic imperative language such as QVTo. Each mapping can be independently specified.

It can be made clearer that pre and post conditions are assertions that fail accordingly.

Comparison of QVTr/QVTo when and where highlights the fallacy that a QVTo mapping is a refinement of QVTr relation. In QVTo, failure of a where post-condition is a catastrophic assertion failure, whereas a QVTr where clause is a corrollary to be attempted afterwards and ignored if it fails/fails to match. The claim in 8.1.4 that the QVTo when and where clauses are owned by QVTr is untrue; QVTo owns its own when and where clauses and works very well without any QVTr objects.

Trace data creation is specified to happen "at the end of the initialization section".

For disjuncting mappings, the initialization section is never executed, which prevents any trace data from being stored.

As a consequence, no resolution via resolve-in-expressions is possible on the disjuncting mapping, due to the missing trace record. This is problematic, since disjunction should be transparent from a resolver's point of view, i.e. it should not make a difference for resolution whether a mapping disjuncts or not.

Hence, some clarification is required whether trace records are deliberately avoided for disjuncting mappings (for whatever reason), or whether trace data must be created in another place than the init section in case of a disjuncting mapping.

No trace data for disjuncting mapping

Trace data creation is specified to happen "at the end of the initialization section".

For disjuncting mappings, the initialization section is never executed, which prevents any trace data from being stored.

As a consequence, no resolution via resolve-in-expressions is possible on the disjuncting mapping, due to the missing trace record. This is problematic, since disjunction should be transparent from a resolver's point of view, i.e. it should not make a difference for resolution whether a mapping disjuncts or not.

Hence, some clarification is required whether trace records are deliberately avoided for disjuncting mappings (for whatever reason), or whether trace data must be created in another place than the init section in case of a disjuncting mapping.

Discussion

It seems the 8.1.x section on Tracing never got written. Time for a thorough review and clarification.

Trace lookups by source objects treat context and all in/inout parameters as source objects.

Trace lookups by target objects treat all out/inout and result parameters as target objects.

Trace lookups by mapping allow either disjuncting mapping or candidate mapping to be used as the mapping selection.

If re-execution is to be completely suppressed and fully re-use a previous execution, the output trace should be the final outputs, but the existing text is clear that it is the preliminary outputs at the end of the initialization section. The earlier trace gives a slightly different semantics that requires the population section to modify the created object after it is traced and allows the population section to use the trace. This is different but fine when explained clearly.

References to 8.1.12 refer to the new text from the QVT13-99 resolution.

The spec should clarify the interaction of
1.) explicit instantiation + execution of 'accessed' transformations, and
2.) trace records / resolving.

The following questions are of interest:

How does the initial trace for an 'accessed' transformation look like? Does it reuse the records previously created by the 'accessing' transformation, or does an 'accessed' transformation always start on an empty trace?

How does an 'accessed' transformation affect the trace? Are the trace records post-visible that were created during execution of the 'accessed' transformation, or is the trace of the 'accessing' transformation unchanged?

Both issues heavily affect the results of resolve-operations. Resolving object references after executing an 'accessed' transformation would be very practical.

Trace data for an 'accessed' transformation

The spec should clarify the interaction of
1.) explicit instantiation + execution of 'accessed' transformations, and
2.) trace records / resolving.

The following questions are of interest:

How does the initial trace for an 'accessed' transformation look like? Does it reuse the records previously created by the 'accessing' transformation, or does an 'accessed' transformation always start on an empty trace?

How does an 'accessed' transformation affect the trace? Are the trace records post-visible that were created during execution of the 'accessed' transformation, or is the trace of the 'accessing' transformation unchanged?

Both issues heavily affect the results of resolve-operations. Resolving object references after executing an 'accessed' transformation would be very practical.

Discussion

The resolution of QVT13-23 makes clear that the trace data contains a trace record for every mapping.

QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent for which the first parameter is a hidden self, or indeed QVTo.

Perhaps something closer to Complete OCL would do, allowing def'd attributes or operations.

QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent

QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent for which the first parameter is a hidden self, or indeed QVTo.

Perhaps something closer to Complete OCL would do, allowing def'd attributes or operations.

Discussion

QVTo has contextual helpers.

Syntactically it is trivial for QVTc and QVTo to have contextual queries just by allowing a scoped rather than simple name for the query.

Semantically to avoid duuplicating QVTo AS irregularities we can use the synonym package merges for Complete OCL to make the implementation easy.

This is a suggestion:

A developer may need to take a set of in models that may vary in size each time he runs the transformation.

So, instead of hard-coding the input/out put models when defining the transformation like this:

transformation Uml2Rdbms(in uml:UML,out rdbms:RDBMS)

The developer should be able to define a dynamic set of input models. So that he will not be obligated to change the transformation definition if the number of input models change every time he runs the transformation.

For example, I defined a transformation that takes multiple input models (conforming to the same meta-model) to merge them. Now, I got different number of in models every time I run the transformation. To make this more dynamic, I need to take an array of models as an input to my transformation without specifying their numbers in the transformation definition each time I run the transformation.

Dynamic set of input models

This is a suggestion:

A developer may need to take a set of in models that may vary in size each time he runs the transformation.

So, instead of hard-coding the input/out put models when defining the transformation like this:

transformation Uml2Rdbms(in uml:UML,out rdbms:RDBMS)

The developer should be able to define a dynamic set of input models. So that he will not be obligated to change the transformation definition if the number of input models change every time he runs the transformation.

For example, I defined a transformation that takes multiple input models (conforming to the same meta-model) to merge them. Now, I got different number of in models every time I run the transformation. To make this more dynamic, I need to take an array of models as an input to my transformation without specifying their numbers in the transformation definition each time I run the transformation.

Discussion - imperative

This is already supported by the QVTo grammar. Just define a Collection of models as input or output.

transformation Uml2Rdbms(in uml:Sequence(UML),out rdbms:Sequence(RDBMS))

and use collection operations to access the individual models.

Discussion - declarative

xcolect is specified to like collect, which flattens, however the xcollect pseudocode does not flatten.

xcollect is ambiguously flattened

xcollect is specified to like collect, which flattens, however the xcollect pseudocode does not flatten.

Discussion

Ditto xcollectselect, xcollectselectOne

Once an attempt is made to put the pseudo-code through Eclipse QVTo, it is quite amazing how many different errors there are.

• spurious source/iterator arguments
• missing compute open {
• increarect non-collection returns
• incorrect accommodation of ordered collections
• no flattening
• no single values
• use of mutable Sequence rather than List

Intuitively List and Dict are objects, so if you pass them to a mapping/query/helper as an inout parameter, the object in the caller may be updated by the call.

This is the behaviour of a Class Instance not a DataType Value.

Please use the open https://bugs.eclipse.org/bugs/show_bug.cgi?id=420150 to discuss this topic.

List and Dict Class/DataType confusion

Intuitively List and Dict are objects, so if you pass them to a mapping/query/helper as an inout parameter, the object in the caller may be updated by the call.

This is the behaviour of a Class Instance not a DataType Value.

Discussion

Equally intuitively List (and Dict) are values. Two distinct 'occurrences' may be equal. This is the behavior of a DataType not a Class.

List and Dict are specified as CollectionType (DataType) derivations so we just need to fix up indications that List and Dict are Classes.

While clarifying wording, QVT13-120 is merged to remove the prohibition on object creation/update in helpers.

8.1.4 states "a mapping operation is always a refinement of an implicit relation" but 8.2.15 defines "refinedRelation: Relation [0..1] The refined relation, if any." Clearly a contradiction.

8.1.4. provides the REL_PackageToSchema example of how an implicit relation might be defined, but no other examples or synthesis rules are supplied.

enforce and checkonly appear in the REL_PackageToSchema example indicating that these define execution mode of a QVTo trnasformation, but there does not appear to be any description of how a transformation might be executed to for instance update an output model. Perhaps the 'output' parameter is 'inout' for create/update but 'out' for create/overwrite.

8 Unclear mapping operation characteristics

8.1.4 states "a mapping operation is always a refinement of an implicit relation" but 8.2.15 defines "refinedRelation: Relation [0..1] The refined relation, if any." Clearly a contradiction.

8.1.4. provides the REL_PackageToSchema example of how an implicit relation might be defined, but no other examples or synthesis rules are supplied.

enforce and checkonly appear in the REL_PackageToSchema example indicating that these define execution mode of a QVTo trnasformation, but there does not appear to be any description of how a transformation might be executed to for instance update an output model. Perhaps the 'output' parameter is 'inout' for create/update but 'out' for create/overwrite.

Discussion

The aspiration that every QVTo mapping has an underlying QVTr relation is fairly dubious. But there is no point respecifying until some prototyping feedback is available.

The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html need to be addressed. Apologies too for the long email. This is a very difficult area where precision is important. Provision of
this resolution demonstrates the need for the resolution, but unfortunately the resolution has an
erroneous precision that will make QVTr 1.1 unimplementable whereas QVTr 1.0 is just mildly
ambiguous and conflicting.
Please do not include the resolution in QVT 1.1 without significantrework.
I found the definition of the "checkonly"/"enforce" to isCheckable/isEnforceable helpful, although
different to three of my own intuitive guesses based on attempts to avoid errors in ModelMorf and
Rel2Core examples.
The problems identified below are the result of a local review of the resolution. In the absence of a
coherent Environment semantics it has not been possible to perform a global review. In particular, I
was unable to review the specification for the arguably redundant bindsTo.
[Incidentally, the same resolution approach is needed for QVTc and QVTo].
Disambiguating rules
--------------------
The resolution uses a similar approach to the OCL 2.0 specification, but neglects to provide any
disambiguating rules although many are needed.
Environments
------------
OCL and the resolution employ environments to carry definitions specific to particular CS constructs,
so that a CS reference may be resolved with the aid of an environment or the AST.
In EssentialOCL, all definitions are resolvable with in the immutable AST with the exception of let and
iterator expressions for which a nestedEnvironment() is used to carry the extra variable declaration
with the aid of addElement(). The nestedEnvironment supports name occlusion from outer scopes.
In CompleteOCL, further definitions may be introduced by a definition constraint. The OCL
specification provides no precise insight into how an environment changes to accommodate the
definition. Should the name be added to the AST or to the environment? Is the name available for
forward reference?
Environment::addElement is defined as a query operation thereby inhibiting side effects. Consequently
usage such as
XX.env = YY.env.addElement(Z.name, Z.ast, false)
leaves the environment of YY unchanged and creates an extended environment for XX.
A series of such usages creates a series of progressively elaborated environments that support
backward but not forward referencing. This was not a clear requirement of the QVT 1.0 specification
and it prevents any variable declarations being introduced in an object template tree being resolved
through environments in other object template trees or predicate expressions.
QVT 1.2 RTF Report Page 173 of 190
Object Management Group
RTF/FTF Report
Imposition of no forward referencing seems very undesirable, particularly since the order of domains is
imposed by the model parameter order. Imagine a Java program in which all methods had to be
defined in a no-forward reference order.
As noted above, CompleteOCL neglected to define how AST definitions were added to the AST. QVTr
must solve this problem since QVTr defines a hierarchically scoped AST rather than an annotation of
a pre-existing AST.
I recommend a two stage approach. The inherited attributes section should first compute an
environment from the pushed-down parent environment augmented by pull-ups from child constructs
so that a complete immutable and consequently unambiguous environment is associated with each
construct and then pushed-down to the children. During the pull-up the environment acquires a
mapping from name to future-AST. During the push-down residual future-AST attributes are populated
to give a valid AST.
Reference resolution
--------------------
OCL uses lookup functions to resolve variable references. It is necessary either to overload the lookup
functions so that the the distinct QVTr variable definition sites can be located in the AST, or to use
some form of Environment::addElement where each definition is defined so that resolution in the
environment is possible.
Details
=======
Throughout, many disambiguating rules are needed to define illegal semantics. For instance "any" is
often used to select a syntactically valid value. Corresponding usage in the OCL specification has a
disambiguating rule to clarify what the consequence of not "one" is.
My current best attempt at Disambiguating Rules is attached.
Environment::addElement takes three arguments, the third being a mayBeImplicit argument. This has
been omitted throughout without explanation.
identifierCS
------------
OCL defines SimpleNameCS. A degenerate mapping from identifierCS to SimplenameCS is required.
topLevelCS
----------
The 'imported transformation' environment element is later referenced as 'imported transformations'.
Typo: TransformationListCS for transformationListCS in Synthesized attributes.
importListCS
------------
Semantics of import conflicts must be defined.
unitCS
------
Typo: ast is not a Set.
Surely the import is of packages (enumerations or operations)or at least transformations (QVTo
implementations) rather than necessarily relational-transformations?
transformationCS
----------------
QVT 1.2 RTF Report Page 174 of 190
Object Management Group
RTF/FTF Report
ownedTag is not synthesized.
keyDeclListCS
-------------
Typo: wrong font in synthesized attributes
modelDeclCS
-----------
The [B] grammar:
modelDeclCS ::= modelIdCS ':' '

'
is missing.
keyDeclCS
---------
Synthesized attributes appear to have experienced a copy and paste error while providing distinct part
and oppositePart left hand sides.
keyPropertyCS
-------------
The synthesized attributes poke the parent.
Suggest: it would be clearer for the parent to gather and distribute children similar to the relation/query
allocation by transformationCS.
relationCS
----------
Transformation.extends does not appear to be transitive.
topQualifierCS
--------------
Suggest: a boolean or enumerated value rather than a string.
domainListCS
------------
Typo: missing indentation.
primitiveTypeDomainCS
---------------------
isCheckable, isEnforceable not synthesized.
objectTemplateCS
----------------
Variable needs to be added to relation to provide a container.
Variable needs to be added to relation environment to provide visibility.
collectionTemplateCS
--------------------
Variable needs to be added to relation to provide a container.
Variable needs to be added to relation environment to provide visibility.
Suggest: last two if guards are redundant.
QVT 1.2 RTF Report Page 175 of 190
Object Management Group
RTF/FTF Report
restCS
------
Variable needs to be added to relation to provide a container.
Non-_ named variable needs to be added to relation environment to provide visibility.
memberCS
--------
Variable needs to be added to relation to provide a container.
Non-_ named variable needs to be added to relation environment to provide visibility.
whenCS
------
predicateListCS should be optional.
whereCS
-------
predicateListCS should be optional.
ExtOclExpressionCS
------------------
This is not present in the QVTr or OCL grammar.
Presumably it represents the QVTr extension to OCL's OclExpressionCS.
However it is an extension, since at least RelationCallExpCS can be used in an ordinary
OclExpressionCS using "not" or "and".
[A], [B], [C] should therefore follow on from OCL's
[A], [B], [C]..., [I].
RelationCallExpressionCS
------------------------
How is a RelationCallExpressionCS distinguished from an OperationCallExpCS?

QVTr syntax mapping (correction to Issue 10646 resolution)

The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html need to be addressed. Apologies too for the long email. This is a very difficult area where precision is important. Provision of
this resolution demonstrates the need for the resolution, but unfortunately the resolution has an
erroneous precision that will make QVTr 1.1 unimplementable whereas QVTr 1.0 is just mildly
ambiguous and conflicting.
Please do not include the resolution in QVT 1.1 without significantrework.
I found the definition of the "checkonly"/"enforce" to isCheckable/isEnforceable helpful, although
different to three of my own intuitive guesses based on attempts to avoid errors in ModelMorf and
Rel2Core examples.
The problems identified below are the result of a local review of the resolution. In the absence of a
coherent Environment semantics it has not been possible to perform a global review. In particular, I
was unable to review the specification for the arguably redundant bindsTo.
[Incidentally, the same resolution approach is needed for QVTc and QVTo].
Disambiguating rules
--------------------
The resolution uses a similar approach to the OCL 2.0 specification, but neglects to provide any
disambiguating rules although many are needed.
Environments
------------
OCL and the resolution employ environments to carry definitions specific to particular CS constructs,
so that a CS reference may be resolved with the aid of an environment or the AST.
In EssentialOCL, all definitions are resolvable with in the immutable AST with the exception of let and
iterator expressions for which a nestedEnvironment() is used to carry the extra variable declaration
with the aid of addElement(). The nestedEnvironment supports name occlusion from outer scopes.
In CompleteOCL, further definitions may be introduced by a definition constraint. The OCL
specification provides no precise insight into how an environment changes to accommodate the
definition. Should the name be added to the AST or to the environment? Is the name available for
forward reference?
Environment::addElement is defined as a query operation thereby inhibiting side effects. Consequently
usage such as
XX.env = YY.env.addElement(Z.name, Z.ast, false)
leaves the environment of YY unchanged and creates an extended environment for XX.
A series of such usages creates a series of progressively elaborated environments that support
backward but not forward referencing. This was not a clear requirement of the QVT 1.0 specification
and it prevents any variable declarations being introduced in an object template tree being resolved
through environments in other object template trees or predicate expressions.
QVT 1.2 RTF Report Page 173 of 190
Object Management Group
RTF/FTF Report
Imposition of no forward referencing seems very undesirable, particularly since the order of domains is
imposed by the model parameter order. Imagine a Java program in which all methods had to be
defined in a no-forward reference order.
As noted above, CompleteOCL neglected to define how AST definitions were added to the AST. QVTr
must solve this problem since QVTr defines a hierarchically scoped AST rather than an annotation of
a pre-existing AST.
I recommend a two stage approach. The inherited attributes section should first compute an
environment from the pushed-down parent environment augmented by pull-ups from child constructs
so that a complete immutable and consequently unambiguous environment is associated with each
construct and then pushed-down to the children. During the pull-up the environment acquires a
mapping from name to future-AST. During the push-down residual future-AST attributes are populated
to give a valid AST.
Reference resolution
--------------------
OCL uses lookup functions to resolve variable references. It is necessary either to overload the lookup
functions so that the the distinct QVTr variable definition sites can be located in the AST, or to use
some form of Environment::addElement where each definition is defined so that resolution in the
environment is possible.
Details
=======
Throughout, many disambiguating rules are needed to define illegal semantics. For instance "any" is
often used to select a syntactically valid value. Corresponding usage in the OCL specification has a
disambiguating rule to clarify what the consequence of not "one" is.
My current best attempt at Disambiguating Rules is attached.
Environment::addElement takes three arguments, the third being a mayBeImplicit argument. This has
been omitted throughout without explanation.
identifierCS
------------
OCL defines SimpleNameCS. A degenerate mapping from identifierCS to SimplenameCS is required.
topLevelCS
----------
The 'imported transformation' environment element is later referenced as 'imported transformations'.
Typo: TransformationListCS for transformationListCS in Synthesized attributes.
importListCS
------------
Semantics of import conflicts must be defined.
unitCS
------
Typo: ast is not a Set.
Surely the import is of packages (enumerations or operations)or at least transformations (QVTo
implementations) rather than necessarily relational-transformations?
transformationCS
----------------
QVT 1.2 RTF Report Page 174 of 190
Object Management Group
RTF/FTF Report
ownedTag is not synthesized.
keyDeclListCS
-------------
Typo: wrong font in synthesized attributes
modelDeclCS
-----------
The [B] grammar:
modelDeclCS ::= modelIdCS ':' '

'
is missing.
keyDeclCS
---------
Synthesized attributes appear to have experienced a copy and paste error while providing distinct part
and oppositePart left hand sides.
keyPropertyCS
-------------
The synthesized attributes poke the parent.
Suggest: it would be clearer for the parent to gather and distribute children similar to the relation/query
allocation by transformationCS.
relationCS
----------
Transformation.extends does not appear to be transitive.
topQualifierCS
--------------
Suggest: a boolean or enumerated value rather than a string.
domainListCS
------------
Typo: missing indentation.
primitiveTypeDomainCS
---------------------
isCheckable, isEnforceable not synthesized.
objectTemplateCS
----------------
Variable needs to be added to relation to provide a container.
Variable needs to be added to relation environment to provide visibility.
collectionTemplateCS
--------------------
Variable needs to be added to relation to provide a container.
Variable needs to be added to relation environment to provide visibility.
Suggest: last two if guards are redundant.
QVT 1.2 RTF Report Page 175 of 190
Object Management Group
RTF/FTF Report
restCS
------
Variable needs to be added to relation to provide a container.
Non-_ named variable needs to be added to relation environment to provide visibility.
memberCS
--------
Variable needs to be added to relation to provide a container.
Non-_ named variable needs to be added to relation environment to provide visibility.
whenCS
------
predicateListCS should be optional.
whereCS
-------
predicateListCS should be optional.
ExtOclExpressionCS
------------------
This is not present in the QVTr or OCL grammar.
Presumably it represents the QVTr extension to OCL's OclExpressionCS.
However it is an extension, since at least RelationCallExpCS can be used in an ordinary
OclExpressionCS using "not" or "and".
[A], [B], [C] should therefore follow on from OCL's
[A], [B], [C]..., [I].
RelationCallExpressionCS
------------------------
How is a RelationCallExpressionCS distinguished from an OperationCallExpCS?

Discussion

These issues cannot be sensibly addressed until the auto-generation being pioneered for OCL can be re-used.

I’m having trouble with the semantics of DELETE on p. 189 of the QVT Specification (v1.1). It reads in part:

FORALL OBJVAR IN MAKESET(<DOMAIN_K_VARIABLE_SET>) (
…
AND BELONGSTO(OBJVAR, MAKESET(<DOMAIN_K_VARIABLE_SET>))

I guess I don’t understand MAKESET and BELONGSTO. First of all, <DOMAIN_K_VARIABLE_SET> is already a set, so what’s the MAKESET function do? Second, the FORALL iterates OBJVAR over the results of the same MAKESET that BELONGSTO tests. So how can BELONGSTO be false? That is, I would assume BELONGSTO is defined as follows:

BELONGSTO(e, S) º e ÎS

except that under this definition the expression above is always satisfied.

Any and all help appreciated. Thank you very much.

Specification of deletion semantics

I’m having trouble with the semantics of DELETE on p. 189 of the QVT Specification (v1.1). It reads in part:

FORALL OBJVAR IN MAKESET(<DOMAIN_K_VARIABLE_SET>) (
…
AND BELONGSTO(OBJVAR, MAKESET(<DOMAIN_K_VARIABLE_SET>))

I guess I don’t understand MAKESET and BELONGSTO. First of all, <DOMAIN_K_VARIABLE_SET> is already a set, so what’s the MAKESET function do? Second, the FORALL iterates OBJVAR over the results of the same MAKESET that BELONGSTO tests. So how can BELONGSTO be false? That is, I would assume BELONGSTO is defined as follows:

BELONGSTO(e, S) º e ÎS

except that under this definition the expression above is always satisfied.

Any and all help appreciated. Thank you very much.

Discussion

Well this is very embarrassing. I don't understand it all either, and I certainly do not understand why it is not written using OCL.

I'm not convinced that QVTr has any delete semantics since declaratively delete occurs as an absence of creation.

Must await the Eclipse QVTr prototype.

The abstract syntax of QVTr allows a rule to be an override of another rule.

Rule::overrides: Rule [0..1]
The rule that this rule overrides.

The concrete syntax of QVT allows it too:

<relation> ::= ['top'] 'relation' <identifier>
['overrides' <identifier>]
'

'

However, the only semantics I can see for 'overrides' is in clause 7.11.1.4 that says:

"A rule may conditionally override another rule. The overriding rule is executed in place of the overridden rule when the overriding conditions are satisfied. The exact semantics of overriding are subclass specific. "

Questions:

1- Whtat are the overriding conditions? are they implied or specified and if so how?

2- I have not seen any other discussion of overrding in a subclass or Rule so not sure what is meant by "The exact semantics of overriding are subclass specific"?

3- I have not seen any example of using 'overrides' what so ever in the spec, shouldn't there be one?

4 - What is the semantics of overriding? is it related to inheritance in the OO sense ? I think QVTr needs a good "inheritance" model where you can relations can be called polymorphically.

Rule Overriding in QVTr

The abstract syntax of QVTr allows a rule to be an override of another rule.

Rule::overrides: Rule [0..1]
The rule that this rule overrides.

The concrete syntax of QVT allows it too:

<relation> ::= ['top'] 'relation' <identifier>
['overrides' <identifier>]
'

'

However, the only semantics I can see for 'overrides' is in clause 7.11.1.4 that says:

"A rule may conditionally override another rule. The overriding rule is executed in place of the overridden rule when the overriding conditions are satisfied. The exact semantics of overriding are subclass specific. "

Questions:

1- What are the overriding conditions? are they implied or specified and if so how?

2- I have not seen any other discussion of overriding in a subclass or Rule so not sure what is meant by "The exact semantics of overriding are subclass specific"?

3- I have not seen any example of using 'overrides' what so ever in the spec, shouldn't there be one?

4 - What is the semantics of overriding? is it related to inheritance in the OO sense ? I think QVTr needs a good "inheritance" model where you can relations can be called polymorphically.

Discussion

This now a much better understood field:

M. Wimmer, G. Kappel, A. Kusel, W. Retschitzegger, J. Schönböck, W. Schwinger, D. Kolovos, R. Paige, M. Lauder, A. Schürr, D. Wagelaar. Surveying Rule Inheritance in Model-to-Model Transformation Languages. In Journal of Object Technology, vol. 11, no. 2, 2012, pages 3:1–46. doi:10.5381/jot.2012.11.2.a3

QVTBase currently imposes single overriding which is unnecessary, and causes a problem for an application that needs to extend when B1 overrides A and B2 overrides A. The extending mapping needs C to override both B1 and B2 to ensure that C occludes both B1 and B2. Therefore we need multi-overrides.

Oops. A QVTc Mapping::refines is an alternative concept that competes without comment with the inherited Rule::overrides. relToCore completely ignores the semantics of overrides translation. Relation::overrides should probably map across unchanged to Mapping::overrides. QVTc and QVTr semantics are unchanged.

Fixing this textually without a prototype is too much of change.

"The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction

Unclear transformation rooting condition

"The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction

Discussion

We need a much simpler principled exposition of the intent of QVTc/QVTr. Since Perdita has correctly come to such unwelcome conclusions, we clearly have a problem. The new statement should be uncontroversial and therefore provide a reference against which subsequent text can be assessed.

The following is perhaps what is needed, but needs more discussion with QVTr users and prototyping of its implications.

In Section 6.3 replace

The semantics of the Core language (and hence the Relations language) allow for the following execution scenarios:
• Check-only transformations to verify that models are related in a specified way.
• Single direction transformations.
• Bi-directional transformations. (In fact more than two directions are possible, but two is the most common case.)
• The ability to establish relationships between pre-existing models, whether developed manually, or through some other
tool or mechanism.
• Incremental updates (in any direction) when one related model is changed after an initial execution.
• The ability to create as well as delete objects and values, while also being able to specify which objects and values must
not be modified.

by

A Declarative QVT transformation capability establishes a correspondence between source objects in one or more source models and transformed objects in one or more transformed models. The correspondence may be used to check or enforce a view of, or a transformation to, target objects in one or more target models.

The correspondence takes the form of trace data comprising a set of trace records. Each trace record identifies a relationship to one or more transformed objects from, one or more, source or transformed, objects or values. The production of each transformed object is traced by exactly one trace record. The trace data includes relationships for all satisfied constraints imposed by the language constructs that express the transformation program. No relationships for satisfiable constraints are omitted from the trace data.

In practice a Core language (and hence the Relations language) transformation is executed after a form, mode and direction have been selected.

There are two main forms of QVT execution:

• For a Transformation execution, there is an exactly 1:1 mapping between the transformed objects and the target objects.

• For a View execution, there is an exactly 1:1 mapping between the transformed objects and the target objects in the view. There may be further target objects outside the view that are unaffected by the execution.

Additionally, for a Query execution, an OCL query is executed on the trace data. No actual target models are required.

There are three modes of execution:

• An enforced View or Transformation execution coerces the target objects to correspond to the transformed objects. (This is most simply achieved by model replacement, but may be realized by executing a series of changes so that desirable extra-model considerations such as xmi:id preservation or minimal database activity are accommodated.)

• A check execution is a degenerate Query execution that just returns true or false according to the existence of the trace data. (An optimized execution capability may bypass the creation of the transformed objects and look for correspondence between source and target objects directly.)

• An update Query, View or Transformation execution compares an old correspondence between source objects and transformed objects with a new correspondence between changed source objects and correspondingly changed transformed objects. The correspondence changes may be used to enforce or check for corresponding creations, deletions and updates in the target objects.

Additionally an in-place update View or Transformation execution shares source and target models and so each source object is coerced to correspond to its transformed equivalent. (This can be naively achieved by model copy. An optimized execution may bypass the creation of the transformed objects by performing each source read before any corrupting write.)

The declarative transformation languages do not have fixed sources and targets, rather they have multiple domains some of which may be designated sources and others as targets. The direction of the transformation is chosen by selecting the domain to be used as a target.

• A unidirectional transformation has just a single choice of direction since only one domain is able to be used as the target

• For a bi-directional, and more generally a multi-directional transformation, the domain used as the target may be selected

In practice it is often difficult to satisfy the bijective requirements of bidirectional execution and so many transformations are just unidirectional.

The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance.

For a Package: self.nestingPackage.nestedPackages->includes(self)

For a Class:
self.package.ownedTypes->includes(self)

But self cannot have two containers.

The problem is easily resolved by extending only Package and adding those Class features that are actually required.

Inconsistent multiple inheritance

The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance.

For a Package: self.nestingPackage.nestedPackages->includes(self)

For a Class:
self.package.ownedTypes->includes(self)

But self cannot have two containers.

The problem is easily resolved by extending only Package and adding those Class features that are actually required.

Discussion

Transformation is mostly a Class that may have arbitrary Package scoping. This has been successfully prototyped by the Eclipse QVT projects, but not in sufficient detail to justify this slightly breaking change.

Problem:

ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified.

However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation:

constructor Column::ColumnConstructor (n:String,t: String)

object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);

Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint.

context ObjectExp
inv : argument->size() > 0 implies body.oclIsUndefined()

Discussion:
This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid.

Proposed solution:

In section 8.2.1.24 add the following subsection:

Constraints

If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa):

context ObjectExp
inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and
not body.oclIsUndefined() implies argument->isEmpty()

In section 8.2.1.24 add the following to the the end notation subsection:

Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body:

object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);

Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated).

In section 8.4.7:

Replace:

<object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
<expression_block>

By:

<object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
(<expression_block> | '(' (<declarator_list>)? ')' )

Enhance ObjectExp to allow constructors invocation

Problem:

ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified.

However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation:

constructor Column::ColumnConstructor (n:String,t: String)

object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);

Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint.

context ObjectExp
inv : argument->size() > 0 implies body.oclIsUndefined()

Discussion:
This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid.

Proposed solution:

In section 8.2.1.24 add the following subsection:

Constraints

If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa):

context ObjectExp
inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and
not body.oclIsUndefined() implies argument->isEmpty()

In section 8.2.1.24 add the following to the the end notation subsection:

Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body:

object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);

Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated).

In section 8.4.7:

Replace:

<object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
<expression_block>

By:

<object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
(<expression_block> | '(' (<declarator_list>)? ')' )

Discussion

This was extensively discussed on the Eclipse qvto-dev mailing list.

The conclusion was that the inheritance of ObjectExp from InstantiationExp is pragmatic and causes more problems that it solves. It should be eliminated.

Allowing objects to be constructed by a constructor expression rather field assignment is a nice syntax enhancement for significant utility classes.

It is hoped that a resolution will be prototyped by:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=479657

The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance.

For a Package: self.nestingPackage.nestedPackages->includes(self)

For a Class:
self.package.ownedTypes->includes(self)

But self cannot have two containers.

The problem is easily resolved by extending only Package and adding those Class features that are actually required.

Problem:

ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified.

However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation:

constructor Column::ColumnConstructor (n:String,t: String)

object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);

Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint.

context ObjectExp
inv : argument->size() > 0 implies body.oclIsUndefined()

Discussion:
This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid.

Proposed solution:

In section 8.2.1.24 add the following subsection:

Constraints

If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa):

context ObjectExp
inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and
not body.oclIsUndefined() implies argument->isEmpty()

In section 8.2.1.24 add the following to the the end notation subsection:

Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body:

object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);

Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated).

In section 8.4.7:

Replace:

<object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
<expression_block>

By:

<object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
(<expression_block> | '(' (<declarator_list>)? ')' )

"The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction

8.1.4 states "a mapping operation is always a refinement of an implicit relation" but 8.2.15 defines "refinedRelation: Relation [0..1] The refined relation, if any." Clearly a contradiction.

8.1.4. provides the REL_PackageToSchema example of how an implicit relation might be defined, but no other examples or synthesis rules are supplied.

enforce and checkonly appear in the REL_PackageToSchema example indicating that these define execution mode of a QVTo trnasformation, but there does not appear to be any description of how a transformation might be executed to for instance update an output model. Perhaps the 'output' parameter is 'inout' for create/update but 'out' for create/overwrite.

The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html need to be addressed. Apologies too for the long email. This is a very difficult area where precision is important. Provision of
this resolution demonstrates the need for the resolution, but unfortunately the resolution has an
erroneous precision that will make QVTr 1.1 unimplementable whereas QVTr 1.0 is just mildly
ambiguous and conflicting.
Please do not include the resolution in QVT 1.1 without significantrework.
I found the definition of the "checkonly"/"enforce" to isCheckable/isEnforceable helpful, although
different to three of my own intuitive guesses based on attempts to avoid errors in ModelMorf and
Rel2Core examples.
The problems identified below are the result of a local review of the resolution. In the absence of a
coherent Environment semantics it has not been possible to perform a global review. In particular, I
was unable to review the specification for the arguably redundant bindsTo.
[Incidentally, the same resolution approach is needed for QVTc and QVTo].
Disambiguating rules
--------------------
The resolution uses a similar approach to the OCL 2.0 specification, but neglects to provide any
disambiguating rules although many are needed.
Environments
------------
OCL and the resolution employ environments to carry definitions specific to particular CS constructs,
so that a CS reference may be resolved with the aid of an environment or the AST.
In EssentialOCL, all definitions are resolvable with in the immutable AST with the exception of let and
iterator expressions for which a nestedEnvironment() is used to carry the extra variable declaration
with the aid of addElement(). The nestedEnvironment supports name occlusion from outer scopes.
In CompleteOCL, further definitions may be introduced by a definition constraint. The OCL
specification provides no precise insight into how an environment changes to accommodate the
definition. Should the name be added to the AST or to the environment? Is the name available for
forward reference?
Environment::addElement is defined as a query operation thereby inhibiting side effects. Consequently
usage such as
XX.env = YY.env.addElement(Z.name, Z.ast, false)
leaves the environment of YY unchanged and creates an extended environment for XX.
A series of such usages creates a series of progressively elaborated environments that support
backward but not forward referencing. This was not a clear requirement of the QVT 1.0 specification
and it prevents any variable declarations being introduced in an object template tree being resolved
through environments in other object template trees or predicate expressions.
QVT 1.2 RTF Report Page 173 of 190
Object Management Group
RTF/FTF Report
Imposition of no forward referencing seems very undesirable, particularly since the order of domains is
imposed by the model parameter order. Imagine a Java program in which all methods had to be
defined in a no-forward reference order.
As noted above, CompleteOCL neglected to define how AST definitions were added to the AST. QVTr
must solve this problem since QVTr defines a hierarchically scoped AST rather than an annotation of
a pre-existing AST.
I recommend a two stage approach. The inherited attributes section should first compute an
environment from the pushed-down parent environment augmented by pull-ups from child constructs
so that a complete immutable and consequently unambiguous environment is associated with each
construct and then pushed-down to the children. During the pull-up the environment acquires a
mapping from name to future-AST. During the push-down residual future-AST attributes are populated
to give a valid AST.
Reference resolution
--------------------
OCL uses lookup functions to resolve variable references. It is necessary either to overload the lookup
functions so that the the distinct QVTr variable definition sites can be located in the AST, or to use
some form of Environment::addElement where each definition is defined so that resolution in the
environment is possible.
Details
=======
Throughout, many disambiguating rules are needed to define illegal semantics. For instance "any" is
often used to select a syntactically valid value. Corresponding usage in the OCL specification has a
disambiguating rule to clarify what the consequence of not "one" is.
My current best attempt at Disambiguating Rules is attached.
Environment::addElement takes three arguments, the third being a mayBeImplicit argument. This has
been omitted throughout without explanation.
identifierCS
------------
OCL defines SimpleNameCS. A degenerate mapping from identifierCS to SimplenameCS is required.
topLevelCS
----------
The 'imported transformation' environment element is later referenced as 'imported transformations'.
Typo: TransformationListCS for transformationListCS in Synthesized attributes.
importListCS
------------
Semantics of import conflicts must be defined.
unitCS
------
Typo: ast is not a Set.
Surely the import is of packages (enumerations or operations)or at least transformations (QVTo
implementations) rather than necessarily relational-transformations?
transformationCS
----------------
QVT 1.2 RTF Report Page 174 of 190
Object Management Group
RTF/FTF Report
ownedTag is not synthesized.
keyDeclListCS
-------------
Typo: wrong font in synthesized attributes
modelDeclCS
-----------
The [B] grammar:
modelDeclCS ::= modelIdCS ':' '

'
is missing.
keyDeclCS
---------
Synthesized attributes appear to have experienced a copy and paste error while providing distinct part
and oppositePart left hand sides.
keyPropertyCS
-------------
The synthesized attributes poke the parent.
Suggest: it would be clearer for the parent to gather and distribute children similar to the relation/query
allocation by transformationCS.
relationCS
----------
Transformation.extends does not appear to be transitive.
topQualifierCS
--------------
Suggest: a boolean or enumerated value rather than a string.
domainListCS
------------
Typo: missing indentation.
primitiveTypeDomainCS
---------------------
isCheckable, isEnforceable not synthesized.
objectTemplateCS
----------------
Variable needs to be added to relation to provide a container.
Variable needs to be added to relation environment to provide visibility.
collectionTemplateCS
--------------------
Variable needs to be added to relation to provide a container.
Variable needs to be added to relation environment to provide visibility.
Suggest: last two if guards are redundant.
QVT 1.2 RTF Report Page 175 of 190
Object Management Group
RTF/FTF Report
restCS
------
Variable needs to be added to relation to provide a container.
Non-_ named variable needs to be added to relation environment to provide visibility.
memberCS
--------
Variable needs to be added to relation to provide a container.
Non-_ named variable needs to be added to relation environment to provide visibility.
whenCS
------
predicateListCS should be optional.
whereCS
-------
predicateListCS should be optional.
ExtOclExpressionCS
------------------
This is not present in the QVTr or OCL grammar.
Presumably it represents the QVTr extension to OCL's OclExpressionCS.
However it is an extension, since at least RelationCallExpCS can be used in an ordinary
OclExpressionCS using "not" or "and".
[A], [B], [C] should therefore follow on from OCL's
[A], [B], [C]..., [I].
RelationCallExpressionCS
------------------------
How is a RelationCallExpressionCS distinguished from an OperationCallExpCS?

I’m having trouble with the semantics of DELETE on p. 189 of the QVT Specification (v1.1). It reads in part:

FORALL OBJVAR IN MAKESET(<DOMAIN_K_VARIABLE_SET>) (
…
AND BELONGSTO(OBJVAR, MAKESET(<DOMAIN_K_VARIABLE_SET>))

I guess I don’t understand MAKESET and BELONGSTO. First of all, <DOMAIN_K_VARIABLE_SET> is already a set, so what’s the MAKESET function do? Second, the FORALL iterates OBJVAR over the results of the same MAKESET that BELONGSTO tests. So how can BELONGSTO be false? That is, I would assume BELONGSTO is defined as follows:

BELONGSTO(e, S) º e ÎS

except that under this definition the expression above is always satisfied.

Any and all help appreciated. Thank you very much.

Current abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught.

That is, QVT1.1 is currently limited to the following style of try/catch logic:

try

except (Exception e)

;

or:

try

except (Exception1 e1, Exception2 e2)

;

Yes. Unuseable caught exceptions are clearly of limited utility.
There can only be one exception variable name for many exception types; what is its type? Cannot be
any of the listed types so it will have to be the common super type. Introduce a new exceptionVariable.
Of course the lower bound on the exception type should be 1. If a catch all is required then the type
can be Exception. If a finally is required then we need a wrapper or specification enhancement.

In the UML to rdbms transformation code given in section A.2.3 :

– mapping to update a Table with new columns of foreign keys
mapping Association::asso2table() : Table
when

{
init

foreignKey := self.map asso2ForeignKey();
column := result.foreignKey->column ;
}

The mapping asso2table is supposed to update a table by adding new columns, but with the last line of the mapping, the existing columns are all replaced by the new ones. I suggest to replace the last line with :
column += result.foreignKey->column ;

yes

You have reached the edge of the specification as written.

1: Yes
2: Yes
3: Yes
4: Yes

I gave some consideration to this for UMLX.

I felt that an abstract 'rule' could define a 'subrule' obligation, which would require an identical match signature, since if the override was narrower it would not fulfill the obligation and if it was wider the additional width would not be permitted by the invocation of the abstract 'rule'.

I felt that all concrete rules should always be matched to ensure that addition of extended functionality did not change previous behaviour. This complies with UMLX's all maximal matches philosophy. Keys in QVTr, Evolution Ids in UMLX can ensure that derived rules reuse inherited matches.

I think a transformation being both a package and a class introduces some difficult compatibility issues to be studied.

Transformation extension is also poorly defined giving additional imprecision when considering the combination of transformation extension and rule override.

My ideas for UMLX were not complete but I think that they may be sounder than QVTr's.

This issue was inadvertently raised from Issue 15417 correspondence. Close it as merged even though
Issue 15417 needs further work.
Disposition: See issue 15417 for disposition

I am confused by something in the MOF QVT specification (version 1.1) and am not sure if it’s an error or my own misunderstanding. Figure 7.3 (p. 24) has links from two instances of ObjectTemplateExp to a single instance of PropertyTemplateItem (the one in the middle). Figure 7.6 (p. 30) shows a composite association between ObjectTemplateExp and PropertyTemplateItem. Why then are there two links to the instance in Figure 7.3? Doesn’t a composite association mean that a PropertyTemplateItem can be owned by only one ObjectTemplateExp?

The problem is that UML Object diagrams omit the decorations from instantiated relationships. Shrt of
moving to a non-standard UMLX diagram, we can perhaps get away with some explanations.

Sometimes, it is useful to get the URI corresponding to the resource of a given transformation input model parameter.

I suggest adding an operation for this purpose in clause 8.3.5 Operations on models.

Model::getURI() : String

Returns the string of the URI corresponding to the model's resource. This operation produces an empty string for a model corresponding to an output parameter

For what it's worth, below is a patch for the Eclipse M2M implementation of QVTOperational where I prototyped such an operation.

No Data Available

Please provide a non-null text in the Scope section of documents ptc/09-12-06 and ptc/09-12-05

No Data Available

The resolution for Issue 11341 uses '.' as a property scoping operator.

This is inconsistent with OCL for which class scoping always uses '::' e.g
enumeration is class::literal operation call is class::operation.

Note the clarifying discussion in OCL, justifying Class.allInstances,
explains
that dot is only for operations on instances.

Simple correction of '.' to '::' in the grammar.

If I want to specify a uni-directional transformation using QVTr, is it ok to use "derived" properties in source domains' object templates? I guess since the transform is not meant to be run in the opposite direction, this will not create a problem?

If that is allowed, it would be a good additional feature of QVTr to allow the definition of new derived properties right in the transform, instead of having them only in the source metamodel.

For example

transform A (...) {

property Class::allSuperClass : Class

relation B {
checkonly domain source c:Class {
allSuperClass = super:Class

}
}

}

does this make sense?

No Data Available

The current specification of List has a vague claim that all OCL Collection operations are available.

Are iterations available?

Are Sequence operations and iterations not available?

Are return types adjusted to List?

The specification needs to provide a clear model defining all the operations and iterations.

Specifying the operations is straightforward, but highlights some nasty inconsistencies such as two
versions of insertAt.
The OCL 2.4 operations are included.
From Issue 13223 clarify wording of insertAt:
From Issue 13251 add remove operations.
A model must wait till OCL 2.5 provides an extensible library model

Problem:

Specification first says in the Constructor concept description:

"The name of the constructor is usually the name of the class to be
instantiated. However this is not mandatory. Giving distinct names allows having more than one constructor."

Later on in the Constructor notation:

"The name of the constructor is necessarily the name of the context type"

This is inconsistent.

Discussion:
Indeed, the notation section statement seems to be correct since:
1. Looks like other programming languages, like Java.
2. More importantly, the instantiation expression would not be so obvious when constructing new objects, and would required to be changed.

Example:

If we have the following constructors:

constructor MyClass::MyClassConstructor(name : String)

constructor MyClass::MyClass(name : String)

How can the instantiation expression refer the different constructor ?

• new MyClass("abc")
• new MyClassConstructor("abc")
• new MyClass::Constructor("abc")

The referred class in a InstantiationExp would not be enough. Changing instantiation expression to provide different name constructor doesn't seem sensible.

Proposed solution:

In section 8.2.1.13

Replace:

"A constructor does not declare result parameters. The name of the constructor is usually the name of the class to be
instantiated. However this is not mandatory. Giving distinct names allows having more than one constructor."

by

"A constructor does not declare result parameters and its name must be the name of the class to be instantiated."

This was discussed on https://bugs.eclipse.org/bugs/show_bug.cgi?id=421621.
Unless we abandon constructor diversity completely, the current AS imposes a needless
implementation difficulty by requiring dynamic resolution of a statically known constructor. This can be
avoided by augmenting InstantiationExp.instantiatedClass with
InstantiationExp.initializationOperation , which can refer to any statically determined constructor. We
can therefore relax the contradictory restrictions on constructor name spelling.
Unfortunately Constructor is not available in ImperativeOCL. Promoting Constructor to ImperativeOCL
would appear easy, unfortunately its superclass ImperativeOperation is also not available. Promoting
ImperativeOperation requires … too hard. So we must instead introduce InstantiationExp.
initializationOperation and redefine it in ObjectExp.

Clause 7.7 mandates fixed-point semantics for in-place transformations.

Please ask my bank to use a repeat-until-no-change in-place transformation for my next pay cheque:

new-balance = old-balance + deposit.

More seriously, the repeat is at the relation level, so if there are multiple applicable relations, the in-place result is specified to experience multiple updates in an indeterminate order. If relation A and then relation B are repeated to exhaustion, is relation A repeated again to accommodate relation B's changes?

Start again. QVTr and QVTc are declarative, therefore they express a single complex truth about the final outputs with respect to the original inputs. There are no observable intermediate steps. It is the responsibility of the transformation engine to ensure that the multiple actual output changes are observed as a single atomic transaction. In particular for in-place transformations, the engine must ensure that no input value is accessed after it is updated for output.

In regard to fixed-point semantics, repetition can only be determinate if it is the entire tranformation that is repeated, and whether to do so would seem to be a legitimate execution option. Therefore QVT should either not specify repetition at all, leaving it to the invoking engine, or specify it as an invocation option for a RelationCallExp.

If an in-place transformation does perform fixed-point repetition at the transformation level, it would seem that the whole repetition should still be a single atomic transaction so that outputs are never observable in an inconsistent partially transformed state between iterations. The engine must therefore iterate over candidate outputs rather than actual outputs.

Fixed point semantics can be achieved by a has-it-changed loop.

Section 8.2.1.22 ResolveExp states the following about the result type of a resolve expression:

"If no target variable is provided, the type is either Object (the type representing all types, see Section 8.3.1) either a Sequence of Objects - depending on the multiplicity."

On top of that, Section 8.2.1.23 ResolveInExp states:

"The type of a ResolveInExp expression is computed using the same rules as for the type of a ResolveExp."

In case of a ResolveInExp, why can't we obtain the result type from the respective mapping?

Consider the following example

mapping EClass :: EClass2EPackage() : EPackage

The result of any resolveIn expression for that mapping is necessarily a subtype of EPackage. No need to cast this up to Object.

OclAny rather Object is of course the top type

In contrast to 8.2.1.23 ResolveInExp, the prior section 8.2.1.22 ResolveExp does not explicitly state whether the source variable is optional for resolve expressions. For Eclipse QVTo, this leads to the situation the source variable is assumed to be mandatory. Consequently, the resolve expression in following snippet is invalid in Eclipse:

var p : EPackage = resolveone(EPackage);

I don't think that this restriction is desirable from the specification viewpoint.

Eclipse bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=392156

The resolve needs a domain in which to search for target objects. For ResolveInExp this can be the
traces of a designated mapping. For ResolveExp it would seem that some source objects must be
supplied. However there seems no reason to prohibit a search everywhere and this could be achieved
by specifying Element.allInstances(). Therefore an omitted ResolveExp sources can mean search all
traces.

A List is a mutable type. However, there is only an interface for adding to a List, not for removing from a List. Analogously to the operation

List(T)::add(T) : Void

there should be something like:

List(T)::remove(T) : Void

Duplicates in part Issue 13251.
Disposition: See issue 19146 for disposition

Problem:

ObjectExp enhances an InstationExp with additional abstract syntax and semantics what respect to the association of the object to be created/updated to a variable.

Likewise, the object expression provides concrete syntax to specify the set of expressions to be executed in order to intialize/update the properties of the object to be created. However this is not reflected in the abstract sytanx.

Discussion:
Indeed, ObjectExp should contain a containment reference to comprise the block of expressions used to initialize/update the object properties.

The best AS candidate is ConstructorBody. Note that this is supported by the own description of the ConstructorBody (section 8.2.1.18):

"A constructor body contains the implementation of a constructor operation or the implementation of an inline constructor
(see ObjectExp)."

This ConstructorBody should be optional, as a result of an enhancement I'll raise in a different issue.

Proposed resolution:

Add the following association to ObjectExp in section 8.2.1.24

body: ConstructorBody [0..1]

The object expression body comprising the expressions to initialize (or update) the properties of the object to be instantiated (or updated).

The required association is already shown in Fig 8.3; just need to add the missing text

In particular, this taxonomy should explicitly include the AssertionFailed exception type that clause 8.2.2.20 refers to for an AssertExp.
Suggest defining a String message attribute for Exception; this would facilitate retrieving the message from a raise expression (clause 8.2.2.15)
Suggest defining AssertionFailed as a subtype of Exception.
Suggest defining 2 attributes in AssertionFailed corresponding to the severity and log expressions of the AssertExp (clause 8.2.2.20)

Yes. We need a toxonomy.
At the root is clearly Exception and this needs no parameters.
We need to introduce a derived StringException for the standard string-valued RaiseExp, and oops we
need to modify the grammar to support this shorthand.
The LogExp-valued AssertionFailed is another derivation of Exception; no severity since it is always
fatal.

The QVT spec says that "an operational transformation may use for its definition intermediate classes and intermediate properties."

Is intermediate data actually restricted to plain transformations? In other words, is intermediate data unsupported for libraries? The eclipse QVTo implementation sticks to this interpretation and actually supports intermediate data only for plain transformations, which is a limitation I don't see a reason for.

No Data Available

Section 9-2 in the UML Profile for NIEM Beta2 document describes an interesting diagrammatic notation for describing the salient organization of a QVTO transformation.

Based on the notation shown in figures 9-2, 9-3, 9-4 and others, this notation clearly involves some kind of UML profile for describing a QVTO transformation whose stereotypes
include <<OperationalTransformation>>, <<MappingOperation>>, <<disjuncts>> and <<inherits>>. The figures in section 9 make a compelling illustration of the utility of a UML Profile for QVTO Transformation.
I believe this UML profile for QVTO is a novel contribution of the UML Profile for NIEM FTF; unfortunately, the document does not describe it and this QVTO Transformation profile
is not mentioned anywhere in the UML Profile for NIEM inventory or in any of the machine readable artifacts.

No Data Available

The proposed resolution for Issue 19178 'clarifies' nested exceptions.

It is wrong. The confusion arises from C++'s problem with a nested exception in a destructor not in a handler. QVTo has no destructors so there is no problem.

Issue 19178 should be closed without change.

Do not apply chnages from Issue 19178 resolution.

For ease of reference, the erroneous 19178 revised text was:
In 8.2.2.13 TryExp add
The selected exceptClause completes before the TryExp completes. Consequently if an exception is
raised during execution of the exceptClause, the execution of the exceptClause cannot complete and so
execution of the transformation terminates without any further changes occurring. The trace records
may be examined to determine what actions the transformation performed prior to termination.
We just need to make clear that the handling of nested exceptions is normal.

QVTo provides no guidance as to how a nested exception should be handled.

Suggest that like C++, a nested exception is ill-formed and the transformation terminates.

The QVTo exception mechanism is lightweight.
Throwing an exception while handling another makes it very difficult to guarantee that the handler for
the first executes correctly.
Therefore declare nested exceptions as ill-formed.

The asList() operation is defined for all concrete collection types. Consequently, it should be defined on List itself (returning self).

Suggestion: specify the operation for the Collection type:

Collection(T)::asList() : List(T)

Add another redefinition for the List type:

List(T)::asList() : List(T)

The additional operation is shown in the Issue 19146 resolution..
Disposition: See issue 19146 for disposition