|
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
