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