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.

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.