8.1.8 has
column := self.attribute->new(a) Column(a.name,getSqlType(a.type));
Surely the (a) is a typo?
8.4.6 introduces a <<>> syntax with an example whereby <<id>> provides the UML isID identification. The syntax appears as part of a general <<IDENTIFIER,IDENTIFIER>> syntax so presumably there may be many idenientofioers not just the "id" special case. Surely the IDENTOFOER should at least be a qualified name to identify the package and surely "id" should be qualified to indicate that it is from a UML namespace and should be spelled in accordance with UML spelling?
QVT supports two styles of comment, single/multi-line each of which may precede/follow the commented syntax element. (A leading new-line distinguishes a preceding from a following comment).
The QVT AS inherits a Comment element from MOF with body and annotatedElement properties. This is inadequate to distinguish the two styles or the two positions. Could be fixed by a couple of Boolean properties.
Comments may also be applied to punctuation that has no corresponding model element.
if x then y
else // must have an else
z endif
Perhaps an annotatedText is necessary to allow a comment to refer to punctuation
<comment multiline="false" prefix="false" annotatedText="else" body="must have an else"/>
Might need an annotatedIndex too for the case where the annotatedText occurs multiple times.
Since the annotatedElement is already there, it might be less klunky to anchor the markup with annotatedElement="...z..." precedingText="else", where "...z..." is the appropriate fragment to reference the z element.
In the standard it is stated that all source variables of a relation must be bound, in order for the relation to be applied. This seems the only reasonable approach for relation application. However it has an interesting consequence in the case of *-multiplicity references r, or indeed for any reference r with multiplicity lower bound 0. The source domain in
top relation R
{ checkonly domain src e : E { r = rx : R {}, att = attvalue };
enforce domain trg f : F { rr = rrx : R1 {}, attf = attvalue };
}
will not match to an E instance x which has empty x.r, because rx cannot be bound to any element, and hence the relation R will not be applied to such x - and att will not be copied to attf.
In other cases (non-empty x.r), instances of E are copied to instances of F, and a specifier could expect that R copies x : E with empty x.r to a y : F with empty y.rr, but because of the totality requirement on source bindings, no y is produced for such x.
The QVT specification should alert specifiers to this issue, and that in such cases it would be necessary to split the above relation into two parts, one handling the mandatory features and other parts for each optional feature.
Note that this issue does not arise in languages such as QVT-O and ATL where copying of optional features can be done 'all at once' rather than element-by-element.
The descriptions regarding checkonly and enforce are incomplete and the examples are misleading.
When a domain is selected as a target, there are three execution possibilities.
The illegal state is never described, but is at the heart of a unidirectional transformation for which, as in RelToCore, the source-only domain has no checkonly/enforce and the target-only domain has enforce.
In contrast almost all of the UML2RDBMS examples have the uml domain marked as checkonly, which requires that an execution from RDBMS to check a pre-existing UML is permissible. This requires that the transformation is genuinely bidirectional although by using checkonly rather than enforce the programmer has unhelpfully prohibited the to-UML result from being persisted.
It is doubtful that checkonly has any value at all as a concrete syntax / abstract syntax annotation. Surely a plausible output domain is always enforce; it is the way in which the transformation is invoked that configures whether the enforce creates/replaces/updates/compares/checks... ? Perhaps it is the redundancy of checkonly that has led to the misunderstandings exemplified by the UML2RDBMS example that checkonly marks the input of a unidirectional relation.
Actions required:
In 7.11.3.8, RelationCallExp.argument has a lowerbound of 2 which seems sensible because surely any Relation must have at least an input and an output?
No. A single output non-top Relation is useful to create a singleton output object independent of any input objects. Distinct when invocations can establish singleton ownership in one place and usage in many places.
The lowerbound should therefore be 1.
The QVTr specification does not clarify if top relations can be called from where clauses. It would seem to be a source of potential errors if top relations were both explicitly invoked from where clauses and implicitly invoked by the usual mechanism for top relations. An explicit call R(a,b) of a top relation would normally be redundant because R would be attempted on the source element a in any case through the normal mechanism.
The clause should additionally state "Top level relations cannot be invoked from a where clause". As a consequence, primitive domains are only needed in non-top relations (clause 7.2.4 can state that primitive domains should only appear in non-top relations).
An <objectTemplate> may have an empty list of <propertyTemplate> but the surrounding {} are mandatory. Similarly a <collectionTemplate> may have an empty list of members but the surrounding {} are mandatory.
It is common for patterns to refer to properties / members by type and often name without caring about nested properties / members, but because of the syntax the user must contend with a confusing syntax error until the {} are added.
The user experience and patterns can be somewhat simpler if the {} can be omitted for empty content.
The fourth QVT14-59 comment identifies that Primitive Domain root variables are not useable.
A top primitive domain input is only useful if the specification provides a mechanism to pass configuration to these inputs. It doesn't, so top primitive domains seem useless as is, and perhaps better supported by contextual properties.
In https://bugs.eclipse.org/bugs/show_bug.cgi?id=548536 I thought a non-top primitive domain might be useful, but realized that the primitives were inputs in one direction and outputs in another violating the 7.2.4 restriction to inputs. Now that multiple root variables are permitted it seems that the primitive domain root variables should be moved to the appropriate domain so that they are directional. RelToCore does not use primitive domains. It appears that a genuine use case for a primitive domain with a root variable is lacking.
Suggest: Replace the unfullied potential paramerization of top relations by immutable contextual trasformation properties in similar style to QVTo.
Primitive domains are then reduced to the vague host domain of shared relation variables such as "name : String".
8.1.3.2 says
Each Extent for an in Model Parameter is immutable. It may be shared when the same external model is loaded by multiple in Model Parameters.
8.1.3.4 says
The roots of the forest have no containers, rather they are members of at most one Extent...
Clearly the elements of a common sub-model loaded by/referenced for two distinct Model Parameters are shared, else there could be confusing duplicates. These elements are in multiple extents contradicting the "at most on".
Suggest revise 8.1.3.4 to
The roots of the forest have no containers, rather they are members of typically one Extent... A shared root may be a member of mutiple Extents.
QVT13-26 requested support for collections of input models. This was resolved by generalizing the type of a ModelParameter to allow a Collection. This change was not necessary.
If each input model has a distinct Extent, there need be no prohibition on the passing of multiple Extents to a single TypedModel. By default this will be treated as a multi-rooted model.
In QVTr/QVTc where Extent is currently unused, reification of Extent as a transformable model element solves problems with providing a 'container' for multi-rooted models and allows collections of input/output models per TypedModel to be managed.
In QVTo, Extent can be similarly reified but care is required to separate the similar functionality of Model as the/one-of-the TypedModel instances.
In QVTo the a paremnt mapping may pull its child mappings by e.g.
result.children := self.children->map Child2Child();
QVTr has no counterpart to this. It is needed by those pursuing a procedural style with where clause sequencing. Relations such as RVarSetToMBVarSet in RelToCore demonstrate the need for a multi-invocation.
Since multi-directional usage prohibits the use of a result as in QVTo, suggest that a 1:1 relation invocation may be invoked to perform a N:N mapping by passing a collection where a non-collection was expected to at most one of the root variables of each domain.
QVTr (and QVTc) defines check and enforce modes with a check-before-enforce specified to suppress a redundant enforce. This seems sensible but is only possible for trivial cases. A relation/mapping defines constraints between objects that check mode can validate. But while checking before enforcing none of the intermediate and trace objects exist, so only trivial relations/mappings whose intermediate objects can be inferred can actually be checked. In the general case most of an enforce execution must be performed in order to create the intermediates. In practice, much simpler to specify a full enforce to an internal-output that can then be synchronized with the output-under-test. Successful synchronization determines the check success. If an internal-output is still available as a consequence of an earlier enforce, then a synchronize and check of yet another output-under-test can re-use the enforce. But check cannot be done without a prior enforce. For the trivial cases implementations may synthesize an optimized enforce/synchronize to improve check performance.
Given an enforced pattern such as:
a:A { b = b:B
{ c = c:C }}
there is an ambiguity as to whether the target of a.b is to be enforced remotely and then re-used here (checked) or enforced locally, so it is enforced locally.
This may perhaps be worked around using a Key, but the user must elaborate the pattern to redundantly define all the Key parts.
This may be worked around using a when pattern that relates "b" to its enforcement elsewhere.
Both the workarounds are tedious.
It is possible that there is some smart related to containment relationships that can do better, but more likely it just adds confusion and requires deeper user insight.
Suggest that remotely enforced PropertyTemplateItems can be annotated as checkonly to make the intent explicit.
a:A { checkonly b = b:B
{ c = c:C }}
An overriding relation may need to create nothing when the derived input pattern does not need transformation by the polymorphism. It might be transformed elsewhere explicitly. (Concrete example is OclType in the ATL metamodel which is defined as a derived OclExpression in ATL but not in OCL.)
Create nothing could be achieved by omitting the engforced domain but that violates a consistent overrideing domains WFR.
Create nothing is more sensibly achieved by no output patterns in the enforced domain,
The semantics of Keys wrt to derived types is unspecified and as discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=512532 far from obvious.
What are the WFRs for Keys?
Are multiple keys per type allowed?
Is key uniqueness applicable to derived types? or does each key have an implicit, distinct derived key for each derived and miltiply-derived type?
Can a realized access of a Keyed variable return a differenr class that shares the same key?
The soundness of QVTr relies on the fallacy that the Rel2Core transformation fully defines the QVTr semantics in terms of the fully defined QVTc semantics. The QVTc semantics are unfortunately not fully defined and the semantic errors in Rel2Core demonstrate that it can never have been exercised. When Rel2Core is consulted to determine the semantics of collection templates or relation overrides or .... oops. Missing.
I have been trying to prototype a viable QVTr2QVTc as part of the Eclipse QVTd project and solved most of the problems, but...
It is not sensible to transform a hierarchy of non-top overriding relations into QVTc since the need to partition each overriding relation into a pair of unfailing predicate matching and residual execution mappings is unreasonably hard using the very unhelpful ObjectTemplateExp+VariableExp+Variable pattern 'node's. A more sensible graphical PatternNode representation is necessary for readability and sanity.
Suggest that a graphical QVTg representation be introduced so that QVTc and QVTr are defined by more realistic QVTc2QVTg and QVTr2QVTg transformations. Bypassing QVTc should avoid the need for QVTr2QVTc to provide an heroic workaround for every QVTc limitation.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=529130 for more discussion.
Model copy is a potentially well-defined behavior that can have a useful default implicit functionality.
QVTr and QVTc have no copy.
QVTo has a deep copy but since it is a library operation it is not part of the language and so it has no associated traceability. A first class copy is needed. See ICMT 2017: Christopher Gerking, David Schubert and Ingo Budde: Reducing the Verbosity of Imperative Model Refinements by using General-Purpose Language Facilities.
UML supports templated types.
OCL is aligned with UML.
QVT extends OCL.
Therefore QVT supports templated types possibly just through grammar inheritance.
For relations, that have some similarities to operations, a template signature is required in order to allow a user to bind a specific enforced type. In the absence of templates, a relation defined on the template parameter lowerbound can only enforce the lowerbound.
QVTr imposes an unnatural declaration order in the exposition of a RelationCS. Surely the when clause should be early and variable declarations where initializeable?
Suggest relaxing the ordering constraint on declarations in a RelationCS to permit the more readable order
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.
Rule::overrides specifies the Rule that this Rule overrides; no problem.
The remote Rule is overridden by this rule.
But the opposite of Rule::overrides is called overidden.Wrong way round, It should be called overriding. Rule::overriding navigates to the (many) Rules that override (not are overridden by) this Rule.
If a variable has an invalid value and that variable is used by passing it to log(), it should not cause an assertion failure on the use of invalid.
QVT 1.3 removed the artificial restriction on 1 root variable per QVTr domain, but neglected to provide the elaboration for multiple roots per primitive domain. THis is needed to pass 2 parameters to a relation as is required by draft OWL <-> UML transformations.
Suggest allowing a comma-separated list of roots.
Issue 18572 highlighted that QVT 1.1 seemed to require inconsistent fixed-point semantics. The resolution solved the inconsistency by requiring repeated execution to be external to QVT.
However some transformations such as the TTC PetriNet to StateChart require repeated transforming.
If QVTr supported the TypedModel::uses property then an endogeneous transformation whose input TypedModel uses its output TypedModel makes the repeated execution for fixed-point semantics consistent.
Need to update 7.7/add a fixed-point semantics section.
Need to add TypedModel::uses to the QVTr concrete syntax.
It is unclear how multiple mappings may conspire to populate the children property of a parent. Is the final truth of
parent.children := aChild
parent.children = Collection
{aChild}or parent.children->includes(aChild)
Suggest the latter, since the former can easily be programmed explicitly. This avoids the need to re-interpret a clarifying includes predicate as a partial assignment.
8.4.7 defines a "%" mult_op but no accompanying specification.
The disambiguation comment in 8.4.4 suggests a dual semantic, format half-specified, modulo is presumably Integer/UnlimitedNatural::mod
8.4.4 4 defines
The notation “blabla %s\n” % myvar involving the binary '%' operator is a shortand for invoking the pre-defined 'format' operation.
The inconsistent punctuation and lack of the longhand '"blabla %s\n".format(myvar)' makes for a hard read; which % is the shorthand?
This really does not seem very useful. The textual saving is small, it only works for single argument formats, it introduces precedence challenges once the missing precedence is specified.
(Eclipse QVTo does not implement the shorthand.)
Suggest delete the shorthand.
The "The potential ambiguity with the modulo operator is solved thanks to the type of the first argument, which is a string in our case." text implies that either QVTo or OCL provides a modulo operator. OCL <= 2.4 does not. QVTo's grammar defines '% as a mult_op, perhaps just as the format shorthand, there are certainly no defined semantics such as what data types are applicable, how zero is accommodated.
(Eclipse QVTo does not provide any % operator.)
Suggest, delete the confusing sentence.
ODM 1.0 uses a CollectionTemplate extension in which a collection comprehension is used to match Sequence content:
checkonly domain uml assn : Association{general = superassn : Association{
memberEnd = supSeq : Sequence(Property){usuper | true}},
memberEnd = subSeq : Sequence(Property){uprop | true}}
; // steps through both sequences in tandem
It is not clear how to achieve this without a CollectionTemnplate iterator.
The proposal for a co-iterator could avoid the guard and so allow
checkonly domain uml assn : Association{general = superassn : Association{
memberEnd = supSeq : Sequence(Property){usuper,index | true}},
memberEnd = subSeq : Sequence(Property){uprop,index | true}};
If a CollectIonTemplate is for an OrderedCollection e.g. in
elements = oSet:OrderedSet
{m1, m2 ++ rest}the literal could be ordered requiring m1 first, m2 next etc. But this inhibits the useful use case of iteration over the Collection unless we extend to:
elements = oSet:OrderedSet
{mBefore ++ m1, m2 ++ mAfter}Alternatively if 'Ordered' is just ignored, we create a disordered OrderedSet.
The exception raising syntax is a bit of a mess, cherry-picking special syntaxes and thereby inhibiting general functionality such as raising a computed exception. It is therefore not possible to re-raise an exception.
QVTo has stereotypedBy and stereotypedStrictlyBy helpers and a * shortform to assist in the use of stereotypes, but seemingly only for read purposes.
QVTc and QVTr have no overt support for stereotypes.
Document why it isn't necessary.
QVTo's myClass.stereotypedBy(MyStereotype) invocation is actually just the myClass.extension_MyStereotype <> null predicate. QVTc and QVTr can therefore support stereotypes using normal navigation. And as declarative transformation languages a stereotype navigation in the target domain is a stereotype assignment.
QVTo should support stereotype assignment by:
myClass.extension_MyStereotype := ...
Just need an OclElement.allExtensions() helper to support reasoning on the actual steotypes without knowing which ones to 'poll'.
8.4.4. bullet 6 says both available.
Following bullet 8 it says only one or the other available.
An OCL Variable requires its initializer to be statically type conformant to its type.
A QVTc/QVTd (Guard)Variable defers conformance checking till run-time at which point a non-conformance is a predicate failure.
There is therefore a problem with the WFR inherited from OCL.
Suggest:
VariableDeclaration should be the basis for Variable references.
RealizedVariable should be a VariableDeclaration, not a Variable.
GuardVariable should be a new derivation of VariableDeclaration.
NB VariableDeclaration is the common supertype of Variable and Parameter, although VariableDeclaration is seriously underspecified by OCL.
The introduction to 10 concludes
"and finally, the application of this transformation to the familiar object to relational transformation is shown to demonstrate the results"
But the Section ends without this application. The QVTc variant of UML2RDBMS is not this application in a different place since the QVTc exposition does not follow the multi-unidirectional conversion style of RelToCore.
QVT 1.1 introduced an opposite syntax to support inverse navigation. e.g.
in 7.3 "opposite(Class.attribute)".
This is not needed since the OCL implicit opposite role name supports "Class" when there is no ambiguity, and "Class[attribute]" when an ambiguity needs resolution.
The OCL syntax is shorter and reads forwards, unlike the redundant opposite syntax. Suggest deprecation.
8.4.4 at the end has
use-traditional-comparison-sysntax
where surely
use-traditional-comparison-syntax
was intended.
8.4.7 defines a "!->" access_op but there is no accompanying specifucation.
OCL provides two under-specified semantics for the [] indexing operator
qualifiedAssociationName[qualifierList]
ambiguousAssociationName[oppositeAssociationName]
QVTo introduces additional internally and externally ambiguous semantics without any disambiguation specification.
The following shorthands are missing from 8.4.5
anExpression[aTypeExp]
anExpression[anotherExpression]
!
!->
An entire Module may be declared as blackbox using the isBlackbox attribute. Whereas it is obvious that a blackbox transformation consists of its signature only (name + model parameters) as it doesn't include any operations, what is a blackbox library? If it doesn't include operations as well, it is useless because it has no effective signature.
If the isBlackbox attribute is useful for transformations only, should it be moved from Module to OperationalTransformation?
The RelToCore transformation that 'defines' QVTr semantics has no semantics for Collections, either explicit through use of CollectionTemplateExp or implicit through use of Collection/non-Collection assignment conversion.
8.4.5 2 states "if a collection value is passed there is an implicit comparison with the size of the collection."
This is clearly not the intent: no Collection can ever equal its size.
Presumably the intent is to treat if (aCollection) as a shorthand for if (aCollection->notEmpty()).
Suggest that all shorthands are spelled out explicitly in longhand.
QVTo has one form of mapping overloading provided by disjuncts. This is poorly specified.
It probably has another provided by name collision. This is unspecified.
What are the QVTo mapping overloading semantics?
QVTo has one form of mapping overloading provided by disjuncts. This is poorly specified.
It probably has another provided by name collision. This is unspecified.
The <rulerefs> between mappings has no defined semantics.
Presumably:
<package-name>*::<transformation-name>::<context-type>::<mapping-name>
allowing <package-name>*::<transformation-name> to be omitted defauklting to the current transdformation, and, preserving the current example semantics, resolving an omitted <context-type> by serching all mapping names in the transformation.
Undefined rulerefs
The <rulerefs> between mappings has no defined semantics.
Presumably:
<package-name>*::<transformation-name>::<context-type>::<mapping-name>
allowing <package-name>*::<transformation-name> to be omitted defauklting to the current transdformation, and, preserving the current example semantics, resolving an omitted <context-type> by serching all mapping names in the transformation.
Issue Links
Discussion
Since <mapping_id> needs definition, we can take the opportunity to rename the strange <rulerefs>.
8.2.2.10 VariableInitExp says
A variable may not declare an initialization value.
when surely it means
A variable may omit an initialization value.
Unfortunate VariableInitExp wording for missing initializer
8.2.2.10 VariableInitExp says
A variable may not declare an initialization value.
when surely it means
A variable may omit an initialization value.
The return type of xselectOne, xcollectselectOne returns a SEquence rather than an optional value.
xselectOne, xcollectselectOne is Sequence of One not One
The return type of xselectOne, xcollectselectOne returns a Sequence rather than an optional value.
Discussion
QVT13-34 revealed numerous errors in the pseudocode. This error is just one of many fixed by its resolution.
"A compound assignment is equivalent to perform as much simple assignments as there are expressions. Null values are skipped."
This is poor English and it conflicts with the OCL specification.
Pedantically it only skips "Null" values so "null values" are allowed anyway.
"An assignment may receive a future variable produced by a deferred resolve expression (see ResolveExp). The effect is equivalent to receive a null value except that a side-effect action occurs in order to allow re-executing the assignment at the end of the transformation.
An assignment expression returns the assigned value unless it is a future value, in which case null is returned."
This is barely intelligible and presumably related to the SmartQVT implementation. It certainly has confusion about nulls.
I recommend following OCL and allowing null values. ->excluding(null) is easily added.
Conflicting exclusion of null during assign
"A compound assignment is equivalent to perform as much simple assignments as there are expressions. Null values are skipped."
This is poor English and it conflicts with the OCL specification.
Pedantically it only skips "Null" values so "null values" are allowed anyway.
"An assignment may receive a future variable produced by a deferred resolve expression (see ResolveExp). The effect is equivalent to receive a null value except that a side-effect action occurs in order to allow re-executing the assignment at the end of the transformation.
An assignment expression returns the assigned value unless it is a future value, in which case null is returned."
This is barely intelligible and presumably related to the SmartQVT implementation. It certainly has confusion about nulls.
I recommend following OCL and allowing null values. ->excluding(null) is easily added.
Issue 19238
AssignExp to an Collection should make clear that the results is
target->including(source)->excluding(null)
Issue 19687
The two examples
mymultivaluedproperty += object Node
{ }; // additive semantics; // the list is reset and re-assigned
are simple assignments from single valued RHS. These are not covered in the preceding description.
I consider both to be errors since the RHS is unsuitable for assignment to the LHS. In both cases an asSet() or whatever should be appended.
More generally, the library operation that exhibits the "additive semantics" should be clearly identified.
Since addition to OCL collections is not permissible, it may be necessary to define constructors, so that
var c : Set(String) := Set
{"a"};
invokes the Set(T)(Set(T)) constructor.
This would allow initialization for a Sequence from a List and vice-versa that is otherwise magic.
which should exploit an OCL definition of OrderedSet::including to be add at end if necessary.
Discussion - nulls
UML does not allow nulls in multi-values, therefore nulls must be excluded during assignments to properties.
OCL does allow nulls, and even though this may appear to be a mistake, QVTo must support nulls in OCL collections until OCL is changed.
Discussion - multiple values
The current wording leaves open the design choice between:
a) perfect fidelity of nested types, i.e. addition of a Collection of Collections adds the one Collection of Collection element
b) perfect flattening, i.e. addition of a Collection of Collections adds all the elements in the nested collections.
c) something in between, perhaps behaving differently depending whether the LHS is a nested collection or not,
OCL unfortunately started without nested collections so that imploicit-collect flattens requiring the explicit collectNested for perfect Collection type fidelity. a) is not really an option. c) risks a confusing anarchy. b) is what is often wanted. If users want nested collections they can use more explicit operations.
Discussion - future values
Premature access to yet-to-be initialized values is obviously bad. Making this an error is an option, but it would be a breaking change; there may be users who poll the variable awaiting initialization. Simplest to just clarify the words to indicate that the value of any yet-to-be-initialized value is null, even when null is not assignable to the value. It is not initialized to null; it is null until initialized.
For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit.
The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit).
Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports.
Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior.
Unspecified handling of imports without access/extends
For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit.
The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit).
Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports.
Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior.
Discussion
Following some off-JIRA correspondence, the original issue is clearer and simpler.
The 8.2.1.4 words say that ImportKind has only two possibilities. But the words and model omit a [1] multiplicity or defaultValue so that null is a third possibility. The grammar also permits a missing ImportKind.
So as suggested we could introduce a third null semantics, or define one of access/extends as the default.
I see no benefit in a third semantics.
"extends" is a very serious mutating activity, not a default.
"access" is harmless and non-mutating. Hardly AST clutter. If the user didn't want the names the user should not have specified an import.
Let "access" be the default.
Clause 8.1.14 uses "mylist.add(5);" rather than "mylist->add(5);
and "mydict.put"
Incorrect navigation operator for LIst operations
Clause 8.1.14 uses "mylist.add(5);" rather than "mylist->add(5); and "mydict.put"
The objectsOf...(T) family of operations (e.g. Element::subobjectsOfKind(T), or Element::allSubobjectsOfType(T), or Model::objectsOfType(T)) returns a set of Elements.
It should be possible to infer the precise return type from the given T, i.e., return a Set(T) instead of Set(Element).
BTW, why is there no Model::objectsOfKind(T) ?
Define return type for objectsOf...(T) operations more precisely
The objectsOf...(T) family of operations (e.g. Element::subobjectsOfKind(T), or Element::allSubobjectsOfType(T), or Model::objectsOfType(T)) returns a set of Elements.
It should be possible to infer the precise return type from the given T, i.e., return a Set(T) instead of Set(Element).
BTW, why is there no Model::objectsOfKind(T) ?
Discussion
We can make the declaraions using the same approximation to a rigorous declaration as used by selectByKind in OCL 2.4.
Omission of objectsOfKInd is an easily corrected oversight.
The incorrect objectsOfKind usage by the current objectsOfType is a confusing error that gets worse when the correct operation is provided. Better to correct it.
clone and deepClone from QVT13-12 can similarly exploit a T.
The confusing wording of Model::createEmptyModel can be clarified,
The prohibition on creation or update of instances in helpers has no justification. Why?
Allow object creation in helpers
The prohibition on creation or update of instances in helpers has no justification. Why?
Discussion
This came up while clarifying wording for QVT13-33.
The prohibition is presumably intended to ensure that all object creation has a corresponding trace record. A good idea but beyond the pragmatic integrity of QVTo. Untraced objects can be created in mappings anyway, so prohibiting their creation in helpers is just an unhelpful restriction on programming flexibility.
There is currently no way for an overriding operation to call its overridden super implementation. ImperativeOCL should provide something similar to the 'super' reference which is available in Java.
Calling the super implementation of an overriding operation
There is currently no way for an overriding operation to call its overridden super implementation. ImperativeOCL should provide something similar to the 'super' reference which is available in Java.
Discussion
QVT13-93 clarifies the concept of a mapping identifier. An arbitrary mapping may therefore be called:
self.map My::Tx::Your::Type::doIt(withSomething);
The following helper from the specification is a NOP, because List::append has no side effect in QVT 1.2.
helper Package::computeCandidates(inout list:List) : List
{ if (self.nothingToAdd()) return list; list.append(self.retrieveCandidates()); return list; }Therefore the snippet should rather use List::add.
Incorrect use of side-effect free append in example
The following helper from the specification is a NOP, because List::append has no side effect in QVT 1.2.
helper Package::computeCandidates(inout list:List) : List
{ if (self.nothingToAdd()) return list; list.append(self.retrieveCandidates()); return list; }Therefore the snippet should rather use List::add.
Discussion
Yes
The "import" feature of Relations Language is not yet explained. And there is no example for it, too. For instance what does the "unit" in "import <unit>;" mean ?
Section: 7.13.5
The "import" feature of Relations Language is not yet explained. And there is no example for it, too. For instance what does the "unit" in "import <unit>;" mean ?
OCL's allInstances() applies to the one and only immutable model extent.
The meaning of this in QVT with multiple, some mutable, extents/domains/typedModels is unclear.
Suggest that allInstances applies to all the input and original inout extents only.
Obtaining instances from other domains is available through alternate library operations such as objectsOfType in QVTo.
allInstances() needs clarification
OCL's allInstances() applies to the one and only immutable model extent.
The meaning of this in QVT with multiple, some mutable, extents/domains/typedModels is unclear.
Suggest that allInstances applies to all the input and original inout extents only.
Obtaining instances from other domains is available through alternate library operations such as objectsOfType in QVTo.
Discussion - QVTo
allInstances() could be defined to apply to the initial, prevailing or final state. Since a QVTo execution proceeds through a predictable sequence of states limiting allInstances() to the initial state is unhelpful. A limitation to the final state is almost unuseable and may require a tool to introduce another form of late processing. Therefore the prevailing state is most appropriate for a QVTo allInstances().The returned instances are the mutable instances since any form of caching would impose an unjustified overhead.
Discussion - QVTr/QVTc
allInstances() could be defined to apply to the initial, prevailing or final state. The initial state is easy. The prevailing state does not exist declaratively. The final state is harder but may be useful for computing derived output values based on the outputs.
However consider a cascade of endogeneous transformations A2B, B2C, C2D in which B2C performs an allInstances(). If we now compose the trio into A2B2C2D, the functionality of the allInstances() must not change. Therefore neither initial nor final state will do, since the initial state changes from B to A and the final state from C to D. We must use a prevailing state, which we can define as the final state of the domain in which the invocation of allInstances() occurs. For our example this is one of B or C and does not change as a consequence of the cascade.
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.
Initializing variables at the point of declaration is generally recognized as good practice. QVTc does not support it.
Suggest extend the (Realized) Variable syntax to support an initializer.
Allow QVTc to use initialized variables
Initializing variables at the point of declaration is generally recognized as good practice. QVTc does not support it.
Suggest extend the (Realized) Variable syntax to support an initializer.
Discussion
Initializing RealizedVariables makes no sense, since a RealizedVariable is initialized by the new Type().
Initializing (Unrealized)Variables is however useful and supported by the Abstract Syntax already; just need some Concrete Syntax re-using the := of an Assignment.
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.
QVTr does not allow variables to be initialized at the point of declaration. This is a rather prehistoric limitation that significantly degrades readability.
a) it requires separate declaration and assignment lines
b) it inhibits inference of the variable type from the initializer
c) it obfuscates the variable assignment
The latter is a particular problem in QVTr where the assignment may a consequence of a pattern match;
Suggest allowing an initializer on a VarDeclarationCS and allowing the type to be inferred from the initializer.
QVTr Variable Initialization
QVTr does not allow variables to be initialized at the point of declaration. This is a rather prehistoric limitation that significantly degrades readability.
a) it requires separate declaration and assignment lines
b) it inhibits inference of the variable type from the initializer
c) it obfuscates the variable assignment
The latter is a particular problem in QVTr where the assignment may a consequence of a pattern match;
Suggest allowing an initializer on a VarDeclarationCS and allowing the type to be inferred from the initializer.
Discussion
The underlying Abstract Syntax supports an initializer.
Prototyping in Eclipse QVTr demonstrated a useful reduction in line count and increase in clarity of the RelToCore transformation.
The QVTr AS allows CollectionTemplateExp::rest to be null corresponding to a precisely enumerated list of collection members to be matched.
The QVTr CS does not support this.
Suggest changing the
'++' (restIdentifier=[pivot::Variable|UnrestrictedName] | '_')
sub-parsing rule to
('++' (restIdentifier=[pivot::Variable|UnrestrictedName] | '_'))?
Exact QVTr Collection match
The QVTr AS allows CollectionTemplateExp::rest to be null corresponding to a precisely enumerated list of collection members to be matched.
The QVTr CS does not support this.
Suggest changing the
'++' (restIdentifier=[pivot::Variable|UnrestrictedName] | '_')
sub-parsing rule to
('++' (restIdentifier=[pivot::Variable|UnrestrictedName] | '_'))?
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 two examples
mymultivaluedproperty += object Node
{ }; // additive semantics; // the list is reset and re-assigned
are simple assignments from single valued RHS. These are not covered in the preceding description.
I consider both to be errors since the RHS is unsuitable for assignment to the LHS. In both cases an asSet() or whatever should be appended.
More generally, the library operation that exhibits the "additive semantics" should be clearly identified.
Since addition to OCL collections is not permissible, it may be necessary to define constructors, so that
var c : Set(String) := Set
{"a"};
invokes the Set(T)(Set(T)) constructor.
This would allow initialization for a Sequence from a List and vice-versa that is otherwise magic.
Unclear multi-valued initialisation from single value
The two examples
mymultivaluedproperty += object Node
{ }; // additive semantics; // the list is reset and re-assigned
are simple assignments from single valued RHS. These are not covered in the preceding description.
I consider both to be errors since the RHS is unsuitable for assignment to the LHS. In both cases an asSet() or whatever should be appended.
More generally, the library operation that exhibits the "additive semantics" should be clearly identified.
Since addition to OCL collections is not permissible, it may be necessary to define constructors, so that
var c : Set(String) := Set
{"a"};
invokes the Set(T)(Set(T)) constructor.
This would allow initialization for a Sequence from a List and vice-versa that is otherwise magic.
Issue Links
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.
As interpretated from the especification (pag 104), the way of adding new operations to OCL predefined types is creating new Typedef instances
which must have the OCL predefined type as the base type. The new operations are added to this new typedef. However there are several problems:
1. The specification doesn't provide any name for these typedefs.
2. The specification doesn't specify which type (QVT typedef or OCL predefined type) should be used when referencing such OCL predefined types in a QVTo transformation.
Solution for 1).
Suggestion a: Name the typedef with the same name of the base type. This provokes name's clash with the predefined type's name, due to there are two different types from two standard libraries
which have the same name. A possible solution, would be expliciting that typedefs (aliases) will never clash its name with its base type.
Suggestion b: Name the tpyedef with a different name, such as QVToXXXXXX or XXXX_Alias.
Solution for 2).
Suggestion a: Taking the typedef as the referenced type in QVTo transformations.
Suggestion b: Taking the OCL predefined type as the referenced type in QVTo transformations.
Suggestion c: Considering resolution of issue 13168, so that only OCL predefined exists, and therefore, the only type which can be referenced.
It's a little bit weird having 2 different types (a type, and its alias typedef) which represent just the same type, specially when they are related by a reference.
My solution's preference in order are:
Suggestion c: Just having one type to refer.
Suggestion a: Since the typedef "extends" the behaviour of the predefined type (adding new operations), the former must be the referred one.
Suggestion b: The OCL predefined type is referenced, but we must take into account that the operations added to the typedef are also available.
QVTo Standard Library and typedefs Issue. Extending OCL predefined types
As interpretated from the especification (pag 104), the way of adding new operations to OCL predefined types is creating new Typedef instances
which must have the OCL predefined type as the base type. The new operations are added to this new typedef. However there are several problems:
1. The specification doesn't provide any name for these typedefs.
2. The specification doesn't specify which type (QVT typedef or OCL predefined type) should be used when referencing such OCL predefined types in a QVTo transformation.
Solution for 1).
Suggestion a: Name the typedef with the same name of the base type. This provokes name's clash with the predefined type's name, due to there are two different types from two standard libraries
which have the same name. A possible solution, would be expliciting that typedefs (aliases) will never clash its name with its base type.
Suggestion b: Name the tpyedef with a different name, such as QVToXXXXXX or XXXX_Alias.
Solution for 2).
Suggestion a: Taking the typedef as the referenced type in QVTo transformations.
Suggestion b: Taking the OCL predefined type as the referenced type in QVTo transformations.
Suggestion c: Considering resolution of issue 13168, so that only OCL predefined exists, and therefore, the only type which can be referenced.
It's a little bit weird having 2 different types (a type, and its alias typedef) which represent just the same type, specially when they are related by a reference.
My solution's preference in order are:
Suggestion c: Just having one type to refer.
Suggestion a: Since the typedef "extends" the behaviour of the predefined type (adding new operations), the former must be the referred one.
Suggestion b: The OCL predefined type is referenced, but we must take into account that the operations added to the typedef are also available.
Discussion
The offending sentence is:
This is specifically used in the QVT standard library to attach operations to pre-defined primitive types, like String and Collections.
This facility is not used anywhere in the specification and there is no grammar that facilitates it. No model of the QVTo library is provided that exploits it. The sentence is therefore just an observation on a particular implementation approach.
The approach takes no account of the very similar requirement for Complete OCL to extend types. This is being resolved by work towards OCL 2.5 / 3.0 with which QVTo will almost certainly have to comply.
Therefore, tomorrow this sentence will be embarassing and incompatible. Today it is just irrelevant and confusing.
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.
Concerning to Relations Language, how will the metamodels get into a transformation script ? Is there a technique similar to Operational Mappings using metamodel declaration and modeltypes ? The RL sample transformation script in annex A.1 (pp 164) doesn't declare the metamodels. The OM sample (A.2.3) does. There is some syntax for declaring and using metamodels and modeltypes in OM (pp118), there isn't for RL (pp38).
Relations Language: how will metamodels get into a transformation scrip
Concerning to Relations Language, how will the metamodels get into a transformation script ? Is there a technique similar to Operational Mappings using metamodel declaration and modeltypes ? The RL sample transformation script in annex A.1 (pp 164) doesn't declare the metamodels. The OM sample (A.2.3) does. There is some syntax for declaring and using metamodels and modeltypes in OM (pp118), there isn't for RL (pp38).
Discussion
We needs to support definition of e.g. UML in
transformation umlToRdbms(uml:UML, rdbms:RDBMS)
But we actually may want to reference a document URI or namespace URI
http://www.omg.org/spec/UML/20131001/UML.xmi http://www.omg.org/spec/UML/20131001
But the current syntax is essentially a Java import without the trailing * option.
import my.model.package;
It cannot reference URIs and it has the wrong separator.
Something similar to QVTo's ModelType is needed:
modeltype UML uses SimpleUml ("http://omg.qvt-examples.SimpleUml");
However ModelType has many problems that we do not need to replicate:
Conversely Complrete OCL has a requirement for an import too, and here ModelType's are not appropriate at all.
Let's fix up import.
top relation AssocToFKey { pKey : Key; ... when
{ ...; pKey = destTbl.key; }... } In my opinion that doesn't work. pKey is of type Key, destTbl.key is of type OrderedSet key, isn't it ?
Section: A1.1.1
top relation AssocToFKey { pKey : Key; ... when
{ ...; pKey = destTbl.key; }... } In my opinion that doesn't work. pKey is of type Key, destTbl.key is of type OrderedSet key, isn't it ?
Discussion
Yes. Well at least it's a Collection; the diagram leaves an ambiguity.
Comparison with the QVTc solution shows that the 'primary' key should be selected, and initialized on creation.
Loading the example in the Eclipse QVTr editor reveals many more problems.
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
The syntax of identifiers is undefined.
The syntax for mapping clearly prohibits the use of a direction named 'where'.
Suggest: identifier is an OCL simpleName, less the new reserved words (check default enforce
imports map realize refines transformation uses where)
Suggest: a string-literal may be used as an identifier to support awkward identifiers such as 'where'.
Identifiers
The syntax of identifiers is undefined.
The syntax for mapping clearly prohibits the use of a direction named 'where'.
Suggest: identifier is an OCL simpleName, less the new reserved words (check default enforce
imports map realize refines transformation uses where)
Suggest: a string-literal may be used as an identifier to support awkward identifiers such as 'where'.
Discussion
OCL 2.3/2.4 clarified identifiers and strings so we can just exploit the OCL productions including it's underscore-prefixed-string identifier.
OCL 2.3 also introduced String::_'+' so no special description is needed for a QVTr extension.
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.
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.
The Helper class in the AS syntax supports both helpers and queries.
These two concepts have important distinctions that are poorly differentiated in 8.2.1.12, where as a minimum the two italicized terms 'helper' and 'query' should be used when defining the semantics of each.
Presumably a 'query' cannot modify anything (other than the log file) anywhere.
Presumably a 'helper' can modify anything anywhere, except of course sets and tuples that are always immutable.
The current wording suggests that a 'helper' can modify sets and tuples but cannot modify objects or create objects. Surely a 'helper' cannot modify sets or tuples but can create or update objects?
Inadequate helper/query distinction
The Helper class in the AS syntax supports both helpers and queries.
These two concepts have important distinctions that are poorly differentiated in 8.2.1.12, where as a minimum the two italicized terms 'helper' and 'query' should be used when defining the semantics of each.
Presumably a 'query' cannot modify anything (other than the log file) anywhere.
Presumably a 'helper' can modify anything anywhere, except of course sets and tuples that are always immutable.
The current wording suggests that a 'helper' can modify sets and tuples but cannot modify objects or create objects. Surely a 'helper' cannot modify sets or tuples but can create or update objects?
OCL defines invalid as the result of a failed evaluation. The QVT specification is almost totally silent on invalid, except for a few library operations that may generate it.
Presumably an invalid not 'caught' by oclIsInvalid/oclIsUndefined in QVTo causes a to-be-specifued exception to be raised in the problem statement.
Presumably an invalid not 'caught' by oclIsInvalid/oclIsUndefined in QVTc/QVTr inhibits the detection of matches.
invalid in QVT
OCL defines invalid as the result of a failed evaluation. The QVT specification is almost totally silent on invalid, except for a few library operations that may generate it.
Presumably an invalid not 'caught' by oclIsInvalid/oclIsUndefined in QVTo causes a to-be-specifued exception to be raised in the problem statement.
Presumably an invalid not 'caught' by oclIsInvalid/oclIsUndefined in QVTc/QVTr inhibits the detection of matches.
Discussion
But invalid may be temporarily caught by a let variable of QVTo var. It is the use that is a problem.
The current phrasing
Within a contextual operation <it>result</it> represents the unique result parameter (if there is a unique declared result) or the
tuple containing the list of declared result parameters.
suggests that the synthetic Tuple return is accessible as result. This is not necessary and imposes considerable implementation difficulties since a new Tuple would need creation with each mutation.
Sucggest the new wording.
Within a contextual operation for which no name is specified for a single return parameter, <it>result</it> is the implicit name of the parameter. If the name is specified explicitly, as is necessary for multiple returns, no pre-defined <it>result</it> variable exists.
Clarify availability of 'result' for Tuple returns
The current phrasing
Within a contextual operation result represents the unique result parameter (if there is a unique declared result) or the
tuple containing the list of declared result parameters.
suggests that the synthetic Tuple return is accessible as result. This is not necessary and imposes considerable implementation difficulties since a new Tuple would need creation with each mutation.
Suggest the new wording.
Within a contextual operation for which no name is specified for a single return parameter, result is the implicit name of the parameter. If the name is specified explicitly, as is necessary for multiple returns, no pre-defined result variable exists.
Discussion
Yes
The QVTr AS and CS permit only a single pattern to be matched in the input (and output) domains. QVTc permits multi-matches.
This can be worked around with nested collections as demonstrated by RDomainToMBottomPredicateForEnforcement in RelToCore
remainingUnBoundDomainVars: Set(essentialocl::Variable);
predicatesWithVarBindings:Set(qvtbase::Predicate);
domain relations rdtVarsSeq:Sequence(Set(Element)) {
rdtSet:Set(Element) {
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}}
++ _
}
++ _
};
rdtVarsSeq->at(2) = predicatesWithoutVarBindings;
rdtVarsSeq->at(3) = unboundDomainVars;
The above is hard to read and uses nested collections in ways that are claimed to be unsupported. Much simpler to just write:
domain relations
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}},
predicatesWithVarBindings:Set(qvtbase::Predicate) {},
remainingUnBoundDomainVars: Set(essentialocl::Variable) {}
;
Suggest in the AS, RelationDomain.pattern changes to RelationDomain.patterns, RelationDomain.rootVariable moves to DomainPattern.rootVariable.
Suggest in the DomainCS CS, "pattern=DomainPatternCS" changes to "patterns+=DomainPatternCS (',' patterns+=DomainPatternCS)*"
As a consequence additional variables may be passed in a RelationCallExp. These can still be in rootVariable order.
QVTr Multi-root match
The QVTr AS and CS permit only a single pattern to be matched in the input (and output) domains. QVTc permits multi-matches.
This can be worked around with nested collections as demonstrated by RDomainToMBottomPredicateForEnforcement in RelToCore
remainingUnBoundDomainVars: Set(essentialocl::Variable);
predicatesWithVarBindings:Set(qvtbase::Predicate);
domain relations rdtVarsSeq:Sequence(Set(Element)) {
rdtSet:Set(Element) {
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}}
++ _
}
++ _
};
rdtVarsSeq->at(2) = predicatesWithoutVarBindings;
rdtVarsSeq->at(3) = unboundDomainVars;
The above is hard to read and uses nested collections in ways that are claimed to be unsupported. Much simpler to just write:
domain relations
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}},
predicatesWithVarBindings:Set(qvtbase::Predicate) {},
remainingUnBoundDomainVars: Set(essentialocl::Variable) {}
;
Suggest in the AS, RelationDomain.pattern changes to RelationDomain.patterns, RelationDomain.rootVariable moves to DomainPattern.rootVariable.
Suggest in the DomainCS CS, "pattern=DomainPatternCS" changes to "patterns+=DomainPatternCS (',' patterns+=DomainPatternCS)*"
As a consequence additional variables may be passed in a RelationCallExp. These can still be in rootVariable order.
Discussion
This seems to be a completely unnecessary restriction that caused the author of relToCore significant difficulties.
The only downside seems to be a slight increase in complexity of a RelationCallExp. No longer exactly one argument per domain, but linearizing the roots per domain is not exactly hard.
(The spelling in the discussion is that of the Eclipse QVTr prototype. Changing pattern to patterns is not appropriate for QVT1.x where property names tend to be simple-singulars. Perhaps a change to owned-plurals and so ownedPatterns may be appropriate for QVT 2.0.)
Exploiting this in relToCore should wait until an executable version has been debugged.
The full names of the QVT languages are a bit cumbersome and so QVTc/QVTo/QVTr are often found in non-OMG usage.
Suggest that the QVT specification at least define them and perhaps use them a little too.
QVTc/QVTo/QVTr acronyms
The full names of the QVT languages are a bit cumbersome and so QVTc/QVTo/QVTr are often found in non-OMG usage.
Suggest that the QVT specification at least define them and perhaps use them a little too.
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.
For AnyType::oclAsType(oclType) operation I could write:
var aClass : Class := anotherVar.oclAsType(Class);
However, for Model::objectsOfType(OclType) operation I can't do:
var aClassSet : Set(Class) := aModel.objectsOfType(Class);
I have to do the following, instead:
var aClassSet : Set(Class) := aModel.objectsOfType(Class).oclAsType(Set(Class));
Therefore, for end-user usability, I propose exploiting TemplateParameterType and changing some QVTo Standard Library operations
Element::subobjectsOfType(OclType) : Set(T)
Element::allSubobjects(OclType) : Set(T)
Element::subobjectsOfKind(OclType) : Set(T)
Element::allSubobjectsOfKind(OclType) : Set(T)
Element::clone() : T
Element::deepclone() : T
Model::objectsOfType(OclType) : Set(T)
Model::copy() : T
Model::createEmptyModel(): T
Note: this approach is made in the Object::asOrderedTuple() : OrderedTuple(T) operation.
8.3.5.7 createEmptyModel static Model::createEmptyModel() : Model Creates and initializes a model of the given type. This operation is useful when creating intermediate models within a transformation.
QVTo Standard Library. Some operation's returned values would better return the TemplateParameterType **
Several stdlib operations would be better changed to avoid doing unnecessary castings on the returned value of the operation.
For AnyType::oclAsType(oclType) operation I could write:
var aClass : Class := anotherVar.oclAsType(Class);
However, for Model::objectsOfType(OclType) operation I can't do:
var aClassSet : Set(Class) := aModel.objectsOfType(Class);
I have to do the following, instead:
var aClassSet : Set(Class) := aModel.objectsOfType(Class).oclAsType(Set(Class));
Therefore, for end-user usability, I propose exploiting TemplateParameterType and changing some QVTo Standard Library operations
Element::subobjectsOfType(OclType) : Set(T)
Element::allSubobjects(OclType) : Set(T)
Element::subobjectsOfKind(OclType) : Set(T)
Element::allSubobjectsOfKind(OclType) : Set(T)
Element::clone() : T
Element::deepclone() : T
Model::objectsOfType(OclType) : Set(T)
Model::copy() : T
Model::createEmptyModel(): T
Note: this approach is made in the Object::asOrderedTuple() : OrderedTuple(T) operation.
Discussion
subobjectsOfType etc duplicate QVT13-53
clone/deepclone merged into QVT13-53
Model::copy/createEmptyModel - NO. Model is the correct return type.
his section (8.3.2) is very confusing for the reader. What does synonym means ? - Is just like a shorthand of the concrete syntax ? - Is just a new operation included in the QVTo Standard Library semantically equivalent?. Ideally, just one type/operation must exist (the OCL predefined type and the operation of an OCL predefined type), so that, writing Void (a type) or asType (operation) should produce the same AST as if I write OclVoid or oclAsType. With this idea, I'm really puzzled with the third paragraph of the section. Please revise this section so that it is less confusing.
section (8.3.2) is very confusing for the reader
This section (8.3.2) is very confusing for the reader. What does synonym means ? - Is just like a shorthand of the concrete syntax ? - Is just a new operation included in the QVTo Standard Library semantically equivalent?. Ideally, just one type/operation must exist (the OCL predefined type and the operation of an OCL predefined type), so that, writing Void (a type) or asType (operation) should produce the same AST as if I write OclVoid or oclAsType. With this idea, I'm really puzzled with the third paragraph of the section. Please revise this section so that it is less confusing.
Discussion - Ocl type prefixes
As an OCL user, I find the attempt and recommendation to hide the underlying OCL functionality very confusing, particularly when it introduces potential collisions whose prevention is inaccurately described.
Since the description of the M1 types does not enumerate them, I am not clear which types are intended. If Eclipse QVTo is any guide, it would be OclAny/Any, OclVoid/Void, but not OclElement, OclInvalid, OclMessage, OclState, OclType.
If this policy is to remain recommended, it must also apply to all of the above. I find the injection of Element and Type into the user's namespace particularly offensive.
I recommend that the recommendation be reversed, so that we just observe that QVTo implementations offering backward compatibility may permit the seven enumerated synonyms to be used as shortforms of the full spelling.
Discussion - ocl operation prefixes
The references to the "Ocl" prefix are inaccurate for operations where it is "ocl".
As an OCL user, I find the attempt and recommendation to hide the underlying OCL functionality a bit confusing, particularly since the abbreviated forms are used very little used in the editorial text and have no definition.
I recommend eliminating their editorial usage and defining them as synonyms that a QVTo implementation offering backward compatibility may support as an alternate spelling that is mapped to the full spelling when used within the abstract syntax
Discussion - Operation name synonyms
This section was written for OCL 2.0 which has no String::+ operator. String::+ is available in OCL 2.4 so there is no need for QVT 1.2 to define it as a synonym.The other mathematical operators have always been part of OCL, so the purpose of enumerating them is unclear and indeed confusing. Is there actually an operation with the spelling "operator+"? I see no need for one. In the concrete syntax, "+" is fully available. In UML and OCL "+" is a permissible internal spelling for an operation name. The _'+' escape enables its use in arbitrary name contexts.
The only question is whether a particular implementation might choose to use "plus" as a spel;ling to avoid problems in languages that do not allow arbitrary spellings. But that is an implementation language-specific choice that does not affect QVT or OCL; perhaps relevant to the Java-binding for OCL specification if written. FWIW, Eclipse QVTo has no "operator+" operation.
Conversely, is the specification actually saying that "plus" may be used rather than "+"? This might be a way of elevating an implementation language workaround into the source, which seems rather perverse. FWIW, Eclipse QVTo provides no "divide" operation.
The operation synonym sentences can be eliminated without any loss.
Creating aliases seems to be a good idea specially when dealing with complex types. However, for that purpose, it is not clear to me that we need to create a (useless) typedef just to represent an alias in the concrete syntax. In practice aliases are very useful when writing transformations (in concrete syntax), but they are useless in the abstract syntax (extra unnecessary classes in modules). One may still think that a typedef as an alias (no extra condition) may be needed to add operations to existing types, as specification suggests doing in order to include new operations for the OCL standard library predefined types. However, this still can be done by means of helpers. Suggestions: - Remove the statements related to aliases in the section 8.2.2.24 - Make Typedef.condition reference be mandatory in Figure 8.7 since, now, Typedef in the abstract syntax will be used to constrain existing types. - Add statements in the concrete syntax section, to clarify the use of aliases to rename existing types. Maybe, a new keyword (like alias) could be included to avoid confusions with the typedef one. - Change the grammar to adapt it to these suggestions. - Clarify in the Standard Library section that helpers will be used to add new operations to the OCL Std Lib predefined type.
Typedef aliases issue
Creating aliases seems to be a good idea specially when dealing with complex types. However, for that purpose, it is not clear to me that we need to create a (useless) typedef just to represent an alias in the concrete syntax. In practice aliases are very useful when writing transformations (in concrete syntax), but they are useless in the abstract syntax (extra unnecessary classes in modules). One may still think that a typedef as an alias (no extra condition) may be needed to add operations to existing types, as specification suggests doing in order to include new operations for the OCL standard library predefined types. However, this still can be done by means of helpers. Suggestions: - Remove the statements related to aliases in the section 8.2.2.24 - Make Typedef.condition reference be mandatory in Figure 8.7 since, now, Typedef in the abstract syntax will be used to constrain existing types. - Add statements in the concrete syntax section, to clarify the use of aliases to rename existing types. Maybe, a new keyword (like alias) could be included to avoid confusions with the typedef one. - Change the grammar to adapt it to these suggestions. - Clarify in the Standard Library section that helpers will be used to add new operations to the OCL Std Lib predefined type.
Discussion
Ignoring the QVT Standard Library usage eliminated by the resolution of Issue 13252, http://solitaire.omg.org/browse/QVT13-13, there are two distinct usages of typedef.
a) to create an alias
b) to create a new constrained type
Discussion - alias
If an alias introduces a new type as the inheritance of Typedef from Type would suggest, we have semantic nightmares. Which type conforms to which? How do we ensure that all functionality understands the typedef equivalence? As observed, a typedef is a concrete syntax text macro that should be eliminated during conversion to the abstract syntax to avoid ambiguities. However an AS concept is needed to persist the macro. A Tag is sufficient.
Discussion - constrained type
The typedef syntax with a constraint introduces a new type. However all the important semantics of this type are unspecified. What are the superclasses of this type? What does it conform to? How do its operations and properties interact with the unconstrained type? Can a Constrained Integer be used as a Sequence index?
The only example of a constrained type is:
typedef TopLevelPackage = Package [container()=null];
suggesting that perhaps self is to be interpreted as the type instance. If container() is the proposed oclContainer() then the example is particularly interesting. If a TopLevelPackage is assigned to a container, how does the type change? Are all assignments supposed to have a predicate evaluation to ensure that typedef constraints are not violated? Are assigned types to be changed by an assignment? Does an assignment that violates a constrained type constraint render a transformation invalid and require some form of failure?
Look at it another way. Suppose we used bland UML. We can add an invariant to a class, which can inherit/aggregate another type to re-use it. We and general purpose tooling understand these semantics. What does a typedef constrained type offer that is new? just magic undefined semantics that cannot be used with any non-QVTo tool.
The constrained typedef appears to be a clear case of misguided syntax sugar. If metamodeling syntax sugar is really needed, let it have a clear relationship to UML.
Conclusion
The alias usage is a concrete syntax synonym that has no need of a Typedef class; a Tag will do.
The constrained type is underspecified syntax sugar. The Typedef class can be deprecated.
FWIW: neither of these forms of typedef is implemented by Eclipse QVTo.
Suggestion: In the Operational Mappings language, element creation and element attachment/detachment to/from an extent should be seen and treated as two different and independent activities. Once an element is created via an ObjectExp, this element is usually attached to another element immediately afterwards, which becomes its container, so the ObjectExp semantics of assigning it to an explicit or inferred extent becomes an unnecessary overhead. And also there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time. They could even exist prior to the transformation execution. A case where this is relevant is with the result of a 'Element::clone()' or 'Element::deepclone()' operation execution. Is it expected that these model elements must belong by default to the same model as the original? How to clone parts of an extent with direction kind == 'in'? How to make them become part of the Set of root elements of another, different extent?
element creation and element attachment/detachment to/from an extent
Suggestion: In the Operational Mappings language, element creation and element attachment/detachment to/from an extent should be seen and treated as two different and independent activities. Once an element is created via an ObjectExp, this element is usually attached to another element immediately afterwards, which becomes its container, so the ObjectExp semantics of assigning it to an explicit or inferred extent becomes an unnecessary overhead. And also there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time. They could even exist prior to the transformation execution. A case where this is relevant is with the result of a 'Element::clone()' or 'Element::deepclone()' operation execution. Is it expected that these model elements must belong by default to the same model as the original? How to clone parts of an extent with direction kind == 'in'? How to make them become part of the Set of root elements of another, different extent?
Discussion
This seems to be a misunderstanding. ObjectExp does not require a created object to be attached to an inferred extent.
This functionality seems to be present already.
Creation without attachment requires a null or null-valued extent during creation.
Attachment after creation can occur through an ObjectExp update to the required extent.
Re-attachment presumably occurs through an ObjectExp update to the new extent.
Detachment then naturally occurs through an ObjectExp update to a null-valued extent.
This issue inspired the provision of a better desciption of extents. The resolution is therefore merged with that of QVT-36.
Major Problem:
(1) The current abstract syntax of ImperativeOCL introduces a couple of
unclear situations. This may lead to incompatible QVT implementations.
Further Problems:
(2) Control flow constructs introduced by ImperativeOCL are redundant
compared with existing conventional OCL constructs.
(3) Several OCL equivalence rules break when ImperativeOCL is present.
Detailed problem description:
(1) The current abstract syntax of ImperativeOCL introduces a couple of
unclear situations. This may lead to incompatible QVT implementations.
In the abstract syntax, ImperativeOCL expressions / statements are
inherited from OclExpression. Therefore, conventional OCL
expressions may (and will) contain sub-expressions that are
actually ImperativeOCL expressions.
In conventional OCL, the interpretation of an expression under a
given environment is a value. In ImperativeOCL, the interpretation
of an expression is a value and a new environment
(state,variables). This extended interpretation is not given for
conventional OCL expressions, leading to undefined operational
semantics of those expressions.
Example: Given the following compute expression:
compute(z:Boolean) {
var x : Boolean := true
var y : Boolean := true
if ((x:=false) and (y:=false))
z := y
}
What is the value of this expression: is it true or false (It
depends on whether the 'and' operator is evaluated short-circuit
or strict). The situation is similar for the evaluation of the
other logical connectives, forAll, and exists when these
expressions contain imperative sub-expressions.
(2) Control flow constructs introduced by ImperativeOCL are redundant
compared with existing conventional OCL constructs.
Some of the new language features in ImperativeOCL such as forEach
and the imperative conditional are not really necessary. Their
effect can already be achieved using conventional OCL expressions:
For example:
company.employees->forEach(c)
has the same effect as
company.employees->iterate(c; r:OclAny=Undefined |
c.salary := c.salary * 1.1
)
and
if ( x < 0 )
else
{ x := 1 } endif is the same as
if x < 0 then x := 0 else x := 1 endif
(3) Several OCL equivalence rules break when ImperativeOCL is present.
In conventional OCL, several equivalence rules well known from
logic hold. Allowing OCL expression to contain imperative
sub-expressions breaks these equivalence rules.
Examples:
let x=e1 in e2 equiv. e2
e1 and e2 equiv. e2 and e1
These equivalences do not necessarily hold if e1 or e2 are allowed
to have side-effects.
Proposed solution:
(A) - (The cheap solution.) State textually that conventional OCL
expressions (as described in the OMG OCL spec.) are not
allowed to have side effects unless used as part of a top
level ImperativeOCL expression. Therefore, even in a system
supporting ImperativeOCL, class invariants, and pre- and
postconditions (e.g.) will not be allowed to contain
ImperativeOCL sub-expressions.
State explicitly that the redundant flow control statements
have been introduced (solely) to write concise imperative
programs and that the side-effect free forms of conditional
evaluation ( 'if-then-else-endif' and 'iterate' ) shall not be
used to program side-effects (instead, the ImperativeOCL forms
shall be used).
(B) - (Major rework.) Rework the abstract syntax to reuse OCL
expressions by composition rather than by inheritance.
Imperative expressions ( => rename to 'statements' ) then may
contain sub-statements and OCL expressions; OCL expressions
are reused unchanged from the OCL spec (no imperative
sub-expressions, no side-effects).
These issues have been discussed on the MoDELS 2008 OCL Workshop,
more details can be found at
http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf
current abstract syntax of ImperativeOCL introduces a couple of unclear situations
Major Problem:
(1) The current abstract syntax of ImperativeOCL introduces a couple of unclear situations. This may lead to incompatible QVT implementations.
Further Problems:
(2) Control flow constructs introduced by ImperativeOCL are redundant compared with existing conventional OCL constructs.
(3) Several OCL equivalence rules break when ImperativeOCL is present.
Detailed problem description:
(1) The current abstract syntax of ImperativeOCL introduces a couple of unclear situations. This may lead to incompatible QVT implementations.
In the abstract syntax, ImperativeOCL expressions / statements are inherited from OclExpression. Therefore, conventional OCL expressions may (and will) contain sub-expressions that are actually ImperativeOCL expressions. In conventional OCL, the interpretation of an expression under a given environment is a value. In ImperativeOCL, the interpretation of an expression is a value and a new environment (state,variables). This extended interpretation is not given for conventional OCL expressions, leading to undefined operational semantics of those expressions.
Example: Given the following compute expression:
compute(z:Boolean) {
var x : Boolean := true
var y : Boolean := true
if ((x:=false) and (y:=false))
z := y
}
What is the value of this expression: is it true or false (It depends on whether the 'and' operator is evaluated short-circuit or strict). The situation is similar for the evaluation of the other logical connectives, forAll, and exists when these expressions contain imperative sub-expressions.
(2) Control flow constructs introduced by ImperativeOCL are redundant compared with existing conventional OCL constructs.
Some of the new language features in ImperativeOCL such as forEach and the imperative conditional are not really necessary. Their effect can already be achieved using conventional OCL expressions:
For example:
company.employees->forEach(c)
has the same effect as
company.employees->iterate(c; r:OclAny=Undefined |
c.salary := c.salary * 1.1
)
and
if ( x < 0 )
else
{ x := 1 }endif is the same as
if x < 0 then x := 0 else x := 1 endif
(3) Several OCL equivalence rules break when ImperativeOCL is present.
In conventional OCL, several equivalence rules well known from logic hold. Allowing OCL expression to contain imperative sub-expressions breaks these equivalence rules.
Examples:
let x=e1 in e2 equiv. e2
e1 and e2 equiv. e2 and e1
These equivalences do not necessarily hold if e1 or e2 are allowed to have side-effects.
Proposed solution:
(A) - (The cheap solution.) State textually that conventional OCL expressions (as described in the OMG OCL spec.) are not allowed to have side effects unless used as part of a top level ImperativeOCL expression. Therefore, even in a system supporting ImperativeOCL, class invariants, and pre- and postconditions (e.g.) will not be allowed to contain ImperativeOCL sub-expressions.
State explicitly that the redundant flow control statements have been introduced (solely) to write concise imperative programs and that the side-effect free forms of conditional evaluation ( 'if-then-else-endif' and 'iterate' ) shall not be used to program side-effects (instead, the ImperativeOCL forms shall be used).
(B) - (Major rework.) Rework the abstract syntax to reuse OCL expressions by composition rather than by inheritance.
Imperative expressions ( => rename to 'statements' ) then may contain sub-statements and OCL expressions; OCL expressions are reused unchanged from the OCL spec (no imperative sub-expressions, no side-effects).
These issues have been discussed on the MoDELS 2008 OCL Workshop, more details can be found at http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf
Discussion - 1 short circuit semantics
It is possible to weasel out of this narrowly described problem by observing that OCL only supports short-circuit semantics once it is proven that no invalid lurks beyond the short-circuit. An extension to this could inhibit short-circuit semantics if any imperative expression is involved.
Discussion - (2) redundant control flow
The first suggestion is contradictory. The replacement for forEach is noticeably longer and uses a side effect within an iterate, which the author argues against elsewhere.
The second suggestion incorrectly assumes that an else clause is present. The imperative if (SwitchExp) allows one-sided functionality including selective control flow adjustment.
Discussion - (3) broken equivalence
The example is unreadable, but the point is unarguable; imperative semantics within functional semantics subvert the functional.
(A) - (The cheap solution.) is simple and adopted here.
(B) - (Major rework.) is a breaking structural change and so forked off to http://solitaire.omg.org/browse/QVT13-87 for consideration by QVT 2.0.
In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so:
package QVTBase
context TypedModel
def: allUsedPackage() : Set(EMOF::Package)
= self.dependsOn.allUsedPackage()>asSet()>union(self.usedPackage)
endpackage
package QVTRelation
context RelationImplementation
inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package)
endpackage
This is not satisfied by almost the last line of RelToCore in 10.3:
enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me);
which seems to have output second.
-----------------------------------------------------
More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation.
This semantic clumsiness could be resolved, if, within a transformation,
relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output.
The RelToCore example can then be mended by declaring that:
RelToCore(...) extends utils::CopyUtilities
and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation.
7.11.3.6 (and 7.11.1.1) BlackBox operation signature difficulties
In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so:
package QVTBase context TypedModel def: allUsedPackage() : Set(EMOF::Package) = self.dependsOn.allUsedPackage()>asSet()>union(self.usedPackage) endpackage package QVTRelation context RelationImplementation inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package) endpackage
This is not satisfied by almost the last line of RelToCore in 10.3:
enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me);
which seems to have output second.
-----------------------------------------------------
More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation.
This semantic clumsiness could be resolved, if, within a transformation,relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output.
The RelToCore example can then be mended by declaring that:
RelToCore(...) extends utils::CopyUtilities
and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation.
Discussion
Binding self to a Transformation instance may conflict with self as the context in a query. Much safer to bind this; just like QVTo.
Using this as the source of an OperationCallExp of a query eliminates an incompatibility with OCL. But there is no need bloat every RelationCallExp with an extra VariableExp for this.
Any enhancement here needs prototyping.
The whole Concrete Syntax section deserves a much more substantial description.
In particular...
The mechanism by which a package name is located is unresolved, perhaps deliberately,
but the omission should be explicit.
What constraints exist on forward referencing of names?
Transformations and mappings could be ordered so that forward references are avoided,
but large modules benefit from an alphabetical ordering of elements, so requiring
a parser friendly order is not user friendly.
9.18 Undefined semantics
The whole Concrete Syntax section deserves a much more substantial description.
In particular...
The mechanism by which a package name is located is unresolved, perhaps deliberately,
but the omission should be explicit.
What constraints exist on forward referencing of names?
Transformations and mappings could be ordered so that forward references are avoided,
but large modules benefit from an alphabetical ordering of elements, so requiring
a parser friendly order is not user friendly.
Discussion
This isn't going to happen until a QVT 2.0 rewrite adopts the autogeneration approaches underway for OCL.
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.
9.18 Undefined syntax
---------------------
The syntax for TransformationName, DirectionName, MappingName, PropertyName and VariableName
is undefined. Presumably each of these is an Identifier (below) when defining, but a PathNameCS
when referencing.
The syntax for PackageName is undefined. Presumably it is an OCL PathNameCS.
The syntax for ValueOCLExpr is undefined. This is presumably an OclExpressionCS.
The syntax for BooleanOCLExpr is undefined. This could be an OclExpressionCS of Boolean type but ...
The syntax for SlotOwnerOCLExpr is undefined. This could be an OclExpressionCS of Class type but ...
If BooleanOCLExpr and SlotOwnerOCLExpr are parsed as OclExpressionCS the 'default' prefix
causes a major ambiguity for 'default(...).xx' as a parenthesised slot owner or function call.
It is necessary to make 'default' a reserved word within OCL expressions.
Suggest: define BooleanOCLExpr and SlotOwnerOCLExpr very narrowly.
Predicate ::= SimpleNameCS ("." SimpleNameCS)* "=" OclExpressionCS
Assignment ::= ["default"] SimpleNameCS ("." SimpleNameCS)* ":=" OclExpressionCS
Undefined syntax
9.18 Undefined syntax
---------------------
The syntax for TransformationName, DirectionName, MappingName, PropertyName and VariableName
is undefined. Presumably each of these is an Identifier (below) when defining, but a PathNameCS
when referencing.
The syntax for PackageName is undefined. Presumably it is an OCL PathNameCS.
The syntax for ValueOCLExpr is undefined. This is presumably an OclExpressionCS.
The syntax for BooleanOCLExpr is undefined. This could be an OclExpressionCS of Boolean type but ...
The syntax for SlotOwnerOCLExpr is undefined. This could be an OclExpressionCS of Class type but ...
If BooleanOCLExpr and SlotOwnerOCLExpr are parsed as OclExpressionCS the 'default' prefix
causes a major ambiguity for 'default(...).xx' as a parenthesised slot owner or function call.
It is necessary to make 'default' a reserved word within OCL expressions.
Suggest: define BooleanOCLExpr and SlotOwnerOCLExpr very narrowly.
Predicate ::= SimpleNameCS ("." SimpleNameCS)* "=" OclExpressionCS
Assignment ::= ["default"] SimpleNameCS ("." SimpleNameCS)* ":=" OclExpressionCS
Discussion
Merged with the inadequate definition of identifiers.
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.
QVT Relations and working with stereotypes: Is there something like a QVT-R standard library with methods on stereotypes in it? There is none in the specification; compare QVT-R, there are some methods. Are there some else options for accessing stereotypes with QVT-R?
QVT Relations and working with stereotypes:
QVT Relations and working with stereotypes: Is there something like a QVT-R standard library with methods on stereotypes in it? There is none in the specification; compare QVT-R, there are some methods. Are there some else options for accessing stereotypes with QVT-R?
Discussion
Good question. Recent progress on ensuring that typesafe OCL navigation works for stereotypes may render the answer trivial, but until such time as a stereotyped QVTr transformation has been executed it is too soon to respond.
The author of Issue 9379 misunderstood the poor description of Pattern::bindsTo and consequently removed the
{composes} qualifier..
There was actually nothing wrong with bindsTo that could not have been fixed by clearer wording to the effect that bindsTo was a dustbin container for variables not contained elsewhere.
The above kind of emphasises the benefits of an ownedPlurals naming policy. Therefore suggest that:
a) the AST bloat from the redundant bindsTo be replaced by definition of a suitable derived property that satisfies the intent of all variables.
b) that variables be renamed ownedVariables and used throughout the QVTr to QVTc transformation
Rewind Issues 9379, 10938
The author of Issue 9379 misunderstood the poor description of Pattern::bindsTo and consequently removed the
{composes} qualifier..
There was actually nothing wrong with bindsTo that could not have been fixed by clearer wording to the effect that bindsTo was a dustbin container for variables not contained elsewhere.
The above kind of emphasises the benefits of an ownedPlurals naming policy. Therefore suggest that:
a) the AST bloat from the redundant bindsTo be replaced by definition of a suitable derived property that satisfies the intent of all variables.
b) that variables be renamed ownedVariables and used throughout the QVTr to QVTc transformation
Discussion
The problem is genuine, but further Eclipse QVTr prototyping reveals two distinct cases, one requiring containment, another not. Further work is needed to specify these accurately.
The QVTo Standard Library has no model and consequently no namespace.
This encourages a major confusion:
The QVToLib::Model and QVToLib::Transformation types used in the QVTo Standard Library are at a different meta-level to UML::Model and QVTbase::Transformation. We have the uncomfortable situation that a QVToLib::Model is an instance of a QVTbase::TypedModel and a QVToLib::Transformation is an instance of a QVTbase::Transformation.
As a minimum the distinct namespaces should be identified and modeled.
Possibly QVToLib::Model and QVToLib::Transformation should be renamed. Since they have no namespace they are currently unuseable in code; their sole purpose is for specification of implementation behavior.
QVTo Standard Library mode and namespace
The QVTo Standard Library has no model and consequently no namespace.
This encourages a major confusion:
The QVToLib::Model and QVToLib::Transformation types used in the QVTo Standard Library are at a different meta-level to UML::Model and QVTbase::Transformation. We have the uncomfortable situation that a QVToLib::Model is an instance of a QVTbase::TypedModel and a QVToLib::Transformation is an instance of a QVTbase::Transformation.
As a minimum the distinct namespaces should be identified and modeled.
Possibly QVToLib::Model and QVToLib::Transformation should be renamed. Since they have no namespace they are currently unuseable in code; their sole purpose is for specification of implementation behavior.
Discussion
It is difficult to make sensible progress until the OCL work in progress modeling libraries provides the solution.
The specification of "late" semantics uses the "conceptually" word; a sure sign of missing semantics. It is followed by a magic null value that stores information for later use and with an unspecified trace interaction.
The interaction of "late" and implicit collect is not handled so in
generalizations := self.eSuperTypes->collect(t | t.late resolve(UML::Generalization))
the direct association of "late" with asssignment is no longer direct; the "late"s must be aggregated. Potentuially this may occur in arbitrary complexd expressions including mapping calls!
An alternate multi-pass interpretation of "late" is given.
This seems like the correct approach; an MtoM transformation from a with-late to multi-pass without-late transformation.
Inadequate definition of "late" semantics
The specification of "late" semantics uses the "conceptually" word; a sure sign of missing semantics. It is followed by a magic null value that stores information for later use and with an unspecified trace interaction.
The interaction of "late" and implicit collect is not handled so in
generalizations := self.eSuperTypes->collect(t | t.late resolve(UML::Generalization))
the direct association of "late" with asssignment is no longer direct; the "late"s must be aggregated. Potentially this may occur in arbitrary complex expressions including mapping calls!
An alternate multi-pass interpretation of "late" is given.
This seems like the correct approach; an MtoM transformation from a with-late to multi-pass without-late transformation.
Discussion
Yes, but such an MtoM is non-trivial. Needs development and testing before it can be included as part of the specification.
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)
{ name:=n; type:=t; }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)
{ name:=n; type:=t; }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:
QVT 1.3 8.1.11.1 attempts to identify the hidden information that a trace record must contain. The text is not suitable for a multiple inheritance where there may be one invoked mapping and many executed mappings.
Probably need to trace all executed mappings.
Need to specify how the inherited mappings merge more clearly; probably as a section-wise merge.
The description of UnlinkExp.target specifies an OclExpression but describes a Property.
Is this an error? Is it introducing a new PropertyLiteralExp?
Pete Rivett, private email, requests removal of "2.0" from the "MOF 2.0 QVT 1.3" title.
Two versions numbers are certainly confusing.
But Isn't the "MOF" redundant too?
The glossary definition of Incremental Update strongly suggests that the trace necessary to execute a transformation is also suitable for incremental execution. This is a total falacy.
Incremental execution of a Rule R with an input s must occur if any relevant property of s changes, which includes any property navigable from s. e.g. s.a.b.c.name. Therefore the trace for incremental execution must identify the identity and value of all accessed property values so that any change can influence re-execution.
Since accessed values may be produced by another mapping, the trace must also record the identity and value of all assigned property values too.
This affects all of QVTc, QVTr, and QVTo.
For QVTo, a re-execution must repeat the accidental ordering of Set elements. Does the specification define an order or just require implementation magic? Is this then a determinstic form of asOrderedSet()?
Does QVTo support operation overloading in a similar way to Java?
How are conflicting contextual operations resolved when access semantics are used for import?
How are conflicting contextual operations resolved when extension semantics are used for import?
Is the resolution at run-time different to that at compile-time?
The description of UnlinkExp.target specifies an OclExpression but describes a Property.
Is this an error? Is it introducing a new PropertyLiteralExp?
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
A late resolve() defers an assignment to such a late time that it cannot be used. Multi-pass transformations must therefore either maintain their own Dict of mappings, or use multiple transformations.
Suggest: Allow a "late" keyword to prefix a block, so that late resolution occurs at the end of the block.
Transformation::transform()/parallelTransform() support a nested invocation but the returned Status content is very limited.
Suggest 1: Reify TraceData/TraceRecord so that arbitrary OCL queries can be executed.
Suggest 2: Add a getTraceData() to Status and 'this'.
Suggest 3: Add an optional Status first argument to all resolve() methods to enable use on an invoked Transformation.
NB. Since a transformation invocation involves cloning, resolve() should hide the clones so that the caller sees only a single object space.
Suggest 4: TraceData/TraceRecord/Status/Transformation/Model should be / share share an abstraction with QVTc/QVTr.
Issue 13082 - http://solitaire.omg.org/browse/QVT13-8 identifies the unsound relationship between ImperativeOCL and EssentialOCL.
It offered a simple textual fix which was exploited to resolve the original issue.
It also suggests a harder rework to establish modeling integrity. This issue forks off the rework not resolved by the original issue.
(B) - (Major rework.) Rework the abstract syntax to reuse OCL
expressions by composition rather than by inheritance.
Imperative expressions ( => rename to 'statements' ) then may
contain sub-statements and OCL expressions; OCL expressions
are reused unchanged from the OCL spec (no imperative
sub-expressions, no side-effects).
These issues have been discussed on the MoDELS 2008 OCL Workshop,
more details can be found at
http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf
(Since this is a breaking structural change, it is unlikely to happen before QVT 2.0)
Major Problem:
(1) The current abstract syntax of ImperativeOCL introduces a couple of
unclear situations. This may lead to incompatible QVT implementations.
Further Problems:
(2) Control flow constructs introduced by ImperativeOCL are redundant
compared with existing conventional OCL constructs.
(3) Several OCL equivalence rules break when ImperativeOCL is present.
Detailed problem description:
(1) The current abstract syntax of ImperativeOCL introduces a couple of
unclear situations. This may lead to incompatible QVT implementations.
In the abstract syntax, ImperativeOCL expressions / statements are
inherited from OclExpression. Therefore, conventional OCL
expressions may (and will) contain sub-expressions that are
actually ImperativeOCL expressions.
In conventional OCL, the interpretation of an expression under a
given environment is a value. In ImperativeOCL, the interpretation
of an expression is a value and a new environment
(state,variables). This extended interpretation is not given for
conventional OCL expressions, leading to undefined operational
semantics of those expressions.
Example: Given the following compute expression:
compute(z:Boolean) {
var x : Boolean := true
var y : Boolean := true
if ((x:=false) and (y:=false))
z := y
}
What is the value of this expression: is it true or false (It
depends on whether the 'and' operator is evaluated short-circuit
or strict). The situation is similar for the evaluation of the
other logical connectives, forAll, and exists when these
expressions contain imperative sub-expressions.
(2) Control flow constructs introduced by ImperativeOCL are redundant
compared with existing conventional OCL constructs.
Some of the new language features in ImperativeOCL such as forEach
and the imperative conditional are not really necessary. Their
effect can already be achieved using conventional OCL expressions:
For example:
company.employees->forEach(c)
has the same effect as
company.employees->iterate(c; r:OclAny=Undefined |
c.salary := c.salary * 1.1
)
and
if ( x < 0 )
else
{ x := 1 } endif is the same as
if x < 0 then x := 0 else x := 1 endif
(3) Several OCL equivalence rules break when ImperativeOCL is present.
In conventional OCL, several equivalence rules well known from
logic hold. Allowing OCL expression to contain imperative
sub-expressions breaks these equivalence rules.
Examples:
let x=e1 in e2 equiv. e2
e1 and e2 equiv. e2 and e1
These equivalences do not necessarily hold if e1 or e2 are allowed
to have side-effects.
Proposed solution:
(A) - (The cheap solution.) State textually that conventional OCL
expressions (as described in the OMG OCL spec.) are not
allowed to have side effects unless used as part of a top
level ImperativeOCL expression. Therefore, even in a system
supporting ImperativeOCL, class invariants, and pre- and
postconditions (e.g.) will not be allowed to contain
ImperativeOCL sub-expressions.
State explicitly that the redundant flow control statements
have been introduced (solely) to write concise imperative
programs and that the side-effect free forms of conditional
evaluation ( 'if-then-else-endif' and 'iterate' ) shall not be
used to program side-effects (instead, the ImperativeOCL forms
shall be used).
(B) - (Major rework.) Rework the abstract syntax to reuse OCL
expressions by composition rather than by inheritance.
Imperative expressions ( => rename to 'statements' ) then may
contain sub-statements and OCL expressions; OCL expressions
are reused unchanged from the OCL spec (no imperative
sub-expressions, no side-effects).
These issues have been discussed on the MoDELS 2008 OCL Workshop,
more details can be found at
http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf
The example transformation creates numerous orphan trace classes.
Surely these should be contained by a trace Package?
This could be produced by a top level RelationalTransformationToTracePackage relation. RelationToTraceClass should then not be top level.
Generation of trace is separate from core, so surely there should be a trace direction for the trace output? The core direction should use the trace direction.
The QVTo Standard Library has no model and consequently no namespace.
This encourages a major confusion:
The QVToLib::Model and QVToLib::Transformation types used in the QVTo Standard Library are at a different meta-level to UML::Model and QVTbase::Transformation. We have the uncomfortable situation that a QVToLib::Model is an instance of a QVTbase::TypedModel and a QVToLib::Transformation is an instance of a QVTbase::Transformation.
As a minimum the distinct namespaces should be identified and modeled.
Possibly QVToLib::Model and QVToLib::Transformation should be renamed. Since they have no namespace they are currently unuseable in code; their sole purpose is for specification of implementation behavior.
The author of Issue 9379 misunderstood the poor description of Pattern::bindsTo and consequently removed the
{composes} qualifier..
There was actually nothing wrong with bindsTo that could not have been fixed by clearer wording to the effect that bindsTo was a dustbin container for variables not contained elsewhere.
The above kind of emphasises the benefits of an ownedPlurals naming policy. Therefore suggest that:
a) the AST bloat from the redundant bindsTo be replaced by definition of a suitable derived property that satisfies the intent of all variables.
b) that variables be renamed ownedVariables and used throughout the QVTr to QVTc transformation
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.
QVT Relations and working with stereotypes: Is there something like a QVT-R standard library with methods on stereotypes in it? There is none in the specification; compare QVT-R, there are some methods. Are there some else options for accessing stereotypes with QVT-R?
The specification of "late" semantics uses the "conceptually" word; a sure sign of missing semantics. It is followed by a magic null value that stores information for later use and with an unspecified trace interaction.
The interaction of "late" and implicit collect is not handled so in
generalizations := self.eSuperTypes->collect(t | t.late resolve(UML::Generalization))
the direct association of "late" with asssignment is no longer direct; the "late"s must be aggregated. Potentuially this may occur in arbitrary complexd expressions including mapping calls!
An alternate multi-pass interpretation of "late" is given.
This seems like the correct approach; an MtoM transformation from a with-late to multi-pass without-late transformation.
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)
{ name:=n; type:=t; }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?
In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so:
package QVTBase
context TypedModel
def: allUsedPackage() : Set(EMOF::Package)
= self.dependsOn.allUsedPackage()>asSet()>union(self.usedPackage)
endpackage
package QVTRelation
context RelationImplementation
inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package)
endpackage
This is not satisfied by almost the last line of RelToCore in 10.3:
enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me);
which seems to have output second.
-----------------------------------------------------
More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation.
This semantic clumsiness could be resolved, if, within a transformation,
relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output.
The RelToCore example can then be mended by declaring that:
RelToCore(...) extends utils::CopyUtilities
and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation.
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.
The whole Concrete Syntax section deserves a much more substantial description.
In particular...
The mechanism by which a package name is located is unresolved, perhaps deliberately,
but the omission should be explicit.
What constraints exist on forward referencing of names?
Transformations and mappings could be ordered so that forward references are avoided,
but large modules benefit from an alphabetical ordering of elements, so requiring
a parser friendly order is not user friendly.
As interpretation from the especification (pag 104), the way of adding new operations to OCL predefined types is creating new Typedef instances
which must have the OCL predefined type as the base type. The new operations are added to this new typedef. However there are several problems:
1. The specification doesn't provide any name for these typedefs.
2. The specification doesn't specify which type (QVT typedef or OCL predefined type) should be used when referencing such OCL predefined types in a QVTo transformation.
Solution for 1).
Suggestion a: Name the typedef with the same name of the base type. This provokes name's clash with the predefined type's name, due to there are two different types from two standard libraries
which have the same name. A possible solution, would be expliciting that typedefs (aliases) will never clash its name with its base type.
Suggestion b: Name the tpyedef with a different name, such as QVToXXXXXX or XXXX_Alias.
Solution for 2).
Suggestion a: Taking the typedef as the referenced type in QVTo transformations.
Suggestion b: Taking the OCL predefined type as the referenced type in QVTo transformations.
Suggestion c: Considering resolution of issue 13168, so that only OCL predefined exists, and therefore, the only type which can be referenced.
It's a little bit weird having 2 different types (a type, and its alias typedef) which represent just the same type, specially when they are related by a reference.
My solution's preference in order are:
c) Just having one type to refer.
a) Since the typedef "extends" the behaviour of the predefined type (adding new operations), the former must be the referred one.
b) The OCL predefined type is referenced, but we must taking into account that operations added to the typedef are available.
issue closed, duplicate of issue # 13252
The concrete syntax for a query uses a pathNameCS, yet the query is defined
within the scope of a transformation.
How should a scoped name be interpreted?
? is a scoped name only applicable for declaring externally definedc queries ?
Comment:
Concrete syntax is incorrect.
Resolution:
The concrete syntax of the production <query> given in Appendix A of this report is changed as follows:
<query> ::= 'query' <identifier>
'(' [<paramDeclaration> (',' <paramDeclaration>)*] ')' ':' <TypeCS>
(';' | '
')
Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report.
The concrete syntax for transformation supports multiple extension.
The abstract syntax supports only single extension.
Suggest: change the concrete syntax.
Comment:
Concrete syntax is incorrect.
Resolution:
The concrete syntax of the production <transformation> given in Appendix A of this report is changed as follows:
<transformation> ::= 'transformation' <identifier>
'(' <modelDecl> (';' <modelDecl>)* ')'
['extends' <identifier>]
'
'
Replace the content of section 7.13.1 and 7.13.2 by the new content given in Appendix A of this report.
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) { // there is no syntax to bind the actual exception caught to a variable or to retrieve it in an except expression. };except (Exception e)
{ // do something with the exception caught: e };
or:
try
{ // ... }except (Exception1 e1, Exception2 e2)
{ // do something with the exception caught: e1 or 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
{ self->closure(self.superClass) // closure might not be standard collection op but I used it just to demonstrate the point }relation B {
checkonly domain source c:Class {
allSuperClass = super:Class
}
}
}
does this make sense?
No Data Available
Original file: ptc/07-07-08.zip
OMG Document Nmber: formal/2008-04-03
Standard document URL http://www.omg.org/spec/QVT/1.0/PDF
On Page 2 (Page 18 in PDF) there is a wrong reference in chapter 2.2 Language Dimension at 1. and 2.
"Core; The Core language is described in Chapter 11.."
"Relations: The Relations language is described in Chapter 9. ..."
It should be 9 and 7 
The Chapter 10 reference is wrong too.
Further wrong Chapter 9/11 references exist in the main text.
The above references are manual text that do not use FrameMaker cross-reference facilities.
Loading the QVT 1.1 FrameMaker files reveals 6 unresolved cross-references.
OMG specifications have Clauses not Chapters.
Sections 8.3.4.7 and 8.3.4.9, page 110:
Operation signatures for 8.3.4.7 and 8.3.4.9 do not correspond with the title of sections.
Please update 8.3.4.7 from "Element::subobjects(OclType) : Set(Element)" to "Element::allSubobjectsOfType(OclType) : Set(Element)".
Please update 8.3.4.9 from "Element::subobjectsOfKind(OclType) : Set(Element)" to "Element::allSubobjectsOfKind(OclType) : Set(Element)"
yes
Section 8.2.2.7, page 95:
The text "list[condition]; // same as list->xselect(i; condition)" should read "list[condition]; // same as list->xselect(i | condition)". Notation of imperative iterate expressions state that the condition section must be separated from prior artifacts (iterators or target initializations), where present, by a "|" character, not a semicolon ";".
Duplicates in part Issue 13282.
Disposition: See issue 13282 for disposition
Section '8.3.5.3 rootObjects' has a typo in the signature of the operation defined: Model::rootobjects() : Set(Element). In compliance with the surrounding definitions and with the title of the section itself, it should read 'Model::rootObjects() : Set(Element), that is, the first letter of 'Objects', capitalized.
Suggestion: Replace 'Model::rootobjects() : Set(Element)' by the new 'Model::rootObjects() : Set(Element)'
yes
Problem's text: // column := self.attribute->forEach new(a) Column(a.name,a.type.name);
discussion: the foreach exp is not well written:
suggestion: replace the text above by "// column := self.attribute->forEach(a)
;
yes
Problem's text: OperationCallExp
discussion: From figure 8.4 and 8.6, we can guess that LogExp should inherits from both, OperationCallExp and ImperativeExpression.
suggesition: add ImperativeExpression as a LogExp's superclass.
yes
Problem's text: part : DictLiteralPart [*]
{composes,ordered}discussion: Do the parts need to be ordered ?. The diagram doesn't show it.
suggestion: Remove ordered or update the diagram.
Yes. A dictionary does not need go be ordered.
Already correct in the QVT 1.1 models
Problem's text: (see DictLiteralValue).
discussion: DictLiteralValue deosn't exist. It must be DictLiteralExp.
suggestion: Replace "DictLiteralValue" by "DictLiteralExp".
yes
Section 8.3.4.11, page 110:
The operaton "Element::deepclone()" should read "Element::deepClone()". I understand that "Subobjects" do not capitalize the leading 'o' for the word "objects", but in all other cases it seems consistent to use capitals for words' leading letters. Both the title and the operation signature should be updated accordingly. This issue is similar to 13913.
The same applies to Section 8.3.7.3 (page 113), "defaultget", which would read "defaultGet", and 8.3.8.4 (page 114), "joinfields", which would read "joinFields". Again both the titles and the operation signatures should be updated accordingly.
No Data Available
Problem's text: The OCL standard library is an instance of the Library metaclass.
discussion: It should obviously refer to the QVT Operational Mapppings standard library.
suggestion: replace "OCL" by "QVT Operational Mappings".
yes
Problem: There are two figures to represent the type extensions.
suggestion: Remove the first figure and name the sencond one as Figure 8.7 - Imperative OCL Package - Type extensions
There are actually 5 sub-diagrams of which the first two are duplicated by the third and fourth;
presumably an editing artefact when the fifth was introduced for ListLiteralExp.
Problem's text: elsePart : OclExpresion
{composes} [0..1]" and "[0..1].
Yes, and correct spelling of OclExpression too.
Problem's text: condition: OclExpression [1]
{composes}discussion: the condition is optional.
suggestion: Replace "[1]" by "[0..1]".
Yes.
Already correct in the QVT 1.1 models
Problem's text: compute (x:MyClass := self.getFirstItem()) while (x<>null)
{ }discussion: the compute expression's body requires the enclosing braces
Suggestion: replace the text above by "compute (x:MyClass := self.getFirstItem()) { while (x<>null) {
}}"
;
Collection(T)::forOne(source, iterator, condition,body) =
forEach (i | condition)
Yes.
Yes.
Problem's text:
1.ReturnExp::value association my have multiplicity [0..1] in the diagram
2.TryExp::catchClause association should be called exceptClause
Discussion:
1. It seems that the returned value of a return expression might be optional.
2. Since the diagram and textual descriptioon are different, I'm not sure which was the original intention of the name of this reference. Reading the description's text
and the opposite role name (exceptOwner), I guees that the name must be "exceptClause".
suggestion:
1.In ReturnExp::value association replace mutiplicity 1 by multiplicity [0..1]. In the text is well described.
2.In TryExp class change change the "catchClause" by "exceptClause"
Discussion: Ordered doesn't make sense in a univalued reference.
Suggestion: remove "ordered".
Yes.
Yes.
Yes.
Already correct in the QVT 1.1 models
Problem's text: list[condition]; // same as list->xselect(i; condition)
discussion: From the specified notation, the xselect expression is not well written.
suggestion: replace ';' by '|'
yes
Problem's text: target : Variable [0..1]
discussion: composes is missed. In the diagram is correctly represented the association's feature.
suggestion: add the following text to end of the line "
Yes.
Already correct in the QVT 1.1 models.
Problem's text: // shorthand for list->xcollect
object X
);
yes
Problem's text: "When an object expression is the body of an imperative collect expression (see xcollect in ImperativeLoopExp)"
discussion: the text should point ImperativeIterateExp instead.
suggestion: replace ImperativeLoopExp by ImperativeIterateExp.
yes
Problem's text: /instantiatedClass: Class [0..1](from InstanciationExp)
discussion: wrong description.
Suggestion: replace the text above by "/instantiatedClass: Class [1](from InstantiationExp)"
note that in /extent reference, "(from InstanciationExp)" must be also replaced by (from instantiationExp)"
Yes and correct the erroneous bounds change on the spurious redefinition.
On Page 130 there is written:
"The dottet arrows in the picture below sho the dependencies between the patterns, with the following interpretatoin: ..."
But there is no picture 
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)
{ name := name }constructor MyClass::MyClass(name : String)
{ name := name + "v2" }How can the instantiation expression refer the different constructor ?
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]
{composes}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
The OCL 2.0 spec has a 32 page section on concrete semantics.
QVTr has 1.5 pages of BNF but no explanation.
In particular:
What are the semantics of 'import' which has no abstract counterpart?
Where is the explanation of the role of [ '
' ] in a <domain>?
Where is the instruction on how to treat the "_" identifier?
No Data Available
The concrete syntax does not specify a parsing goal.
If the first element (Transformation) is taken to be the goal, most of the rest
of the grammar is orphaned.
Suggest:
TopLevel ::= (Transformation | Mapping)*
simple change
A Direction defines the packages used by each direction domain.
Nothing defines the (additional) packages used by the middle area. For instance
there is no place to specify the trace class model generated by the RelationToCore
transformation. With many transformations and mappings in a QVTcore it does not
seem appropriate to overload TransformationName or MappingName as a hook to
reference the appropriate middle meta-models; different Mappings may have distinct
middle meta-models; multiple transformations may share the same middle meta-model.
(Core should be a first class programming language, not just one that supports
the eccentricities of a RelationToCore conversion.)
Suggest: a DirectionName between "where" and "(" in Mapping.
This reads very naturally:
map ...
check left (...
enforce right (...
where middle (...
But we also need to fix the Abstract Syntax. As a minimum a Mapping needs a
middle-typed-model property to capture the missing information. With this addition
a Mapping duplicates so much of a CoreDomain/Area, that it is more appropriate
to eliminate Area altogether, merging it into CoreDomain. Area is eliminated
from Mapping, and added as an additional CoreDomain referenced by the middleDomain
property.
So:
CoreDomain extends Domain
CoreDomain.variables : RealizedVariable [0..*] composed
CoreDomain.bottomPattern : BottomPattern [1] composed
CoreDomain.guardPattern : GuardPattern [1] composed
Mapping extends Rule
Rule.domain : Domain [0..*] composed (must be at least CoreDomain[3])
Mapping.specification - no change
Mapping.local - no change
Mapping.context - no change
Mapping.middle : CoreDomain [1] (must be in Rule.domain)
The suggested changes may be convenient but they are not necessary:
For uniformity, collectselect should be renamed xcollectselect following the distinction
between collect and xcollect (imperative version).
This is an unpleasant but worthwhile change. Implementations may choose to provide both spellings
for transitional compatibility.
If collectselect changes, so too should collectselectOne, collectOne and selectOne, since their
computation is imperative too.
Style. Use same font and presentation as 7.12.3, 8.4.
Typo. Remove '(' preceding '","' in BottomPattern.
Typo. Remove 'e' in 'Assignement'.
Some aspects of the presentation are easily resolved, but replacing e.g. DirectionName to
<directionName> is not worthwhile. These will all change to e.g. DirectionNameCS once OCL 2.5
aligned grammars are provided.
The '(' is needed as part of an 'optional' for which the prevailing BNF is [].
Assignement is a simple typo.
GuardPatterns and BottomPatterns with Variables but without Constraints must end with a '|'.
This is inelegant. Better to only require '|' as prefix to constraints (or to require it always).
Suggest:
GuardPattern ::= Variable ("," Variable)* ["|" (Constraint ";")+]
similarly BottomPattern
Simple change.
Issue 9379 made Pattern.bindsTo a non-composition.
This deprives Core of any parent for its non-realized variables.
Suggest: move BottomPattern.realizedVariables to CorePattern.variables.
CorePattern.variables then composes all variables declared for the pattern. A class-type
check of RealizedVariable/Variable derives the 'isRealized' property.
It is convenient to keep realized and unrealized variables separate to avoid unnecessary isRealized
tests.
Just add CorePattern.variables to compose the unrealized variables.
9.3 Assignment.slotExpression should be PropertyAssignment.slotExpression (VariableAssignments have no slot)
Simple move already in QVTcore.xml
Consider using asTuple instead of tuple keyword for TupleExp since asX() is usually
used for conversions.
There is no TupleExp or asTuple() in QVT 1.0 or 1.1 but there is an asOrderedTuple() with the
resolved description. So it appears that a variant of the suggested resolution made it into QVT 1.0.
Disposition: Closed, No Change
The concrete syntax defines 'realized', but section 10 consistently uses 'realize'.
Suggest: 'realize'
The concrete syntax defines 'realized' for a single element of a comma-separated list.
Section 10 appears to expect that 'realized' is a prefix to a comma-separated list.
Suggest: 'realize' is a comma-separated list prefix.
(semi-colon separation is available for distinct realize/not-realize.)
Use 'realize' as a keyword in the concrete syntax.
Use 'realized' as an adjective in editorial text, model names; e.g. RealizedVariable
Section 10 uses anonymous maps for composed mappings. The Concrete Syntax
does not allow this. Similarly, an 'in' is not appropriate for a composed mapping.
Suggest:
ComposedMapping ::= "map" [MappingName] ["refines" MappingName] MappingPatterns
where MappingPatterns is the common part of Mapping.
simple change
There is no concrete syntax for enforcement operations.
Suggest: a BottomPattern Constraint may also be
'create' OperationCallExpCS
'delete' OperationCallExpCS
simple change
The concrete sysntax allows guard patterns to have assignments. The abstract syntax does not.
Suggest: GuardPattern uses Predicate rather than Constraint
Simple change
Issue 19146 resolution makes the behaviour of List clear.
Dict clarified below and a typo
String clarified below.
allSubojectsOfType see Issue 13989 resolution.
raisedException Yes. But the Status operations are misleadingly under Transformation. Add a
missing section heading.
asList(T) Yes, supersedes Issue 19146 resolution.
PS see Issue 19146 resolution.
toLower Yes. Make it clear that all String operations are immutable. Redirect OCL 2.4 synonyms to
OCL 2.4 deprecating the synonyms. We can also fix some bad typos, Boolean rather than
Integer/Real returns, references to the non-existent Float type and spurious matchXXX arguments.
lastToUpper this seems to be a major bloat. Either name or description could change. Since the
name exists with an obvious functionality, correct the description.
PS Yes
Problem's text: "/body: BlockExp [0..1]
{composes} (from ImperativeOperation) (from ImperativeOperation)
The operation body of the constructor. It should necessarily be
a ConstructorBody instance.
Yes. But we can go all the way by modeling the ConstructorBody constraint
Problem's text: "the invocation of the operation returns a tuple"
discussion: it could be understood as an OCL Tuple, which doesn't apply.
suggestion: Replace "a tuple" by "an ordered tuple".
The usage or OrderedTuple seems misguided since an ordinary OCL Tuple does very similar things
without a positional hazard and without noticeable lexical overhead.
Only the case of TupleLiteralEx/UnpackExp is plausibly defined in QVT 1.1 and neither of the QVT
implementations (SmartQVT or Eclipse QVT) support OrderedTuple.
Therefore eliminate TupleLiteralExp, UnpackExp and OrderedTupleType and
OrderedTupleLiteralPart.
Note that there are no editing instructions for the grammar. It is not clear that OrderedTuples were
really supported at all.
In the spirit of issue #13228, and in conversation with Mariano Belaunde, we think it is worth considering also adding the following operations to mutable lists. As specific usages of 'removeAt()': 'removeFirst()' and 'removeLast()'. And also: 'removeAll(Collection(T))'. Notice that this one includes the case of removing values specified inside mutable lists as long as ListType inherits CollectionType. Suggestion: Add the following text to section 8.3.8: - List(T)::removeFirst() : T Removes the first value of the mutable list. The return value is the value removed. - List(T)::removeLast() : T Removes the last value of the mutable list. The return value is the value removed. - List(T)::removeAll(Collection(T)) : Void Removes from the mutable list all the values that are also present in the specified collection.
And remove() from Issue 13228. A List is not a Collection so we need two removeAll's.
Additional operations in Issue 19146.
Disposition: See issue 19146 for disposition
For 'removeAt' I specify 'one' as the starting index value. Suggestion: - List(T)::remove(T) : T Removes a value from the list. - List(T)::removeAt(int) : T Removes a value from the mutable list at the given position. The index starts at one (in compliance with OCL convention). The return value is the value removed from the mutable list. - List(T)::clear() : Void Removes all values in the mutable list.
Yes. Revised wording in 132 is explicitly one-based.
Disposition: See issue 19146 for disposition
There is no support for transformation extension in the QVT Core concrete syntax.
Suggest: re-use the concrete syntax of QVT Relation, allowing "extends x" to follow
a transformation declaration.
example:
transformation yy::umlRdbms
{ middle imports tuml2rdbms; uml imports umlMM; rdbms imports rdbmsMM; }extends base1, xx::base2, base3
Simple change. Names are left vague pending resolution of Issue 10935.
The QVT Relation Concrete Syntax makes no provision for organisation of transformations
in a package hierarchy; all transformations are presumed to be in root packages.
Suggest: change <identifier> to <transformationId> in both definition and reference
of the <transformation> production, and define <transformationId> as <pathNameCS>.
simple change
Problem's text: in MappingParameter class: "refiningParameter" and "refinedDomain".
discussion: while a mappingOperation refines a Relation, a mappingParamer should "refer" a RelationDomain. In the text of MappingParameter section, the concept of "refers" is used several time instead of "refines".
suggestion: replace "refiningParameter" and "refinedDomain" by "referringParameter" and "referredDomain".
Duplicates in part Issue 12527.
Disposition: See issue 12527 for disposition
Problem's text: "configuration property UML::Attribute::MAX_SIXE: String
discussion: providing a context to a configuration property doesn't seem to make sense.
suggestion remove "UML::Attribute::"
It's not obviously sensible, but is it actually wrong?
If there are many configuration properties, it may be convenient to partition them hierarchically. cf.
java.vm.specification.vendor.
The punctuation is however confusing; add a space.
Suggestion: Change original explanation text: "Removes an object of the model extent. All links that the object have with other objects in the extent are deleted." by something similar to the following one: "Removes an object from the model extent. The object is considered removed from the extent if it is not a root object of the extent, and is not contained by any other object of the extent."
simple change
The explanation of the operation: 'List(T)::insertAt(T,int) : Void' in Section 8.3.8.3 has a mistake concerning the index associated with the first element for OCL collections. The index starts at one, '1', not zero, '0'. Suggestion: Substitute the word 'zero' by the word 'one', so that the text reads: "The index starts at one (in compliance with OCL convention)."
Yes. Improved wording in Issue 19146.
Disposition: See issue 19146 for disposition
Problem's text: "overriden: Operation [0..1]"
discussion: the overriden operation should be an ImperativeOperation. This is correctly showd in the diagram.
suggestion: Replace "Operation" by "ImperativeOperation".
Yes.
Already correct in the QVT 1.1 models
Problem's text: "isubclass of Module (see: ImperativeOCL package)"
Discussion: Module doesn't belong to ImperativeOCL package.
Suggestion: remove "(see: ImperativeOCL package)"
simple change
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.
Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.
An Ecore file resolving these anomalies is attached
These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.
ContextualProperty .initExpression is Issue 13270
ObjectExp.instantiatedClass is Issue 13276
ObjectExp. initializationOperation is Issue 19021
ObjectExp. body is Issue 19022
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.
Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.
An Ecore file resolving these anomalies is attached.
These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.
CatchExp.exceptionVariable/CatchExp.exception changes are Issue 15997
Remove UnpackExp is Issue 13268
Remove OrderedTupleType is Issue 13268
Remove OrderedTupleLiteralExp is Issue 13268
Remove OrderedTupleLiteralPart is Issue 13268
Add InstantiationExp.initializationOperation is Issue 19021
QVT Operational Mappings claims in the overview section, the use of ListLiteralExpression (for instance to initialize a list), as in the section 8.1.14 (Pag 55) is shown. However, there is no way to represent this literal expression in the abstract syntax, due to: 1. There is no ListLiteralExp in the imperativeOCL package. 2. CollectionLiteralExp (from EssentialOCL) can't be used. There is a way to initialize lists, making use of the asList operator which appears in the Standard Library section (8.3.85 / Pag 112), however this should be clarified. Therefore, two possible solutions could be taken: Suggestion 1: Create a ListLiteralExp which should extend CollectionLiteralExp (From EssentialOCL). Suggestion 2: Update the overview examples, to properly ilustrate how to initialize lists. Besides, the grammar ( Pag 124) )should be consequently changed as well. (List
{ 1, 2, 3, }literal expressions wouldn't be supported).
No Data Available
Section 8.2.2.22 provides no guidance on the meaning of:
var x:X;
var y:Y;
var z:Z;
...
var (x:X,y,z) := self.foo();
[If one of the variables in the left hand side, does exist ...]
Possible interpretations
a) x:X is always a syntactical shorthand.
Therefore the above is a shorthand for:
var x:X;
var y:Y;
var z:Z;
...
var x:X; var (x,y,z) := self.foo();
and consequently there is duplicate variable definition to be
reported as a semantic error.
b) x:X is a convenience type check assertion
Therefore the above is a shorthand for:
var x:X;
var y:Y;
var z:Z;
...
var (x,y,z) := self.foo();
with a successful validation of type consistency.
c) x:X is not available as a shorthand
Therefore the above is a syntax error.
------------------------------------
Interpretations b) and c) require semantic knowledge to resolve syntactic
sugar.
Interpretation a) is an unambiguous syntax shorthand that could be more
clearly
described by:
"The following example demonstrates a shorthand in which variables are both
declared
and assigned.
var (x:X,y:Y,z) := self.foo();
Any variable name qualified by a type name is both a declaration and an
assignment,
with all declarations proceding the unapack assignment.
The above example should therefore be analyzed as:
var x:X; var y:Y; var (x,y,z) := self.foo();"
---------------------------------------------------------------------
Recommend interpretation a) with the above textual clarification.
No Data Available
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.
Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.
An Ecore file resolving these anomalies is attached.
'nsURI' for 'EMOF' should be 'http://schema.omg.org/spec/MOF/2.0/emof.xml' rather than 'http:///emof.ecore'
'name' for 'EMOF' should be 'EMOF' rather than 'emof'
'name' for 'Property.isID' should be 'isID' rather than 'isId'
'Factory' should be defined
'ReflectiveCollection' should be defined
'ReflectiveSequence' should be defined
'Comment.body' should be defined
'Factory.package' should be defined
'Element.tag' should be undefined
'eOpposite' for 'Tag.element' should be undefined
'lowerBound' for 'Operation.class' should be '0' rather than '1'
'lowerBound' for 'Type.package' should be '0' rather than '1'
'lowerBound' for 'Property.class' should be '0' rather than '1'
'ordered' for 'Class.superClass' should be 'false' rather than 'true'
'ordered' for 'Comment.annotatedElement' should be 'false' rather than 'true'
'ordered' for 'Element.ownedComment' should be 'false' rather than 'true'
'ordered' for 'Operation.raisedException' should be 'false' rather than 'true'
'ordered' for 'Package.nestedPackage' should be 'false' rather than 'true'
'ordered' for 'Package.ownedType' should be 'false' rather than 'true'
'ordered' for 'Tag.element' should be 'false' rather than 'true'
'defaultValueLiteral' for 'Class.isAbstract' should be 'false' rather than undefined
'defaultValueLiteral' for 'MultiplicityElement.isOrdered' should be 'false' rather than undefined
'defaultValueLiteral' for 'MultiplicityElement.isUnique' should be 'true' rather than undefined
'defaultValueLiteral' for 'MultiplicityElement.lower' should be '1' rather than undefined
'defaultValueLiteral' for 'MultiplicityElement.upper' should be '1' rather than undefined
'defaultValueLiteral' for 'Property.isComposite' should be 'false' rather than undefined
'defaultValueLiteral' for 'Property.isDerived' should be 'false' rather than undefined
'defaultValueLiteral' for 'Property.isReadOnly' should be 'false' rather than undefined
'Element.container()' should be defined
'Element.equals(object)' should be defined
'Element.get(property)' should be defined
'Element.getMetaClass()' should be defined
'Element.isSet(property)' should be defined
'Element.set(property,object)' should be defined
'Element.unset(property)' should be defined
'Extent.elements()' should be defined
'Extent.useContainment()' should be defined
'Factory.convertToString(dataType,object)' should be defined
'Factory.create(metaClass)' should be defined
'Factory.createFromString(dataType,string)' should be defined
'ReflectiveCollection.add(object)' should be defined
'ReflectiveCollection.addAll(objects)' should be defined
'ReflectiveCollection.clear()' should be defined
'ReflectiveCollection.remove(object)' should be defined
'ReflectiveCollection.size()' should be defined
'ReflectiveSequence.add(index,object)' should be defined
'ReflectiveSequence.get(index)' should be defined
'ReflectiveSequence.remove(index)' should be defined
'ReflectiveSequence.set(index,object)' should be defined
'Type.isInstance(object)' should be defined
'URIExtent.contextURI()' should be defined
'URIExtent.element(uri)' should be defined
'URIExtent.uri(element)' should be defined
Unnavigable 'opposite' of 'Class.superClass' should be modelled
Unnavigable 'opposite' of 'Element.ownedComment' should be modelled
Unnavigable 'opposite' of 'Package.nestedPackage' should be modelled
Unnavigable 'opposite' of 'Property.opposite' should be modelled
No Data Available
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in qvt_metamodel.emof.xml in the 07-07-08 ZIP.
Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the EMOF was notionally auto-generated.
EMOF files resolving these anomalies are attached.
No Data Available
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in QVT_1.0.mdl in the 07-07-08 ZIP.
Since the diagrams are printed from QVT_1.0.mdl all the QVT problems also
occur in 08-04-03.
Textual errors in 08-04-03 cannot be analyzed automatically. There are
so many that a thorough proof read is required combined with a statement
that the diagrams only are normative
The QVT 1.0 diagrams and models were originally from the models in the QVT_1.0.mdl file. The
diagrams rely on proprietary tooling. Unfortunately some independent evolution occurred and so there
were many inconsistencies.
Consistent Ecore/EMOF files from Eclipse were endorsed as the QVT 1.1 non-normative files.
For QVT 1.2, the primary non-normative files are UML models derived from the QVT 1.1 Ecore files.
The diagrams are redrawn from the UML using the Open Source Papyrus tool. The diagrams are
drawn to assist understanding rather than to squeeze as much as possible into the useable area. The
redrawn diagrams are therefore larger/more numerous. (Unfortunately Papyrus does not support
text is added manually.) In all other respects diagrams and UML non-normative
files should be consistent.
The multiplicity of unnavigable opposites was not present in the Ecore files and so is set to 0..1 for
compositions, and 0..* for non-compositions by the Ecore2UML conversion. This causes a few 1
multiplicities to change to 0..1. The 1 multiplicities were needlessly restrictive prohibiting re-use of
classes, so the 0..1 seems better. Perhaps we should have an issue to change navigable containers
too.
TemplateParameterType is missing from the diagrams since it is not preset in the non-normative files.
TemplateParameterType has no practical utility implementations are required to work magic for
templates types which may or may not involve the TemplateParameterType class.
I find that when I consult the specification, I want to see all the diagrams, which is hard when they are
spread thoughout the AS section. All diagrams are therefore brought to the start of their AS section.
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.
Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.
An Ecore file resolving these anomalies is attached
These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text. CorePattern.variable is Issue 10938
Assignment.slotExpression is Issue 11108
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.
Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.
An Ecore file resolving these anomalies is attached
These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.
Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.
An Ecore file resolving these anomalies is attached.
These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.
No: Domain.typedModel lowerbound of 0 is correct; primitive domains have no TypedModel
Rule.transformation lowerbound change is Issue 11825.
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.
Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.
An Ecore file resolving these anomalies is attached.
No Data Available
Use of automated tooling to support comparison of the models developed
initially as part of the Eclipse GMT/UMLX project and being transferred to the
Eclipse QVT Declarative/QVT Operational Mappings Projects reveals the following
errors and anomalies in emof.ecore in the 07-07-08 ZIP.
Note that these errors and anomalies are not the same as those separately reported
for the QVT_1.0.mdl from which the Ecore was notionally auto-generated.
An Ecore file resolving these anomalies is attached.
These changes mostly affect non-normative files which were corrected when QVT 1.1 issued revised
files based on Eclipse QVT contributions. However a few changes remain to be resolved in the main
text.
CollectionTemplateExp.rest/member lowerBound is Issue 11826.
PropertyTemplateItem.value multiplicity is right in diagram not text
UnpackExp should not compose targetVariable There are a lot of issues in this section: 1. name of Variable association was not updated to targetVariable. 2.
{ordered}is missed. 3. variable should not compose. They should refer for instance a previously defined VarInitExp::referredVariable. 4. Parenthesis are missed in the first example (notation section). 5. Remember to update the diagram in figure 8.6 (pag 86). Note: These proposed changes are needed if you want to allow unpacking OrderedTuples using previously defined variables (which makes sense). Another (worst) alternative is forcing to declare new variables . In this case, the notation section should be changed.
No Data Available
There is no support for queries in the QVT Core concrete syntax.
Suggest: re-use the concrete syntax of QVT Relation, except that the query
is defined at global scope and so must be qualified by the name of a
transformation defined in the same source unit.
example:
query txName::getStringSize (someString:String): Integer
{ someString -> size() }Simple change. Names are left vague pending resolution of Issue 10935.
Problem's text: // shorthand for mylist->forEach
i.late resolve(Table)
discussion: EBNF and forExp suggest using always braces to enclose the forExp body.
Suggestion: Enclose the forEach's body with '
'.
yes
Problem's text: ->forEach (cl) cleaningTransf.map removeDups(cl);
discussion: EBNF and forExp suggest using always braces to enclose the forExp body.
Suggestion: Enclose the forEach's body with '
'. Note that there are two forExps in this section
yes
Problem's text: This is called the “collect” shorthand
discussion: Since OCL provides a "collect" shorthand (f.i. doing aCollection.anOperationCall()), I would rather call "xcollect" shortand to avoid confusions.
suggestion: Replate "collect" by "xcollect".
OCL provides an 'implicit collect' shorthand, so 'imperative collect' is a better contrast
Problem's text: Superclasses OperationCallExp
discussion: It should extend ImperativeCallExp instead. The diagram is well showed.
suggestion: Replate "OperationCallExp" by "ImperativeCallExp".
Duplicates in part Issue 12527.
Disposition: See issue 12527 for disposition
missed text: there is a missed text related to the initExpression association.
discussion: If we have a look to the diagram in figure 8.2, we may realize that a description of the initExpression association is missed.
suggestion: include the following text in the association's description:
initExpression: OclExpression [0..1]
An optional OCL Expression to initialize the contextual property.
Yes.
Already correct in the QVT 1.1 models
Problem's text: // shorthand of self.ownedElement->xcollect i.map class2table();
discussion: It seems that the imperativeIteratExp has not been correctly notated.
suggestion: replace the text above by: // shorthand of self.ownedElement->xcollect(i | i.map class2table());
yes
Issue : QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles
UML models drawn with Rose allow an opposite role to be defined for a
uni-directional role. This practice is common but haphazard in UML Infrastructure,
EMOF, OCL and QVT specification diagrams.
However EMOF provides only the (run-time) usage of the model and so any
EMOF (or Ecore) model generator must strip non-navigable opposite roles.
QVT matches models at compile-time and matching has no inherent need to
observe navigation constraints. This is amply demonstrated by the Rel2Core
transformation that makes extensive use of, for instance, the inverse Key to Class
relationship.
----------------------------------
Problem: some QVT transformations require names for non-navigable opposite roles,
but those names cannot be present in layered multi-package EMOF meta-models.
The Rel2Core transformation of Section 10.3 cannot be implemented with QVT 1.0.
----------------------------------
Abandoning EMOF (or Ecore) compliance in favour of perhaps CMOF seems unacceptable.
Changing EMOF (or Ecore) to incorporate opposite roles is not possible because
an EMOF specification cannot be extended to include the opposite role of every
meta-model that will ever exist.
Even if it was, there would be a substantial delay until meta-modelling tools
adopted the change and a problem with poor standardisation and global
non-interference of opposite rolenames.
QVT must therefore support definition of non-navigable role names as part of a
transformation. ModelMorf provided a very practical concrete syntax solution,
whereby the reserved operation opposite(qualified-role-name) could be used as
the missing opposite role-name wherever a forward role-name could be used.
An upward compatible abstract syntax requires an additional is-opposite qualifier
for each referred property.
So for
QVTCore::PropertyAssignment add isOpposite:Boolean[0..1] default false.
QVTTemplate::PropertyTemplateItem add isOpposite:Boolean[0..1] default false.
QVTRelation::Key add oppositeParts:Property[0..*]
{ composed }with the constraint that parts.size() + oppositeParts.size() > 0
Perhaps QVTOperational::Module needs an additional oppositeConfigProperty and
QVTOperational::ContextualProperty needs an additional isOpposite too.
No Data Available
7.11.2.3 and Figure 7.6 both impose a lowerBound of 1 on CollectionTemplateExp.member and CollectionTemplateExp.rest.
However, the concrete syntax permits an empty match. This empty match is exploited in the
UnsharedWhenVarsToMgVars relation in Section 10.
Suggest:
Change CollectionTemplateExp.member to [0..*]
Change CollectionTemplateExp.rest to [0..1]
Add a sentence to clarify the empty match semantics.
yes
Mapping is a Rule and Rule.transformation has unit multiplicity and is a container.
Therefore Rule.context can never be a container.
This could be fixed in a number of ways:
Fix 1: Change Rule.transformation to 0..1
--> allow hierarchical Rule containment
--> all Transformation rules are distinctly named
– no representation change
– minor semantic relaxation for QVTr/QVTo
– minor semantic surprise for QVTc - composed mapping has null Mapping.transformation.
Fix 2: Change Rule.context to not composes
--> require flat Rule containment
--> Transformation can have multiple unnamed rules
– no change for QVTc/QVTo
– representation change for QVTc
Fix 3: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.context[1]
Redefine Rule.transformation[1] as a derived property
Remove mapping.context (inherited from Rule)
– Doesn't work: context needs to be NamedElement to be either Rule or Transformation
Fix 4: Change opposite of Transformation.rule from Rule.transformation[1] to Rule.owningTransformation[0..1]
Redefine Rule.transformation[1] as a derived property
Rule.transformation := owningTransformation
Mapping.transformation := if context then context.transformation else owningTransformation endif
– no representation change
– minor semantic relaxation for QVTr/QVTo
Recommend 4.
Rule.transformation changed to 0..1 in QVTCore.xml for QVT 1.1.
Fix 4 doesn't seem that wonderful, so go with the obvious Fix 1. And why prohibit all reuse of Rule
outside a Transformation?
Text of Clause 7.2.3 is unclear:
Suggested rewrite:
(1) Add the following as the first two sentences of the first
paragraph.
"In the evaluation of a Transformation, one or more domains are
specified as target. The phrase 'executing in the direction of [some
domain]' refers to these domains."
Then change a few words in the paragraph as suggest by the text in []
below:
"Whether or not the [change "the" to "a"] relationship maybe [should
be "is"] enforced is determined by the target domain, which may be
marked as checkonly or enforced. When a transformation
[change "transformation" to "relation"] is enforced
[change "enforced" to "evaluated"] in the direction of a checkonly
domain, it is simply checked to see if [change "if" to "whether"]
there exists a valid match in the relevant model that satisfies the
relationship. When a transformation executes in the direction of the
model of an enforced domain, if checking fails, the target model is
modified so as to satisfy the relationship, i.e. a
check-before-enforce semantics."
[Strike the words beginning with "i.e." "check-before-enforce" is new
terminology that is neither defined nor helpful.]
Yes, we can certainly try to be clearer.
Section 7.13.5 Relation BNF
The grammar rule for template is incorrect (It does not allow a
template to have embedded within it another template. The example in
Appendix A will not compile with such a grammar.)
It says:
<propertyTemplate> ::= <identifier> '=' <OclExpressionCS>
It should says:
<propertyTemplate> ::= <identifier> '=' ( <template> |
<oclExpressionCS
No Data Available
It is not clear when and how you choose a top-level and not-top-level relation. Primitive domains, the reason for them and the use of them, are not explained although they are used in the Relation language example A1.1.1
'top' is explained clearly in Section 7.2.2 Top-level Relations.
'primitive' is a bit of a secret
have built a transformation engine based on QVT relations. The QVT relations example in Annex A contains a 'function' PrimitiveTypeToSqlType at the end of the example in textual syntax. This example is the only relations example in the whole spec. Nowhere is the semantics of 'function' defined nor contains the grammar of the concrete syntax a function keyword. However, 'query' is defined. Is 'function' another name for 'query'?
QVT Base has a Function.queryExpression.
QVT 1.1 added the mapping from queryCS to Function.
Not 'nowhere' but we can do better
9.17.12 EnforcementOperation, Figure 9.3
----------------------------------------
The definition: "operationCallExp : OperationCallExp[1]"
and the corresponding "*" enforcementOperation multiplicity in
Figure 9.3 provides a consistent definition of a shared reference
to a Call expression. There is no indication of where this
expression might be contained. It is unlikely that such
expressions can usefully be shared since they must refer to
invocation-site-specific variables.
Therefore:
Change the definition to:
operationCallExp : OperationCallExp[1]
{composes}and draw the composition with 0..1 parent multiplicity.
Simple change already in QVTcore.xml
The specification introduces comments by concrete syntax. Comments within the abstract syntax are not considered. This is i.e. undesirable for automated analysis of software product quality to which transformations are subject. One would again need to analyze the AST instead of the transformation metamodel. So I propose to introduce comments for transformations.
No Data Available
There is a reference to a figure that does not exist : figure 1.
No Data Available
The grammar rule used to produce a forExp doesn't coincide with the notation specified in the abstract syntax section for it (Pag 89, Section 8.2.2.6). The rule production in the grammar is wrong. Suggestion: Change the production rule: <for_exp> ::= ('forEach' | 'forOne') '(' <iter_declarator_list> ('|' <expression> )? ')' <expression_block>
No Data Available
A clarification is needed in the text because it says "A variable parameter is an abstract concept..." and it can lead to confussion. A variable parameter can not be abstract because we could not create VarParameters for Helpers or Constructors (We could just create ModelParameters or MappingParameters). Suggestion: Remove the word "abstract".
No Data Available
The extraCondition association needs revision: 1. The name does match with the diagram. 2. The cardinality is incorrect. Suggestion: Change the text with the following line: additionalCondition: OclExpression [*]
{composes, ordered}
No Data Available
