|
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
