Hi
First and second tranches have been approved. Third tranche now
voting, already quorate.
The final tranche of resolutions below have just gone into preview.
The extent resolution is probably worth yet another read. I did some
further clarification on orphans.
Regards
Ed Willink
-------- Forwarded Message --------
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 Descriptions
- Title:
- Relations Language: how will metamodels
get into a transformation scrip
- Summary:
-
Concerning to Relations Language, how will the
metamodels get into a transformation script ? Is there a
technique similar to Operational Mappings using
metamodel declaration and modeltypes ? The RL sample
transformation script in annex A.1 (pp 164) doesn't
declare the metamodels. The OM sample (A.2.3) does.
There is some syntax for declaring and using metamodels
and modeltypes in OM (pp118), there isn't for RL (pp38).
- Source:
- ptc/07-07-07
— Chapter/Section: 7 — Page Number/s: 13ff
- Legacy
Issue Number:
- 12213
- Reporter:
- Siegfried Nolte, Siegfried Nolte
(siegfried@xxxxxxxxxxxxxxxxxx)
- Reported:
- Wed, 6 Feb 2008 05:00 GMT on QVT
1.0
- Updated:
- Wed, 21 Oct 2015 09:17 GMT
- Discussion:
- QVT13-6
- Summary:
-
Relations Language: how
will metamodels get into a transformation scrip
Concerning to Relations Language, how will the
metamodels get into a transformation script ? Is
there a technique similar to Operational Mappings
using metamodel declaration and modeltypes ? The RL
sample transformation script in annex A.1 (pp 164)
doesn't declare the metamodels. The OM sample
(A.2.3) does. There is some syntax for declaring and
using metamodels and modeltypes in OM (pp118), there
isn't for RL (pp38).
Discussion
We needs to support definition of e.g. UML in
transformation umlToRdbms(uml:UML, rdbms:RDBMS)
But we actually may want to reference a document
URI or namespace URI
But the current syntax is essentially a Java import
without the trailing * option.
It cannot reference URIs and it has the wrong
separator.
Something similar to QVTo's ModelType is needed:
modeltype UML uses SimpleUml ("http:);
However ModelType has many problems that we do not
need to replicate:
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) target.invresolve() target.invresolve(c : Class | c.name.startsWith('_'))
invresolveIn(Class2Table) 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) target.invresolveone() target.invresolveone(c : Class | c.name.startsWith('_'))
invresolveoneIn(Class2Table) 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);
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); 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
|
