|
Subject:
|
[omg] [QVT13] Ballot #5 is ready for review until Wed, 28 Oct 2015 04:00 GMT.
|
|
Date:
|
Thu, 22 Oct 2015 02:29:45 -0400 (EDT)
|
|
From:
|
QVT 1.3 RTF (No Reply)
<jira+qvt-rtf@xxxxxxx>
|
|
To:
|
qvt-rtf@xxxxxxx
|
Ballot #5 — QVT 1,3 RTF Ballot 4
Hello Task Force Members:
Ballot #5 is opening soon and the issues are ready to be reviewed.
Issues:
12
Ballot Opens:
Wed, 28 Oct 2015 04:00 GMT
Ballot Closes:
Fri, 6 Nov 2015 04:59 GMT
All dates are UTC
Please note the following excerpt from OMG Policies and Procedures: "A Representative on the F/RTF who fails to vote in a contiguous sequence of at least two polls that complete during a period of at least two weeks is automatically removed from the F/RTF.
A proxy vote or a vote of abstain is considered a vote for this purpose." (document pp/14-06-04, section 4.4.1.3)
Task Force Members who are awaiting approval will not be able to register their votes until they are approved.
Issues Summary
Issues Descriptions
Title:
Relations Language: how will metamodels get into a transformation scrip
Summary:
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).
Source:
ptc/07-07-07 — Chapter/Section: 7 — Page Number/s: 13ff
Legacy Issue Number:
12213
Reporter:
Siegfried Nolte, Siegfried Nolte (siegfried@xxxxxxxxxxxxxxxxxx)
Reported:
Wed, 6 Feb 2008 05:00 GMT on
QVT 1.0
Updated:
Wed, 21 Oct 2015 09:17 GMT
Discussion:
QVT13-6
Summary:
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
But the current syntax is essentially a Java import without the trailing * option.
It cannot reference URIs and it has the wrong separator.
Something similar to QVTo's ModelType is needed:
modeltype UML uses SimpleUml ("http:);
However ModelType has many problems that we do not need to replicate:
§
it is a Class; absolutely not
§
it supports strict/effective inside rather than outside the program
§
it has undefined URI usage
Conversely Complrete OCL has a requirement for an import too, and here ModelType's are not appropriate at all.
Let's fix up import.
Revised Text:
In 7.1 replace
transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {
by
import SimpleUML : 'http:
transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {
Insert before 7.1.1
7.1.1 Import statements
An import statement introduces definitions of unqualified, or first qualifier names for resolution as if defined at the root package of the transformation.
The import of a document URI (such as http://www.omg.org/spec/UML/20131001/UML.xmi) makes the root element (the
UML Package) available to resolve references (to
UML). Additionally, the optional alias (SimpleUML) also makes the root element available to resolve references to the alias name.
Alternatively the import of a namespace URI (such as
http://www.omg.org/spec/UML/20131001) makes the referenced element available in a similar way. It is not specified how an implementation locates elements corresponding
to namespace URIs or how it distinguishes namespace URI access from document URI access. (A plausible implementation maintains a catalog of known namespace URIs to support their resolution leaving everything else to be interpreted as a document URI.)
The import may use further qualification such as
'http://www.omg.org/spec/UML/20131001'::Activities to provide a finer grained import. A trailing wildcard as in
'http://www.omg.org/spec/UML/20131001'::* imports all names defined by the reference preceding the wild card. For UML, this is the Packages
Actions, Activities,
Classification, ... . An alias and a wildcard cannot be used together.
In 7.13.5 replace
<topLevel> ::= ('import' <unit> ';' )* <transformation>*
<unit> ::= <identifier> ('.' <identifier>)*
by
<topLevel> ::= <import>* <transformation>*
<import> ::= 'import' [<identifier> ':'] <URI> ('::' <identifier>)* ['::*'] ';'
<URI> ::= #x27 StringChar* #x27
In 9.18 replace
TopLevel ::= (Transformation | Mapping | Query)*
by
TopLevel ::= Import* (Transformation | Mapping | Query)*
Import ::= 'import' [simpleNameCS ':'] <URI> ('::' simpleNameCS)* ['::*'] ';'
<URI> ::= #x27 StringChar* #x27
Extent Of Change:
Minor
Created:
Wed, 14 Oct 2015 20:03 GMT
Updated:
Wed, 21 Oct 2015 09:17 GMT
Discussion:
QVT13-131
Title:
MOF-QVT 1.0: 7.11.3.6 (and 7.11.1.1) BlackBox operation signature difficulties
Summary:
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.
Legacy Issue Number:
13054
Reporter:
Ed Willink, Model Driven Solutions (ed@xxxxxxxxxxxxx)
Reported:
Fri, 31 Oct 2008 04:00 GMT on
QVT 1.0
Updated:
Wed, 21 Oct 2015 08:59 GMT
Discussion:
QVT13-7
Summary:
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.
Created:
Wed, 14 Oct 2015 16:14 GMT
Updated:
Wed, 21 Oct 2015 08:59 GMT
Discussion:
QVT13-129
Title:
element creation and element attachment/detachment to/from an extent
Summary:
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?
Source:
formal/08-04-03 — Chapter/Section: 8.2.1.24 — Page Number/s: 86-87
Legacy Issue Number:
13103
Reporter:
Victor Sanchez, Open Canarias, SL (vsanchez@xxxxxxxxxxxxxxxx)
Reported:
Fri, 21 Nov 2008 05:00 GMT on
QVT 1.0
Updated:
Wed, 21 Oct 2015 05:50 GMT
Discussion:
QVT13-9
Summary:
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.
See Issue
QVT13-36 for disposition
Created:
Mon, 12 Oct 2015 18:57 GMT
Updated:
Wed, 21 Oct 2015 05:50 GMT
Discussion:
QVT13-119
Title:
Unclear transformation rooting condition
Summary:
"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
Legacy Issue Number:
15411
Reporter:
Ed Willink, Model Driven Solutions (ed@xxxxxxxxxxxxx)
Reported:
Tue, 10 Aug 2010 04:00 GMT on
QVT 1.1
Updated:
Wed, 21 Oct 2015 08:35 GMT
Discussion:
QVT13-18
Summary:
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.
Created:
Tue, 13 Oct 2015 15:13 GMT
Updated:
Wed, 21 Oct 2015 08:35 GMT
Discussion:
QVT13-123
Title:
Trace data for an 'accessed' transformation
Summary:
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.
Source:
formal/11-01-01 — Chapter/Section: 8.2.1.4 ModuleImport — Page Number/s: 83
Legacy Issue Number:
18323
Reporter:
Christopher Gerking, campus.upb.de (cgerking@xxxxxxxxxxxxx)
Reported:
Thu, 27 Dec 2012 05:00 GMT on
QVT 1.1
Updated:
Wed, 21 Oct 2015 05:59 GMT
Discussion:
QVT13-22
Summary:
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.
See Issue
QVT13-23 for disposition
Created:
Sat, 10 Oct 2015 17:13 GMT
Updated:
Sat, 10 Oct 2015 17:13 GMT
Discussion:
QVT13-103
Title:
No trace data for disjuncting mapping
Summary:
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.
Source:
formal/11-01-01 — Chapter/Section: 8.2.1.15 MappingOperation — Page Number/s: 93
Legacy Issue Number:
18324
Reporter:
Christopher Gerking, campus.upb.de (cgerking@xxxxxxxxxxxxx)
Reported:
Thu, 27 Dec 2012 05:00 GMT on
QVT 1.1
Updated:
Wed, 21 Oct 2015 15:32 GMT
Discussion:
QVT13-23
Summary:
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.
Revised Text:
In 8.1.4 change
{
init { … }
population { … }
end { … }
}
to
{
init { … }
population { … }
end { … }
}
In 8.1.4 replace
Between the initialization and the population sections, there is an implicit section, named the instantiation section, which
creates all output parameters that have a null value at the end of the initialization section. This means that, in order to
return an existing object rather than creating a new one, one simply needs to assign the result parameter within the
initialization section.
by
Before the init, there is an implicit section, named the pre-trace section, which suppresses redundant re-execution of a mapping.
Following the init and before the population sections, there is an implicit section, named the instantiation section, which creates all output parameters that have a null value at the end of the initialization section.
The null value tests mean that, in order to return an existing object rather than creating a new one, one simply needs to assign the result parameter within the
init section.
Following the instantiation section, a further implicit section, named the post-trace section creates the trace record of the execution.
In 8.1 before 8.1.10 Add a new section
8.1.x Tracing and Resolving
Execution of a mapping establishes a trace record to maintain the relationship between its context object and the result object or objects. This relationship can be queried using one of the eight
resolve expressions.
8.1.x.1 Trace Records
Execution of a transformation builds the overall
trace-data which comprises a sequence of trace-records; one for each mapping execution in execution order. This includes every mapping executed by, accessed or extended, transformations or libraries, but not those by transformation invocations.
Each trace-record comprises:
§
context-parameter - the context parameter object
§
in-parameters - the in and inout parameter objects or values
§
invoked-mapping - the invoked mapping operation
§
executed-mapping - the executed mapping operation
§
out-parameters - the out parameter objects or values
§
result-parameters - the result parameter object or objects
The invoked-mapping and executed-mapping operations may differ when a
disjuncting mapping is executed. The invoked-mapping is the
disjuncting mapping. The executed-mapping is the successfully selected
candidate mapping or null.
inout parameters are traced once as in-parameters; they cannot change during production of the trace-record.
The trace-record is created during the post-trace section of the selected
candidate mapping, which is after the initialization and instantiation sections and before the population section.
A trace-record is created by every mapping execution, unless predicates or initialization section fail.
A trace-record is created or re-used by every mapping invocation, unless predicates or initialization section fail. In the case of a standard mode execution for which no candidate mapping is selected, the
executed-mapping, out-parameters and result-parameters are
null.
The following example mapping declarations
mapping X::disjunctingMapping(in p1:P1, inout p2:P2, out p3:P3) : r1:R1, r2:R2
disjuncts mappingName, ... {}
mapping X::mappingName(in p1:P1, inout p2:P2, out p3:P3) : r1:R1, r2:R2 ..{...}
may be invoked as
var t := anX.map disjunctingMapping(aP1, aP2, aP3);
var anR1 := t.r1;
var anR2 := t.r2;
to create the following trace-record. (Hyphens are used in names that are helpful for exposition, but which are not accessible to program code.)
object Trace-Record {
context-parameter := anX;
in-parameters := Sequence{aP1, aP2};
invoked-mapping := X::disjunctingMapping;
executed-mapping := X::mappingName;
out-parameters := Sequence{aP3};
result-parameters := Sequence{anR1, anR2};
}
The trace-record traces the relationship between mapping inputs and outputs; between the inputs {anX, aP1, aP2} and the outputs {aP3, anR1, anR2}.
Note that there is no trace for object construction in helpers or for nested object construction in mappings. If a trace of all objects is needed, a mapping must be used to create each object as a mapping output.
8.1.x.2 The pre-trace, instantiation and post-trace sections
The auto-generated pre-trace, instantiation and post-trace sections occurs surround the initialization section of a mapping, whose general structure is:
mapping X::mappingName(in p1:P1, inout p2:P2, out p3:P3) : r1:R1, r2:R2
when { … }
where { … }
{
var trace-records := trace-data
->select(executed-mapping=X::mappingName)
->select(context-parameter=self)
->select(in-parameters->at(1)=p1)
->select(in-parameters->at(2)=p2);
if (trace-records->notEmpty()) {
var trace-record := trace-records->at(1);
p3 := trace-record.out-parameters->at(1);
r1 := trace-record.result-parameters->at(1);
r2 := trace-record.result-parameters->at(2);
return;
};
init { … }
if (p3 == null) p3 := object P3{};
if (r1 == null) r1 := object R1{};
if (r2 == null) r2 := object R2{};
trace-data += object Trace-Record{
context-parameter:=self,
in-parameters:=Sequence{p1, p2},
invoked-mapping:=X::dislunctingName,
executed-mapping:=X::mappingName,
out-parameters:=Sequence{p3},
result-parameters:=Sequence{r1,r2}
};
population { … }
end { … }
}
In the pre-trace section, the trace-data is consulted to locate all
trace-records whose executed-mapping, context-parameter and
in-parameters match the new candidate mapping invocation. If a match is found, the previous
out-parameters and result-parameters are used as the mapping return values and the mapping re-execution is suppressed.
Then the initialization section provides an opportunity for the default
null values of outputs to be replaced by something more useful. If the
null values are unchanged, the instantiation section constructs an object for each object. inout parameters may not be changed during the initialization section.
The post-trace section records the execution of the mapping by adding a
trace-record to the trace-data.
A candidate mapping execution is suppressed to avoid creating a
trace-record whose context-parameter, in-parameters,
invoked-mapping and executed-mapping fields duplicate another trace-record already in the
trace-data. When comparing trace-record fields, Class instances are compared as objects without regard for their content, and DataType values are compared by deep value equality. Traced object instances may therefore be modified between mapping
executions without inhibiting detection of re-execution since only the object references are traced. However any modification of a traced DataType value such as a List inhibits detection of a re-execution since the entire value is traced.
When a re-execution attempt is detected, the re-execution is suppressed without any additional
trace-record being created. Note that traced Class instances are mutable and so the re-used value may have changed in the interim.
8.1.x.3 resolve() - Resolution of target objects by Type
The trace data may be queried to identify all target objects using the
resolve operation without a context object or argument.
The query may be restricted to identifying all target objects conforming to a given type by adding a type argument.
The returned target objects may be restricted to those mapped from a particular source object by supplying the source object as the context object.
Additionally, or alternatively, the returned target objects may be restricted by an OCL condition.
source.resolve(t : Table | t.name.startsWith('_'))
These queries return a sequence of target objects in mapping invocation order.
An equivalent OCL-like query for SOURCE.resolve(T : TYPE | CONDITION) is
let selectedRecords = trace-data->select(in-parameters->including(context-parameter)->includes(SOURCE)) in
let selectedTargets = selectedRecords->collect(out-parameters->union(result-parameters)) in
selectedTargets->selectByKind(TYPE)->select(T | CONDITION)
8.1.x.4 resolveIn() - Resolution of target objects by Mapping
The trace data may be queried to identify all target objects produced by a given invoked disjuncting mapping or executed candidate mapping using the
resolveIn _expression_.
The returned target objects may be restricted to those mapped from a particular source object by supplying the source object as the context object.
source.resolveIn(Class2Table)
Additionally, or alternatively, the returned target objects may be restricted by an OCL condition.
source.resolveIn(Class2Table, t : Table | t.name.startsWith('_'))
These queries return a sequence of target objects in mapping invocation order.
An equivalent OCL-like query for SOURCE.resolveIn(MAPPING, T : TYPE | CONDITION) is
let selectedRecords1 = trace-data->select(in-parameters->including(context-parameter)->includes(SOURCE)) in
let selectedRecords2 = selectedRecords1->select((invoked-mapping = MAPPING) or (executed-mapping = MAPPING)) in
let selectedTargets = selectedRecords2->collect(out-parameters->union(result-parameters)) in
selectedTargets->selectByKind(TYPE)->select(T | CONDITION)
8.1.x.5 invresolve() - Resolution of source objects by Type or Mapping
The corresponding inverse queries are available using the
invresolve or invresolveIn expressions. These identify source objects mapped to a given type or by a given mapping.
invresolve()
invresolve(Class) Class
target.invresolve()
target.invresolve(c : Class | c.name.startsWith('_'))
invresolveIn(Class2Table) for
target.invresolveIn(Class2Table)
target.invresolveIn(Class2Table, c : Class | c.name.startsWith('_'))
8.1.x.6 resolveone() - Resolution of a single source or target object by Type or Mapping
The four resolveone variants of the four
resolve expressions modify the return to suit the common case where only a single object is expected. The return is therefore the first resolved object or
null.
resolveone()
resolveone(Table)
source.resolveone()
source.resolveone(t : Table | t.name.startsWith('_'))
resolveoneIn(Class2Table)
source.resolveoneIn(Class2Table)
source.resolveoneIn(Class2Table, t : Table | t.name.startsWith('_'))
invresolveone()
invresolveone(Class) Class
target.invresolveone()
target.invresolveone(c : Class | c.name.startsWith('_'))
invresolveoneIn(Class2Table) for
target.invresolveoneIn(Class2Table)
target.invresolveoneIn(Class2Table, c : Class | c.name.startsWith('_'))
8.1.x.7 Late resolution
The resolve expressions query the prevailing state of the
trace data. resolve cannot of course return results from mappings that have yet to execute and so careful programming of mapping invocations may be required to ensure that required results are available when needed. Alternatively a
late keyword may prefix resolve when the resolution occurs within an assignment. This defers the execution of the assignment and the partial computation involving
late resolve's until all mapping executions have completed. The deferred assignment cannot return the future value; it therefore returns a
null value.
More precisely, mappings execute, assignment right hand sides involving late resolutions are computed, then finally deferred assignments are made. The ordering in which late resolutions occur does not matter, since each late resolution
can influence only its own deferred assignment.
myprop := mylist->late resolve(Table);
for
This last example also demonstrates that an implicit imperative xcollect of resolutions may be performed, in this case requiring the collection to be performed after all mappings have executed.
8.1.x.8 Persisted Trace Data
The trace data may be persisted and reloaded to support a re-execution. However the
trace record does not trace configuration data, transformation properties or intermediate data, and does not involve a deep clone of every traced object. It is therefore not possible to use a persisted form of the
trace data to support incremental re-execution of an arbitrary QVTo transformation since the required object state may not be present in persisted trace. A well-behaved transformation that avoids dependence on mutable object properties or other untraced
facilities may be re-executable.
In 8.2.1.15 Correct
A mapping operation is an operation implementing a mapping between one or more source model elements-
intoand one or
more target model elements.
In 8.2.1.15 Replace
The when clause acts either as a pre-condition or as a guard, depending on the invocation mode of the mapping
operation.
by
The when clause acts either as a pre-condition when invoked with strict semantics, or as a guard, when invoked using standard semantics.
In 8.2.1.15 Replace
The initialization section is used for computation prior to the effective instantiation of the outputs. The population section is used to populate the outputs and the finalization section is used to define termination computations
that take place before exiting the body.
by
The init (initialization) section is used for computation prior to the effective instantiation of the outputs. The
population section is used to populate the outputs and the end (finalization) section is used to define termination computations that take place before exiting the body.
In 8.2.1.15 Replace
There are three reuse and composition facilities associated to mapping operations:
by
A mapping operation may be explicitly defined as a disjunction of candidate mapping operations. Every mapping operation is also an implicit disjunction of all mappings that are overloads as a consequence of matching name and argument
count. Execution of a disjunction involves selecting the first candidate mapping whose when clause and other predicates are satisfied and then invoking it. This is described in Section 8.1.12. The empty body of the disjuncting mapping is not executed.
Additionally, there are two extension mechanisms associated to mapping operations:
In 8.2.1.15 Replace
3. A mapping operation may be defined as a disjunction of other mapping operations. This means selecting, among the
set of disjuncted mappings, the first that satisfies the when clause and then invoking it. The execution semantics subsection
below provides the details of these reuse facilities.
by
The execution semantics subsection below provides the details of these mapping extension mechanisms.
In 8.2.1.15 Constraints add
The body of a disjuncting mapping must be empty.
disjunct->notEmpty() implies body = null
In 8.2.1.15 Replace
We first define the semantic of the execution of a mapping operation in absence of any reuse facility (inheritance, merge, and disjunction), then we describe the effect of using these facilities.
by
We firstly define the semantic of the execution of a mapping operation in the absence of any inheritance or merge reuse facility.
In 8.2.1.21 Replace
Indicates the mode of the mapping invocation.
by
Indicates whether the mapping invocation mode is strict or standard.
In 8.2.1.21 Replace
In strict mode the when clause is evaluated as a pre-condition. In contrast, when the mapping is invoked in standard mode, the execution of the mapping body is skipped and the null value is returned to the caller.
by
In strict mode, failure to evaluate the when clause as a pre-condition causes the mapping execution to fail. In contrast in standard mode, failure to evaluate the when clause as a guard causes execution of the mapping body to be
skipped and null to be returned to the caller.
In 8.2.1.21 Correct
The map and xmap keywords may be called on a
listcollection as source
In 8.2.1.22 Correct
where the <resolve_op> is one of the following: resolve,
resolveone, invresolve, and invresolveone.
In 8.2.1.22 Correct
When isDeferred is true the
latelate keyword is used before the
operation name<resolve_op>.
In 8.2.1.22 Correct
The resolution operator may be called on a
listcollection. This is a shorthand for invoking it in the body of
a ForExpan xcollect ImperativeIterateExp _expression_.
In 8.2.1.22 Replace
// shorthand for mylist->forEach(i) { i.late resolve(Table); }
by
// shorthand for mylist->xcollect(late resolve(Table))
Extent Of Change:
Significant
Created:
Sat, 10 Oct 2015 10:14 GMT
Updated:
Wed, 21 Oct 2015 16:01 GMT
Discussion:
QVT13-102
Title:
xcollect is ambiguously flattened
Summary:
xcolect is specified to like collect, which flattens, however the xcollect pseudocode does not flatten.
Source:
formal/11-01-01 — Chapter/Section: 8.2.2.7 — Page Number/s: 109
Legacy Issue Number:
19177
Reporter:
Ed Willink, Model Driven Solutions (ed@xxxxxxxxxxxxx)
Reported:
Thu, 9 Jan 2014 05:00 GMT on
QVT 1.1
Updated:
Thu, 22 Oct 2015 04:25 GMT
Discussion:
QVT13-34
Summary:
xcollect is ambiguously flattened
xcollect is specified to like collect, which flattens, however the xcollect pseudocode does not flatten.
Discussion
Ditto xcollectselect, xcollectselectOne
Once an attempt is made to put the pseudo-code through Eclipse QVTo, it is quite amazing how many different errors there are.
§
spurious source/iterator arguments
§
missing compute open {
§
increarect non-collection returns
§
incorrect accommodation of ordered collections
§
no flattening
§
no single values
§
use of mutable Sequence rather than List
Revised Text:
In 8.2.2.7 ImperativeIterateExp Collection(T)::xcollect(source, iterator, body) replace
Collection(T)::xcollect(source, iterator, body) : Sequence(TT) =
compute (res:Sequence(TT) := Sequence{})
source->forEach (iterator:T) {
var target : TT := body;
if (target<>null) res += target;
};
Collection(T)::xselect(source, iterator, condition) : Sequence(T) =
compute (res:Sequence(T) := Sequence{})
source->forEach (iterator:T) {
var target : T := iterator;
if (target<>null and condition) res += target;
};
Collection(T)::xselectOne(source, iterator, condition) : Sequence(T) =
compute (res:Sequence(T) := Sequence{})
source->forEach (iterator:T) {
var target : T := iterator;
if (target<>null and condition) {res += target; break;}
};
Collection(T)::xcollectselect(source, iterator, target, body, condition) : Sequence(TT) =
compute (res:Sequence(TT) := Sequence{})
source->forEach (iterator:T) {
var target : TT := body;
if (target<>null and condition) res += target;
};
Collection(T)::xcollectselectOne(source, iterator, target, body, condition) : Sequence(TT) =
compute (res:Sequence(TT) := Sequence{})
source->forEach (iterator:T) {
var target : TT := body;
if (target<>null and condition) {res += target; break;}
};
T and TT are respectively the type of the source elements and the type of the target elements. When applying the
imperative iterate _expression_ if the source collection is not ordered, it is implicitly converted into the corresponding
ordered collection (Set and Bag become respectively OrderedSet and Sequence). If the condition is not given, it should be
replaced by true in the definitions above.
by
Collection(T)::xcollect(BODY) : BagOrSequence(TT) =
compute (res : List(TT) := List{}) {
self->forEach(COLLECTOR) {
BODY->flatten()->forEach(target) {
if (target <> null) res += target;
};
};
}->asBagOrSequence();
Collection(T)::xselect(CONDITION) : BagOrOrderedSetOrSequenceOrSet(T) =
compute (res : List(T) := List{}) {
self->forEach(SELECTOR) {
if (SELECTOR<> null and CONDITION) res += SELECTOR;
};
}->asBagOrOrderedSetOrSequenceOrSet();
Collection(T)::xselectOne(CONDITION) : T =
compute (res : T := null) {
self->forEach(SELECTOR) {
if (SELECTOR<> null and CONDITION) { res := SELECTOR; break; }
};
};
Collection(T)::xcollectselect(BODY, CONDITION) : BagOrSequence(TT) =
compute (res : List(TT) := List{}) {
self->forEach(COLLECTOR) {
BODY->flatten()->forEach(SELECTOR) {
if (SELECTOR <> null and CONDITION) { res += SELECTOR; }
};
};
}->asBagOrSequence();
Collection(T)::xcollectselectOne(BODY, CONDITION) : TT =
compute (res : TT := null) {
self->forEach(COLLECTOR) {
BODY->flatten()->forEach(SELECTOR) {
if (SELECTOR <> null and CONDITION) { res := SELECTOR; break; }
};
if (res <> null) { break; }
};
};
where
§
BagOrOrderedSetOrSequenceOrSet denotes the Bag, OrderedSet, Sequence or Set kind of the source Collection
§
BagOrSequence denotes either Bag or Sequence according to whether the source Collection is unordered or ordered
§
BODY is a TT-valued Imperative OCL _expression_ that may use the COLLECTOR variable
§
CONDITION is a Boolean-valued Imperative OCL _expression_ that may use the SELECTOR variable
Extent Of Change:
Support Text
Created:
Tue, 6 Oct 2015 18:34 GMT
Updated:
Wed, 21 Oct 2015 10:12 GMT
Discussion:
QVT13-125
Title:
Specify the utility of an extent
Summary:
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?
Source:
formal/11-01-01 — Chapter/Section: 8 — Page Number/s: n/a
Legacy Issue Number:
19204
Reporter:
Ed Willink, Model Driven Solutions (ed@xxxxxxxxxxxxx)
Reported:
Wed, 5 Feb 2014 05:00 GMT on
QVT 1.1
Updated:
Wed, 21 Oct 2015 17:17 GMT
Discussion:
QVT13-36
Summary:
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.
Revised Text:
Add the following section after 8.1.2 Model Types and before 8.1.3 Libraries
8.1.x Extents, Models and Model Parameters
The inputs and output of a transformation are identified by Model Parameters which have a direction, model name and ModelType.
transformation Uml2Rdbms(in uml:UML, out rdbms:RDBMS)
8.1.x.1 Implementation responsibilities
A transformation is executed by a QVTo implementation which must load an external model for each
in and inout parameter and identify a future external model for each
out parameter. When the transformation completes successfully, the implementation must save the
inout models and the no longer future out models.
8.1.x.2 Extents
The interface between implementation and specified behavior uses a distinct MOF Extent associated with each Model Parameter. A MOF Extent identifies the root objects of its Model. The root objects are members of the Extent and
are said to reside in the Extent.
The initial members of in and inout Extents are the roots of loaded external models. There are no initial members of
out Extents.
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. Other Extents are mutable and must be distinct even when the same external model is bound to more than one Model Parameter. There are therefore no shared model conflicts within the QVTo engine. Resolution of the conflict between
multiple Extents that need to be saved to the same external model is a problem for the implementation to solve, perhaps by prohibiting the conflict in the first place.
8.1.x.3 Models
A Model comprises a forest of model elements (objects) with each tree defined by MOF containment relationships. For many applications, a single root, and its containment tree, rather than a forest is sufficient. However during
the course of a transformation, model elements are created for use by the model and these may form additional roots until the model elements are assigned to their intended container.
Each Model Parameter has an Extent whose members are the root objects of a Model. The ModelParameter's ModelType identifies the permitted content of the Model, The ModelParameter's name may be used with the operations of the Model
library type.
uml.objectsOfKind(Class);
The name may be used to assign all members of the Extent.
A model assignment displaces any previous members associated with the extent in favor of the root model elements of the replacement Model. The previous members cease to reside in any Extent and so become orphans.
Additional Models and corresponding Extents may be created by the Model::copy() and Model::createEmptyModel() operations. These Extents have no associated external model and so their contents will be lost unless assigned to Extents
with external models or unless passed to other transformations. The Models passed to nested transformation calls by Transformation::transform() or Transformation::parallelTransform() may not be modified after the call. This may require that a copy is created.
8.1.x.4 Object Containment and Extent Residence
A MOF object can be contained by at most one other object, consequently the containment relationship of a model form a forest. The roots of the forest have no containers, rather they are members of at most one Extent and are therefore
said to reside in that Extent. The non-roots of the forest are transitively contained by a root that is a member of the Extent; the non-roots are therefore also said to reside in the Extent. Objects that do not reside in an Extent are orphans.
parent.child := firstChild;
parent.child := secondChild;
Assignment of a container relationship, or opposite containment relationship, establishes a new parent-child containment relationship. This may displace the previous child so that it has no container, however the displaced child
retains its residence in its models' extent; the displaced child is therefore added to the extent's members and is an additional root object for the model.
model.addElement(anObject);
Similarly assignment of the residence of a root object, establishes or updates the residence of the root object and transitively of all its contained objects. Any previous residence is eliminated.
When a transformation consistently assigns all residences and containments for all objects, the result is often a tree for the Extent of each
inout and out parameter. However if any residence or containment is left unassigned, some orphan objects are lost.
Direct object creation or construction typically results in orphans whose containment and residence is assigned later since there is no inference of a default residence. The object may be explicitly assigned to the root of some
extent when it is created:
column := new Column@mymodel(n,t); fornew
object x:X@srcmodel { … }
Objects returned as out or inout parameters of a mapping are assigned to an explicit or inferred extent. If no extent can be inferred, typically because two ModelParameters use the same ModelType, the objects
are orphans. This is a programming hazard that can be diagnosed by tooling.
An object may be completely removed from its extent by invoking Model::removeElement(). This makes the object an orphan with no references to or from any other object.
Cloned and deepcloned objects are added to the Extent of the source object; they are therefore new root objects until assigned to some container.
8.1.x.5 Orphans
An orphan is a potentially lost object; it resides in no container and no extent and so will not contribute to any
out or inout model.
Orphans may arise as the result of:
§
Model::removeElement() explicitly orphaning an object
§
model assignment displacing an obsolete model
§
non-mapping object construction
Creation of orphans by object construction is discouraged in two ways. An @extent may form part of the ObjectExp, or Mapping out parameter declaration. In the case of mappings, a default extent is inferred by metamodel compatibility.
However objects constructed within helpers may be orphans.
An orphan may cease to be an orphan when a container is assigned, or when Model::addElement() is used to add the orphan element to the members of the Extent that identifies the root objects of the Model.
Although an orphan may have no container and may reside in no extent, it may still be referenced by objects that reside in an out extent. At the end of the transformation, when these extents are saved, the referenced orphans are
unresolved and the saved extent is incomplete and difficult to use. Referenced orphans are therefore saved as members of each extent in which they are referenced.
In 8.2.1.6 replace
More precisely there is a MOF extent corresponding to each parameter.
by
More precisely each ModelParameter has a ModelType for a MOF Extent whose members are the root objects of the corresponding Model.
In 8.2.1.6 delete the following contradiction
Any object creation occurs in an extent associated with a model parameter.
In 8.2.1.6 delete the following (rewritten above)
Relationship between MOF extents and model parameters
When a model element is created by a transformation it is necessary to know in what model the model element is to be
created. In particular, this makes it possible to use the inspection operations on model parameters like objects() and
objectsOfType() to retrieve an object previously created. In MOF there is a notion of Extent that is simply defined
as a container for Objects. Here we are correlating the notion of model (represented by model parameters in a
transformation definition) with the notion of MOF extent stating that for each model parameter there is a MOF extent.
In 8.2.1.16 delete the following fiction
A mapping operation being a refinement of a relation, a mapping parameter is associated with a domain of the refined
relation. This correspondence is based on the order of the declared parameters and domains, where the contextual
parameter, if any, is the first and the result parameters are positioned after the “regular” parameters. The type of the
mapping parameter should necessarily be the same as the type specified by the object pattern of the domain (see Domain
definition in Clause 7.11).
In 8.2.1.24 ObjectExp add after the first paragraph
Object creation, initialization and residence are separate activities. Object creation occurs when the referredObject has a null value; it is skipped if the referredObject variable references an existing object. Object initialization
always occurs, but may be trivial if the body is empty. Object residence is left unchanged when the extent is omitted; it will be established as soon as the created object is put at the target end of some composition relationship. An explicit object residence
may be established by specifying the model parameter for the required extent as the extent.
In 8.2.2.12 UnlinkExp correct
An unlink _expression_ represents an explicit removal of
a valuean object from a multivalued property link.
In 8.2.2.12 UnlinkExp add
The residence of the removed object is unaffected; it therefore becomes a root object of its model. If total removal is required the
Model::removeElement() operation may be used.
In 8.3.4 correct
8.3.4 Operations on elementsElements
In 8.3.4.10 clone add
The returned object is added to the root of the model containing the source element.
In 8.3.4.11 deepclone add
The returned object is added to the root of the model containing the source element.
In 8.3.5 correct
8.3.5 Operations on modelsModels
In 8.3.5.1 correct
Returns the listset of
theall objects in the model
extent.
In 8.3.5.3 correct
Returns the set of all the objects in the
extentmodel that are not contained by other objects
of the extentin the model.
Before 8.3.5.4 removeElement add
8.3.5.x addElement
Model::addElement (anObject : Element): Void
The object is first displaced from any usage by setting its container to null, then the object is added to the model's extent so that it provides another root for the model. Any non-containment references to and from the object are unaffected.
In 8.3.5.4 removeElement replace
Removes an object of the model extent. All links between the object and other objects in the extent are deleted. References from collections to the ends of deleted links are removed. References from noncollections are set to null.
by
Removes an object from the model so that it becomes an orphan. All references to or from the object are eliminated. References from collections are removed. References from non-collections are set to null.
In 8.3.5.6 copy replace
Performs a complete copy of a model into another model. All objects belonging to the source extent are copied into the target extent.
by
Creates a deep copy of a model and its extent. All objects transitively contained in the source model are copied into the new model. The roots of the new model are the initial members of the new extent. The new extent has no associated
external file and so the new contents may be lost unless assigned to another model or passed to another transformation.
In 8.3.5.7 createEmptyModel replace
Creates and initializes a model of the given type. This operation is useful when creating intermediate models within a transformation.
by
Creates a model and extent of the given type without any content. This operation is useful when creating intermediate models within a transformation.
Extent Of Change:
Significant
Created:
Mon, 12 Oct 2015 18:46 GMT
Updated:
Wed, 21 Oct 2015 17:17 GMT
Discussion:
QVT13-118
Title:
QVTr Variable Initialization
Summary:
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.
Legacy Issue Number:
19665
Reporter:
Ed Willink, Model Driven Solutions (ed@xxxxxxxxxxxxx)
Reported:
Fri, 28 Nov 2014 05:00 GMT on
QVT 1.2
Updated:
Wed, 21 Oct 2015 09:36 GMT
Discussion:
QVT13-43
Summary:
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.
Revised Text:
In 7.13.5 replace
<varDeclaration> ::= <identifier> (, <identifier>)* ':' <TypeCS> ';'
to
<varDeclaration> ::= <identifier> (, <identifier>)* ':' <TypeCS>
['=' <OclExpressionCS>] ';'
Extent Of Change:
Minor
Created:
Wed, 21 Oct 2015 09:27 GMT
Updated:
Wed, 21 Oct 2015 09:35 GMT
Discussion:
QVT13-132
Title:
Allow QVTc to use initialized variables
Summary:
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.
Source:
invalid:- — Chapter/Section: 9 — Page Number/s: 174
Legacy Issue Number:
19725
Reporter:
Ed Willink, Model Driven Solutions (ed@xxxxxxxxxxxxx)
Reported:
Thu, 19 Feb 2015 05:00 GMT on
QVT 1.2
Updated:
Wed, 21 Oct 2015 09:51 GMT
Discussion:
QVT13-50
Summary:
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.
Revised Text:
In 9.18 Concrete Syntax replace
Variable :=
VariableName ':' TypeDeclaration
by
Variable :=
VariableName ':' TypeDeclaration [':=' ValueOCLExpr]
Extent Of Change:
Minor
Created:
Wed, 21 Oct 2015 09:48 GMT
Updated:
Wed, 21 Oct 2015 09:51 GMT
Discussion:
QVT13-133
Title:
Section: 7.13.5
Summary:
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 ?
Legacy Issue Number:
11690
Reporter:
Anonymous
Reported:
Tue, 27 Nov 2007 05:00 GMT on
QVT 1.0
Updated:
Wed, 21 Oct 2015 09:18 GMT
Discussion:
QVT13-59
Summary:
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 ?
See Issue
QVT13-6 for disposition
Created:
Wed, 14 Oct 2015 20:00 GMT
Updated:
Wed, 14 Oct 2015 20:00 GMT
Discussion:
QVT13-130
Title:
How can an UnlinkExp.target be a Property
Summary:
The description of UnlinkExp.target specifies an OclExpression but describes a Property.
Is this an error? Is it introducing a new PropertyLiteralExp?
Reporter:
Ed Willink, Model Driven Solutions (ed@xxxxxxxxxxxxx)
Reported:
Wed, 21 Oct 2015 16:48 GMT on
QVT 1.2
Updated:
Wed, 21 Oct 2015 17:27 GMT
Discussion:
QVT13-134
Summary:
How can an UnlinkExp.target be a Property
The description of UnlinkExp.target specifies an OclExpression but describes a Property.
Is this an error? Is it introducing a new PropertyLiteralExp?
Discussion
It can't be a Property. It is a property.
Revised Text:
In 8.2.2.12 UnlinkExp correct
The target _expression_. It should evaluate to a
Propertyproperty that can be updated.
Extent Of Change:
Minor
Created:
Wed, 21 Oct 2015 17:26 GMT
Updated:
Wed, 21 Oct 2015 17:27 GMT
Discussion:
QVT13-135
The OMG Team
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6172 / Virus Database: 4450/10869 - Release Date: 10/22/15
