Hi
Third batch of resolutions below. If there is a problem, let me know
so that I can withdraw the bad resolution.
Regards
Ed Willink
-------- Forwarded Message
--------
Hello Task Force Members:
Ballot
#4 is opening soon and the issues are ready to be
reviewed.
- Issues:
- 24
- Ballot
Opens:
- Wed, 21 Oct 2015 04:00 GMT
- Ballot
Closes:
- Thu, 29 Oct 2015 03: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:
- 9.18 Undefined syntax
- Summary:
-
9.18 Undefined syntax
---------------------
The syntax for TransformationName, DirectionName,
MappingName, PropertyName and VariableName
is undefined. Presumably each of these is an Identifier
(below) when defining, but a PathNameCS
when referencing.
The syntax for PackageName is undefined. Presumably it
is an OCL PathNameCS.
The syntax for ValueOCLExpr is undefined. This is
presumably an OclExpressionCS.
The syntax for BooleanOCLExpr is undefined. This could
be an OclExpressionCS of Boolean type but ...
The syntax for SlotOwnerOCLExpr is undefined. This
could be an OclExpressionCS of Class type but ...
If BooleanOCLExpr and SlotOwnerOCLExpr are parsed as
OclExpressionCS the 'default' prefix
causes a major ambiguity for 'default(...).xx' as a
parenthesised slot owner or function call.
It is necessary to make 'default' a reserved word within
OCL expressions.
Suggest: define BooleanOCLExpr and SlotOwnerOCLExpr
very narrowly.
Predicate ::= SimpleNameCS ("." SimpleNameCS)* "="
OclExpressionCS
Assignment ::= ["default"]
SimpleNameCS ("." SimpleNameCS)* ":=" OclExpressionCS
- Legacy
Issue Number:
- 10934
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Sun, 25 Mar 2007 04:00 GMT on QVT
1.0
- Updated:
- Wed, 14 Oct 2015 16:08 GMT
- Discussion:
- QVT13-1
- Summary:
-
Undefined syntax
9.18 Undefined syntax
---------------------
The syntax for TransformationName, DirectionName,
MappingName, PropertyName and VariableName
is undefined. Presumably each of these is an
Identifier (below) when defining, but a PathNameCS
when referencing.
The syntax for PackageName is undefined. Presumably
it is an OCL PathNameCS.
The syntax for ValueOCLExpr is undefined. This is
presumably an OclExpressionCS.
The syntax for BooleanOCLExpr is undefined. This
could be an OclExpressionCS of Boolean type but ...
The syntax for SlotOwnerOCLExpr is undefined. This
could be an OclExpressionCS of Class type but ...
If BooleanOCLExpr and SlotOwnerOCLExpr are parsed
as OclExpressionCS the 'default' prefix
causes a major ambiguity for 'default(...).xx' as a
parenthesised slot owner or function call.
It is necessary to make 'default' a reserved word
within OCL expressions.
Suggest: define BooleanOCLExpr and SlotOwnerOCLExpr
very narrowly.
Predicate ::= SimpleNameCS ("." SimpleNameCS)* "="
OclExpressionCS
Assignment ::= ["default"]
SimpleNameCS ("." SimpleNameCS)* ":="
OclExpressionCS
Discussion
Merged with the inadequate definition of
identifiers.
See Issue QVT13-2 for disposition
- Created:
- Wed, 14 Oct 2015 16:07 GMT
- Updated:
- Wed, 14 Oct 2015 16:08 GMT
- Discussion:
- QVT13-128
- Title:
- 9.18 Identifiers
- Summary:
-
The syntax of identifiers is undefined.
The syntax for mapping clearly prohibits the use of a
direction named 'where'.
Suggest: identifier is an OCL simpleName, less the new
reserved words (check default enforce
imports map realize refines transformation uses where)
Suggest: a string-literal may be used as an identifier
to support awkward identifiers such as 'where'.
- Legacy
Issue Number:
- 10935
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Sun, 25 Mar 2007 04:00 GMT on QVT
1.0
- Updated:
- Wed, 14 Oct 2015 16:07 GMT
- Discussion:
- QVT13-2
- Summary:
-
Identifiers
The syntax of identifiers is undefined.
The syntax for mapping clearly prohibits the use of
a direction named 'where'.
Suggest: identifier is an OCL simpleName, less the
new reserved words (check default enforce
imports map realize refines transformation uses
where)
Suggest: a string-literal may be used as an
identifier to support awkward identifiers such as
'where'.
Discussion
OCL 2.3/2.4 clarified identifiers and strings so we
can just exploit the OCL productions including it's
underscore-prefixed-string identifier.
OCL 2.3 also introduced String::_'+' so no special
description is needed for a QVTr extension.
- Revised Text:
-
In 7.13.2 replace
The "_" OCL prefix convention for escaping
reserved words can be used to refer to conflicting
properties or class names.
by
Reserved words and awkward characters may be used
within identifiers using OCL's
underscore-prefixed-string-literal escape. e.g
A simple underscore prefix may also be used but
is now deprecated.
Delete
7.13.4 Shorthands used to invoke pre-defined
operations
The binary operator “+” can be used as shorthand
for the string concat operation.
In 7.13.5 add
Production names ending CS are defined by OCL.
<identifier> :: simpleNameCS
replace all usages of TypeCS by typeCS.
In 8.4.7 after keywords add
<identifier> ::= simpleNameCS <STRING> ::= (#x22 StringChar* #x22) | (#x27 StringChar* #x27)
In 9.18 add
Production names ending CS are defined by OCL.
DirectionName ::= simpleNameCS
MappingName ::= pathNameCS
PackageName ::= pathNameCS
PropertyName ::= simpleNameCS
QueryName ::= pathNameCS
TransformationName ::= pathNameCS
VariableName ::= simpleNameCS
TypeDeclaration ::= typeCS
BooleanOCLExpr ::= OclExpressionCS
QueryOCLExpr ::= OclExpressionCS
SlotOwnerOCLExpr ::= OclExpressionCS
ValueOCLExpr ::= OclExpressionCS
- Extent Of Change:
- Minor
- Created:
- Wed, 14 Oct 2015 13:06 GMT
- Updated:
- Wed, 14 Oct 2015 14:10 GMT
- Discussion:
- QVT13-127
- Title:
- Section: A1.1.1
- Summary:
-
top relation AssocToFKey { pKey : Key; ... when
{ ...; pKey = destTbl.key; }
... } In my opinion that doesn't work. pKey is of type
Key, destTbl.key is of type OrderedSet key, isn't it ?
- Source:
- ptc/07-07-07
— Chapter/Section: A1.1.1 — Page Number/s: 166
- Legacy
Issue Number:
- 11686
- Reporter:
- Siegfried Nolte, Siegfried Nolte
(siegfried@xxxxxxxxxxxxxxxxxx)
- Reported:
- Mon, 26 Nov 2007 05:00 GMT on QVT
1.0
- Updated:
- Wed, 14 Oct 2015 08:19 GMT
- Discussion:
- QVT13-4
- Summary:
-
Section: A1.1.1
top relation AssocToFKey { pKey : Key; ... when
{ ...; pKey = destTbl.key; }
... } In my opinion that doesn't work. pKey is of
type Key, destTbl.key is of type OrderedSet key,
isn't it ?
Discussion
Yes. Well at least it's a Collection; the diagram
leaves an ambiguity.
Comparison with the QVTc solution shows that the
'primary' key should be selected, and initialized on
creation.
Loading the example in the Eclipse QVTr editor
reveals many more problems.
- Revised Text:
-
In A.1.1.1
Replace all usage of "//" by "--"
Replace
key Table (name, schema);
key Column (name, owner);
key Key (name, owner);
by
key Table {name, schema};
key Column {name, owner};
key Key {name, owner};
Replace
key=k:Key {name=cn+'_pk', column=cl}};
by
_'key'=k:Key {name=cn+'_pk', column=cl,
kind='primary'}};
Replace
srcTbl, destTbl: Table;
pKey: Key;
by
srcTbl, destTbl: SimpleRDBMS::Table;
pKey: SimpleRDBMS::Key;
Replace
pKey = destTbl.key;
by
pKey = destTbl._'key'->select(kind='primary');
Replace
function
PrimitiveTypeToSqlType(primitiveTpe:String):String
by
query
PrimitiveTypeToSqlType(primitiveType:String):String
Replace
endif
endif;
by
endif
endif
- Extent Of Change:
- Support Text
- Created:
- Sun, 11 Oct 2015 15:26 GMT
- Updated:
- Sun, 11 Oct 2015 15:35 GMT
- Discussion:
- QVT13-117
- Title:
- Typedef aliases issue
- Summary:
-
Creating aliases seems to be a good idea specially when
dealing with complex types. However, for that purpose,
it is not clear to me that we need to create a (useless)
typedef just to represent an alias in the concrete
syntax. In practice aliases are very useful when writing
transformations (in concrete syntax), but they are
useless in the abstract syntax (extra unnecessary
classes in modules). One may still think that a typedef
as an alias (no extra condition) may be needed to add
operations to existing types, as specification suggests
doing in order to include new operations for the OCL
standard library predefined types. However, this still
can be done by means of helpers. Suggestions: - Remove
the statements related to aliases in the section
8.2.2.24 - Make Typedef.condition reference be mandatory
in Figure 8.7 since, now, Typedef in the abstract syntax
will be used to constrain existing types. - Add
statements in the concrete syntax section, to clarify
the use of aliases to rename existing types. Maybe, a
new keyword (like alias) could be included to avoid
confusions with the typedef one. - Change the grammar to
adapt it to these suggestions. - Clarify in the Standard
Library section that helpers will be used to add new
operations to the OCL Std Lib predefined type.
- Source:
- formal/08-04-03
— Chapter/Section: 8.2.2.24 — Page Number/s: 104
- Legacy
Issue Number:
- 13168
- Reporter:
- Adolfo Sanchez-Barbudo Herrera,
Open Canarias, SL (adolfosbh@xxxxxxxxxxxxxxxx)
- Reported:
- Thu, 18 Dec 2008 05:00 GMT on QVT
1.0
- Updated:
- Wed, 14 Oct 2015 07:58 GMT
- Discussion:
- QVT13-10
- Summary:
-
Typedef aliases issue
Creating aliases seems to be a good idea specially
when dealing with complex types. However, for that
purpose, it is not clear to me that we need to
create a (useless) typedef just to represent an
alias in the concrete syntax. In practice aliases
are very useful when writing transformations (in
concrete syntax), but they are useless in the
abstract syntax (extra unnecessary classes in
modules). One may still think that a typedef as an
alias (no extra condition) may be needed to add
operations to existing types, as specification
suggests doing in order to include new operations
for the OCL standard library predefined types.
However, this still can be done by means of helpers.
Suggestions: - Remove the statements related to
aliases in the section 8.2.2.24 - Make
Typedef.condition reference be mandatory in Figure
8.7 since, now, Typedef in the abstract syntax will
be used to constrain existing types. - Add
statements in the concrete syntax section, to
clarify the use of aliases to rename existing types.
Maybe, a new keyword (like alias) could be included
to avoid confusions with the typedef one. - Change
the grammar to adapt it to these suggestions. -
Clarify in the Standard Library section that helpers
will be used to add new operations to the OCL Std
Lib predefined type.
Discussion
Ignoring the QVT Standard Library usage eliminated
by the resolution of Issue 13252, http://solitaire.omg.org/browse/QVT13-13,
there are two distinct usages of typedef.
a) to create an alias
b) to create a new constrained type
Discussion - alias
If an alias introduces a new type as the
inheritance of Typedef from Type would suggest, we
have semantic nightmares. Which type conforms to
which? How do we ensure that all functionality
understands the typedef equivalence? As observed, a
typedef is a concrete syntax text macro that should
be eliminated during conversion to the abstract
syntax to avoid ambiguities. However an AS concept
is needed to persist the macro. A Tag is sufficient.
Discussion - constrained type
The typedef syntax with a constraint introduces a
new type. However all the important semantics of
this type are unspecified. What are the superclasses
of this type? What does it conform to? How do its
operations and properties interact with the
unconstrained type? Can a Constrained Integer be
used as a Sequence index?
The only example of a constrained type is:
typedef TopLevelPackage = Package
[container()=null];
suggesting that perhaps self is to be
interpreted as the type instance. If container()
is the proposed oclContainer() then the
example is particularly interesting. If a
TopLevelPackage is assigned to a container, how does
the type change? Are all assignments supposed to
have a predicate evaluation to ensure that typedef
constraints are not violated? Are assigned types to
be changed by an assignment? Does an assignment that
violates a constrained type constraint render a
transformation invalid and require some form of
failure?
Look at it another way. Suppose we used bland UML.
We can add an invariant to a class, which can
inherit/aggregate another type to re-use it. We and
general purpose tooling understand these semantics.
What does a typedef constrained type offer that is
new? just magic undefined semantics that cannot be
used with any non-QVTo tool.
The constrained typedef appears to be a clear case
of misguided syntax sugar. If metamodeling syntax
sugar is really needed, let it have a clear
relationship to UML.
Conclusion
The alias usage is a concrete syntax synonym that
has no need of a Typedef class; a Tag will do.
The constrained type is underspecified syntax
sugar. The Typedef class can be deprecated.
FWIW: neither of these forms of typedef is
implemented by Eclipse QVTo.
- Revised Text:
-
In 8.1.14 delete
Another mechanism is defined to make the type
system more flexible. The typedef mechanism allows
attaching additional
constraints to an existing type within a specific
context. It also serves to define aliases to
complex data types. When used
in the signature of a mapping operation, the
typedef constraints are added to the guard of the
mapping operation. The
condition is expressed within brackets after the
type taken as reference.
typedef TopLevelPackage = Package
[container()=null];
typedef AttributeOrOperation = Any [#Attribute or
#Operation];
typedef Activity =
ActionState[stereotypedBy("Activity")];
The type defined by a typedef is considered to be
in the scope of the model type of the type taken
as reference. For
instance, if Package exists in the context of a
UML modeltype, the TopLevelPackage is also
considered being defined in
the context of the UML modeltype.
The “#Metaclass” notation - respectively
'##Metaclass’ - is a shorthand for
isKindOf(Metaclass) - respectively
isTypeOf(Metaclass).
and replace
A typedef can also be used to simply define an
alias to a complex type, as for tuple types:
by
A typedef can be used to define an alias for a
complex type such as a tuple type:
In 8.2.2.22 replace
Figure 8.11 depicts the four new types, which
are: TemplateParameterType, Typedef,
DictionaryType, and ListType.
by
Figure 8.11 depicts the four new types, which
are: TemplateParameterType, Typedef (deprecated),
DictionaryType, and ListType.
Replace the whole of 8.2.2.23 Typedef by
8.2.2.23 Typedef (deprecated)
The Typedef class was underspecified and
unnecessary.
A type alias may be defined by using a typedef
construct.
A Constrained Type may be defined by adding an
invariant to a derived class.
Superclasses
Class
Associations
base : Type [1]
condition : OclExpression [0..1] {composes}
In 8.4.7 replace
8.4.7.1 Syntax for module definitions
by
// Syntax for module definitions
Replace
// typedefs
<typedef> ::= 'typedef' <identifier>
'=' <typespec> (typedef_condition)? ';'
<typedef_condition> ::= '['
<_expression_> ']'
by
<typedef> ::= 'typedef' <identifier>
'=' <typespec> ';'
and add
8.4.7.1 Deprecated syntax
The following alternative constructs may be
provided by tools offering backward compatibility
to earlier versions of the QVT specification.
// typedefs
<typedef> ::= 'typedef' <identifier>
'=' <typespec> (typedef_condition)? ';'
<typedef_condition> ::= '['
<_expression_> ']'
- Extent Of Change:
- Significant
- Created:
- Mon, 5 Oct 2015 19:52 GMT
- Updated:
- Sat, 10 Oct 2015 09:48 GMT
- Discussion:
- QVT13-89
- Title:
- ** QVTo Standard Library
- Summary:
-
-
- QVTo Standard Library. Some operation's returned
values would better return the
TemplateParameterType **
Several stdlib operations would be better changed
to avoid doing unnecessary castings on the
returned value of the operation.
For AnyType::oclAsType(oclType) operation I could
write:
var aClass : Class := anotherVar.oclAsType(Class);
However, for Model::objectsOfType(OclType) operation I
can't do:
var aClassSet : Set(Class) :=
aModel.objectsOfType(Class);
I have to do the following, instead:
var aClassSet : Set(Class) :=
aModel.objectsOfType(Class).oclAsType(Set(Class));
Therefore, for end-user usability, I propose exploiting
TemplateParameterType and changing some QVTo Standard
Library operations
Element::subobjectsOfType(OclType) : Set(T)
Element::allSubobjects(OclType) : Set(T)
Element::subobjectsOfKind(OclType) : Set(T)
Element::allSubobjectsOfKind(OclType) : Set(T)
Element::clone() : T
Element::deepclone() : T
Model::objectsOfType(OclType) : Set(T)
Model::copy() : T
Model::createEmptyModel(): T
Note: this approach is made in the
Object::asOrderedTuple() : OrderedTuple(T) operation.
- Source:
- formal/08-04-03
— Chapter/Section: 8.3 — Page Number/s: 104
- Legacy
Issue Number:
- 13181
- Reporter:
- Adolfo Sanchez-Barbudo Herrera,
Open Canarias, SL (adolfosbh@xxxxxxxxxxxxxxxx)
- Reported:
- Fri, 19 Dec 2008 05:00 GMT on QVT
1.0
- Updated:
- Wed, 14 Oct 2015 08:27 GMT
- Discussion:
- QVT13-12
- Summary:
-
8.3.5.7 createEmptyModel
static Model::createEmptyModel() : Model Creates and
initializes a model of the given type. This
operation is useful when creating intermediate
models within a transformation.
QVTo Standard Library. Some operation's returned
values would better return the TemplateParameterType
**
Several stdlib operations would be better changed to
avoid doing unnecessary castings on the returned
value of the operation.
For AnyType::oclAsType(oclType) operation I could
write:
var aClass : Class := anotherVar.oclAsType(Class);
However, for Model::objectsOfType(OclType)
operation I can't do:
var aClassSet : Set(Class) :=
aModel.objectsOfType(Class);
I have to do the following, instead:
var aClassSet : Set(Class) :=
aModel.objectsOfType(Class).oclAsType(Set(Class));
Therefore, for end-user usability, I propose
exploiting TemplateParameterType and changing some
QVTo Standard Library operations
Element::subobjectsOfType(OclType) : Set(T)
Element::allSubobjects(OclType) : Set(T)
Element::subobjectsOfKind(OclType) : Set(T)
Element::allSubobjectsOfKind(OclType) : Set(T)
Element::clone() : T
Element::deepclone() : T
Model::objectsOfType(OclType) : Set(T)
Model::copy() : T
Model::createEmptyModel(): T
Note: this approach is made in the
Object::asOrderedTuple() : OrderedTuple(T)
operation.
Discussion
subobjectsOfType etc duplicate QVT13-53
clone/deepclone merged into QVT13-53
Model::copy/createEmptyModel - NO. Model is the
correct return type.
See Issue QVT13-53
for disposition
- Created:
- Sat, 10 Oct 2015 19:03 GMT
- Updated:
- Sat, 10 Oct 2015 19:09 GMT
- Discussion:
- QVT13-107
- Title:
- QVT 1.1 QVTr syntax mapping (correction to
Issue 10646 resolution)
- Summary:
-
The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html
need to be addressed. Apologies too for the long email.
This is a very difficult area where precision is
important. Provision of
this resolution demonstrates the need for the
resolution, but unfortunately the resolution has an
erroneous precision that will make QVTr 1.1
unimplementable whereas QVTr 1.0 is just mildly
ambiguous and conflicting.
Please do not include the resolution in QVT 1.1 without
significantrework.
I found the definition of the "checkonly"/"enforce" to
isCheckable/isEnforceable helpful, although
different to three of my own intuitive guesses based on
attempts to avoid errors in ModelMorf and
Rel2Core examples.
The problems identified below are the result of a local
review of the resolution. In the absence of a
coherent Environment semantics it has not been possible
to perform a global review. In particular, I
was unable to review the specification for the arguably
redundant bindsTo.
[Incidentally, the same resolution
approach is needed for QVTc and QVTo].
Disambiguating rules
--------------------
The resolution uses a similar approach to the OCL 2.0
specification, but neglects to provide any
disambiguating rules although many are needed.
Environments
------------
OCL and the resolution employ environments to carry
definitions specific to particular CS constructs,
so that a CS reference may be resolved with the aid of
an environment or the AST.
In EssentialOCL, all definitions are resolvable with in
the immutable AST with the exception of let and
iterator expressions for which a nestedEnvironment() is
used to carry the extra variable declaration
with the aid of addElement(). The nestedEnvironment
supports name occlusion from outer scopes.
In CompleteOCL, further definitions may be introduced by
a definition constraint. The OCL
specification provides no precise insight into how an
environment changes to accommodate the
definition. Should the name be added to the AST or to
the environment? Is the name available for
forward reference?
Environment::addElement is defined as a query operation
thereby inhibiting side effects. Consequently
usage such as
XX.env = YY.env.addElement(Z.name, Z.ast, false)
leaves the environment of YY unchanged and creates an
extended environment for XX.
A series of such usages creates a series of
progressively elaborated environments that support
backward but not forward referencing. This was not a
clear requirement of the QVT 1.0 specification
and it prevents any variable declarations being
introduced in an object template tree being resolved
through environments in other object template trees or
predicate expressions.
QVT 1.2 RTF Report Page 173 of 190
Object Management Group
RTF/FTF Report
Imposition of no forward referencing seems very
undesirable, particularly since the order of domains is
imposed by the model parameter order. Imagine a Java
program in which all methods had to be
defined in a no-forward reference order.
As noted above, CompleteOCL neglected to define how AST
definitions were added to the AST. QVTr
must solve this problem since QVTr defines a
hierarchically scoped AST rather than an annotation of
a pre-existing AST.
I recommend a two stage approach. The inherited
attributes section should first compute an
environment from the pushed-down parent environment
augmented by pull-ups from child constructs
so that a complete immutable and consequently
unambiguous environment is associated with each
construct and then pushed-down to the children. During
the pull-up the environment acquires a
mapping from name to future-AST. During the push-down
residual future-AST attributes are populated
to give a valid AST.
Reference resolution
--------------------
OCL uses lookup functions to resolve variable
references. It is necessary either to overload the
lookup
functions so that the the distinct QVTr variable
definition sites can be located in the AST, or to use
some form of Environment::addElement where each
definition is defined so that resolution in the
environment is possible.
Details
=======
Throughout, many disambiguating rules are needed to
define illegal semantics. For instance "any" is
often used to select a syntactically valid value.
Corresponding usage in the OCL specification has a
disambiguating rule to clarify what the consequence of
not "one" is.
My current best attempt at Disambiguating Rules is
attached.
Environment::addElement takes three arguments, the third
being a mayBeImplicit argument. This has
been omitted throughout without explanation.
identifierCS
------------
OCL defines SimpleNameCS. A degenerate mapping from
identifierCS to SimplenameCS is required.
topLevelCS
----------
The 'imported transformation' environment element is
later referenced as 'imported transformations'.
Typo: TransformationListCS for transformationListCS in
Synthesized attributes.
importListCS
------------
Semantics of import conflicts must be defined.
unitCS
------
Typo: ast is not a Set.
Surely the import is of packages (enumerations or
operations)or at least transformations (QVTo
implementations) rather than necessarily
relational-transformations?
transformationCS
----------------
QVT 1.2 RTF Report Page 174 of 190
Object Management Group
RTF/FTF Report
ownedTag is not synthesized.
keyDeclListCS
-------------
Typo: wrong font in synthesized attributes
modelDeclCS
-----------
The [B] grammar:
modelDeclCS ::= modelIdCS ':' '
{' metaModelIdListCS '}
'
is missing.
keyDeclCS
---------
Synthesized attributes appear to have experienced a copy
and paste error while providing distinct part
and oppositePart left hand sides.
keyPropertyCS
-------------
The synthesized attributes poke the parent.
Suggest: it would be clearer for the parent to gather
and distribute children similar to the relation/query
allocation by transformationCS.
relationCS
----------
Transformation.extends does not appear to be transitive.
topQualifierCS
--------------
Suggest: a boolean or enumerated value rather than a
string.
domainListCS
------------
Typo: missing indentation.
primitiveTypeDomainCS
---------------------
isCheckable, isEnforceable not synthesized.
objectTemplateCS
----------------
Variable needs to be added to relation to provide a
container.
Variable needs to be added to relation environment to
provide visibility.
collectionTemplateCS
--------------------
Variable needs to be added to relation to provide a
container.
Variable needs to be added to relation environment to
provide visibility.
Suggest: last two if guards are redundant.
QVT 1.2 RTF Report Page 175 of 190
Object Management Group
RTF/FTF Report
restCS
------
Variable needs to be added to relation to provide a
container.
Non-_ named variable needs to be added to relation
environment to provide visibility.
memberCS
--------
Variable needs to be added to relation to provide a
container.
Non-_ named variable needs to be added to relation
environment to provide visibility.
whenCS
------
predicateListCS should be optional.
whereCS
-------
predicateListCS should be optional.
ExtOclExpressionCS
------------------
This is not present in the QVTr or OCL grammar.
Presumably it represents the QVTr extension to OCL's
OclExpressionCS.
However it is an extension, since at least
RelationCallExpCS can be used in an ordinary
OclExpressionCS using "not" or "and".
[A], [B],
[C] should therefore follow
on from OCL's
[A], [B],
[C]..., [I].
RelationCallExpressionCS
------------------------
How is a RelationCallExpressionCS distinguished from an
OperationCallExpCS?
- Legacy
Issue Number:
- 14640
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Mon, 16 Nov 2009 05:00 GMT on QVT
1.1
- Updated:
- Wed, 14 Oct 2015 07:49 GMT
- Discussion:
- QVT13-15
- Summary:
-
QVTr syntax mapping
(correction to Issue 10646 resolution)
The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html
need to be addressed. Apologies too for the long
email. This is a very difficult area where precision
is important. Provision of
this resolution demonstrates the need for the
resolution, but unfortunately the resolution has an
erroneous precision that will make QVTr 1.1
unimplementable whereas QVTr 1.0 is just mildly
ambiguous and conflicting.
Please do not include the resolution in QVT 1.1
without significantrework.
I found the definition of the "checkonly"/"enforce"
to isCheckable/isEnforceable helpful, although
different to three of my own intuitive guesses based
on attempts to avoid errors in ModelMorf and
Rel2Core examples.
The problems identified below are the result of a
local review of the resolution. In the absence of a
coherent Environment semantics it has not been
possible to perform a global review. In particular,
I
was unable to review the specification for the
arguably redundant bindsTo.
[Incidentally, the same
resolution approach is needed for QVTc and QVTo].
Disambiguating rules
--------------------
The resolution uses a similar approach to the OCL
2.0 specification, but neglects to provide any
disambiguating rules although many are needed.
Environments
------------
OCL and the resolution employ environments to carry
definitions specific to particular CS constructs,
so that a CS reference may be resolved with the aid
of an environment or the AST.
In EssentialOCL, all definitions are resolvable with
in the immutable AST with the exception of let and
iterator expressions for which a nestedEnvironment()
is used to carry the extra variable declaration
with the aid of addElement(). The nestedEnvironment
supports name occlusion from outer scopes.
In CompleteOCL, further definitions may be
introduced by a definition constraint. The OCL
specification provides no precise insight into how
an environment changes to accommodate the
definition. Should the name be added to the AST or
to the environment? Is the name available for
forward reference?
Environment::addElement is defined as a query
operation thereby inhibiting side effects.
Consequently
usage such as
XX.env = YY.env.addElement(Z.name, Z.ast, false)
leaves the environment of YY unchanged and creates
an extended environment for XX.
A series of such usages creates a series of
progressively elaborated environments that support
backward but not forward referencing. This was not a
clear requirement of the QVT 1.0 specification
and it prevents any variable declarations being
introduced in an object template tree being resolved
through environments in other object template trees
or predicate expressions.
QVT 1.2 RTF Report Page 173 of 190
Object Management Group
RTF/FTF Report
Imposition of no forward referencing seems very
undesirable, particularly since the order of domains
is
imposed by the model parameter order. Imagine a Java
program in which all methods had to be
defined in a no-forward reference order.
As noted above, CompleteOCL neglected to define how
AST definitions were added to the AST. QVTr
must solve this problem since QVTr defines a
hierarchically scoped AST rather than an annotation
of
a pre-existing AST.
I recommend a two stage approach. The inherited
attributes section should first compute an
environment from the pushed-down parent environment
augmented by pull-ups from child constructs
so that a complete immutable and consequently
unambiguous environment is associated with each
construct and then pushed-down to the children.
During the pull-up the environment acquires a
mapping from name to future-AST. During the
push-down residual future-AST attributes are
populated
to give a valid AST.
Reference resolution
--------------------
OCL uses lookup functions to resolve variable
references. It is necessary either to overload the
lookup
functions so that the the distinct QVTr variable
definition sites can be located in the AST, or to
use
some form of Environment::addElement where each
definition is defined so that resolution in the
environment is possible.
Details
=======
Throughout, many disambiguating rules are needed to
define illegal semantics. For instance "any" is
often used to select a syntactically valid value.
Corresponding usage in the OCL specification has a
disambiguating rule to clarify what the consequence
of not "one" is.
My current best attempt at Disambiguating Rules is
attached.
Environment::addElement takes three arguments, the
third being a mayBeImplicit argument. This has
been omitted throughout without explanation.
identifierCS
------------
OCL defines SimpleNameCS. A degenerate mapping from
identifierCS to SimplenameCS is required.
topLevelCS
----------
The 'imported transformation' environment element is
later referenced as 'imported transformations'.
Typo: TransformationListCS for transformationListCS
in Synthesized attributes.
importListCS
------------
Semantics of import conflicts must be defined.
unitCS
------
Typo: ast is not a Set.
Surely the import is of packages (enumerations or
operations)or at least transformations (QVTo
implementations) rather than necessarily
relational-transformations?
transformationCS
----------------
QVT 1.2 RTF Report Page 174 of 190
Object Management Group
RTF/FTF Report
ownedTag is not synthesized.
keyDeclListCS
-------------
Typo: wrong font in synthesized attributes
modelDeclCS
-----------
The [B] grammar:
modelDeclCS ::= modelIdCS ':' '
{' metaModelIdListCS '}
'
is missing.
keyDeclCS
---------
Synthesized attributes appear to have experienced a
copy and paste error while providing distinct part
and oppositePart left hand sides.
keyPropertyCS
-------------
The synthesized attributes poke the parent.
Suggest: it would be clearer for the parent to
gather and distribute children similar to the
relation/query
allocation by transformationCS.
relationCS
----------
Transformation.extends does not appear to be
transitive.
topQualifierCS
--------------
Suggest: a boolean or enumerated value rather than a
string.
domainListCS
------------
Typo: missing indentation.
primitiveTypeDomainCS
---------------------
isCheckable, isEnforceable not synthesized.
objectTemplateCS
----------------
Variable needs to be added to relation to provide a
container.
Variable needs to be added to relation environment
to provide visibility.
collectionTemplateCS
--------------------
Variable needs to be added to relation to provide a
container.
Variable needs to be added to relation environment
to provide visibility.
Suggest: last two if guards are redundant.
QVT 1.2 RTF Report Page 175 of 190
Object Management Group
RTF/FTF Report
restCS
------
Variable needs to be added to relation to provide a
container.
Non-_ named variable needs to be added to relation
environment to provide visibility.
memberCS
--------
Variable needs to be added to relation to provide a
container.
Non-_ named variable needs to be added to relation
environment to provide visibility.
whenCS
------
predicateListCS should be optional.
whereCS
-------
predicateListCS should be optional.
ExtOclExpressionCS
------------------
This is not present in the QVTr or OCL grammar.
Presumably it represents the QVTr extension to OCL's
OclExpressionCS.
However it is an extension, since at least
RelationCallExpCS can be used in an ordinary
OclExpressionCS using "not" or "and".
[A], [B],
[C] should therefore
follow on from OCL's
[A], [B],
[C]..., [I].
RelationCallExpressionCS
------------------------
How is a RelationCallExpressionCS distinguished from
an OperationCallExpCS?
Discussion
These issues cannot be sensibly addressed until the
auto-generation being pioneered for OCL can be
re-used.
- Created:
- Sun, 11 Oct 2015 12:52 GMT
- Updated:
- Sun, 11 Oct 2015 12:53 GMT
- Discussion:
- QVT13-115
- Title:
- QVT 1.1 8 Unclear mapping operation
characteristics
- Summary:
-
8.1.4 states "a mapping operation is always a
refinement of an implicit relation" but 8.2.15 defines
"refinedRelation: Relation [0..1]
The refined relation, if any." Clearly a contradiction.
8.1.4. provides the REL_PackageToSchema example of how
an implicit relation might be defined, but no other
examples or synthesis rules are supplied.
enforce and checkonly appear in the REL_PackageToSchema
example indicating that these define execution mode of a
QVTo trnasformation, but there does not appear to be any
description of how a transformation might be executed to
for instance update an output model. Perhaps the
'output' parameter is 'inout' for create/update but
'out' for create/overwrite.
- Legacy
Issue Number:
- 15390
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Fri, 30 Jul 2010 04:00 GMT on QVT
1.1
- Updated:
- Wed, 14 Oct 2015 07:49 GMT
- Discussion:
- QVT13-17
- Summary:
-
8 Unclear mapping
operation characteristics
8.1.4 states "a mapping operation is always a
refinement of an implicit relation" but 8.2.15
defines "refinedRelation: Relation [0..1] The refined relation,
if any." Clearly a contradiction.
8.1.4. provides the REL_PackageToSchema example of
how an implicit relation might be defined, but no
other examples or synthesis rules are supplied.
enforce and checkonly appear in the
REL_PackageToSchema example indicating that these
define execution mode of a QVTo trnasformation, but
there does not appear to be any description of how a
transformation might be executed to for instance
update an output model. Perhaps the 'output'
parameter is 'inout' for create/update but 'out' for
create/overwrite.
Discussion
The aspiration that every QVTo mapping has an
underlying QVTr relation is fairly dubious. But
there is no point respecifying until some
prototyping feedback is available.
- Created:
- Sat, 10 Oct 2015 17:40 GMT
- Updated:
- Sat, 10 Oct 2015 17:40 GMT
- Discussion:
- QVT13-104
- Title:
- Rule Overriding in QVTr
- Summary:
-
The abstract syntax of QVTr allows a rule to be an
override of another rule.
Rule::overrides: Rule [0..1]
The rule that this rule overrides.
The concrete syntax of QVT allows it too:
<relation> ::= ['top']
'relation' <identifier>
['overrides' <identifier>]
'
{'
....
'}
'
However, the only semantics I can see for 'overrides'
is in clause 7.11.1.4 that says:
"A rule may conditionally override another rule. The
overriding rule is executed in place of the overridden
rule when the overriding conditions are satisfied. The
exact semantics of overriding are subclass specific. "
Questions:
1- Whtat are the overriding conditions? are they
implied or specified and if so how?
2- I have not seen any other discussion of overrding in
a subclass or Rule so not sure what is meant by "The
exact semantics of overriding are subclass specific"?
3- I have not seen any example of using 'overrides'
what so ever in the spec, shouldn't there be one?
4 - What is the semantics of overriding? is it related
to inheritance in the OO sense ? I think QVTr needs a
good "inheritance" model where you can relations can be
called polymorphically.
- Legacy
Issue Number:
- 15417
- Reporter:
- Maged Elaasar, NASA
(Maged.E.Elaasar@xxxxxxxxxxxx)
- Reported:
- Fri, 13 Aug 2010 04:00 GMT on QVT
1.1
- Updated:
- Wed, 14 Oct 2015 12:22 GMT
- Discussion:
- QVT13-19
- Summary:
-
Rule Overriding in QVTr
The abstract syntax of QVTr allows a rule to be an
override of another rule.
Rule::overrides: Rule [0..1]
The rule that this rule overrides.
The concrete syntax of QVT allows it too:
<relation> ::= ['top']
'relation' <identifier>
['overrides' <identifier>]
'
{' .... '}
'
However, the only semantics I can see for
'overrides' is in clause 7.11.1.4 that says:
"A rule may conditionally override another rule.
The overriding rule is executed in place of the
overridden rule when the overriding conditions are
satisfied. The exact semantics of overriding are
subclass specific. "
Questions:
1- What are the overriding conditions? are they
implied or specified and if so how?
2- I have not seen any other discussion of
overriding in a subclass or Rule so not sure what is
meant by "The exact semantics of overriding are
subclass specific"?
3- I have not seen any example of using 'overrides'
what so ever in the spec, shouldn't there be one?
4 - What is the semantics of overriding? is it
related to inheritance in the OO sense ? I think
QVTr needs a good "inheritance" model where you can
relations can be called polymorphically.
Discussion
This now a much better understood field:
M. Wimmer, G. Kappel, A. Kusel, W. Retschitzegger,
J. Schönböck, W. Schwinger, D. Kolovos, R. Paige, M.
Lauder, A. Schürr, D. Wagelaar. Surveying Rule
Inheritance in Model-to-Model Transformation
Languages. In Journal of Object Technology, vol. 11,
no. 2, 2012, pages 3:1–46.
doi:10.5381/jot.2012.11.2.a3
QVTBase currently imposes single overriding which
is unnecessary, and causes a problem for an
application that needs to extend when B1 overrides A
and B2 overrides A. The extending mapping needs C to
override both B1 and B2 to ensure that C occludes
both B1 and B2. Therefore we need multi-overrides.
Oops. A QVTc Mapping::refines is an alternative
concept that competes without comment with the
inherited Rule::overrides. relToCore completely
ignores the semantics of overrides translation.
Relation::overrides should probably map across
unchanged to Mapping::overrides. QVTc and QVTr
semantics are unchanged.
Fixing this textually without a prototype is too
much of change.
- Created:
- Wed, 14 Oct 2015 10:15 GMT
- Updated:
- Wed, 14 Oct 2015 12:21 GMT
- Discussion:
- QVT13-126
- Title:
- QVTr already has queries but they are much
less user friendly than e.g. MOFM2T's equivelent
- Summary:
-
QVTr already has queries but they are much less user
friendly than e.g. MOFM2T's equivelent for which the
first parameter is a hidden self, or indeed QVTo.
Perhaps something closer to Complete OCL would do,
allowing def'd attributes or operations.
- Legacy
Issue Number:
- 15523
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Fri, 13 Aug 2010 04:00 GMT on QVT
1.1
- Updated:
- Wed, 14 Oct 2015 08:21 GMT
- Discussion:
- QVT13-20
- Summary:
-
QVTr already has queries
but they are much less user friendly than e.g.
MOFM2T's equivelent
QVTr already has queries but they are much less
user friendly than e.g. MOFM2T's equivelent for
which the first parameter is a hidden self, or
indeed QVTo.
Perhaps something closer to Complete OCL would do,
allowing def'd attributes or operations.
Discussion
QVTo has contextual helpers.
Syntactically it is trivial for QVTc and QVTo to
have contextual queries just by allowing a scoped
rather than simple name for the query.
Semantically to avoid duuplicating QVTo AS
irregularities we can use the synonym package merges
for Complete OCL to make the implementation easy.
- Revised Text:
-
In 7.13.5 replace
<query> ::= 'query' <identifier>
by
<query> ::= 'query' <queryId>
and add
<queryId> ::= <PathNameCS>
In 9.18 replace
Query ::= 'query' QueryName '('
by
Query ::= 'query' QueryId '('
and add
QueryId ::= PathNameCS
- Extent Of Change:
- Minor
- Created:
- Sun, 11 Oct 2015 14:06 GMT
- Updated:
- Sun, 11 Oct 2015 14:16 GMT
- Discussion:
- QVT13-116
- 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, 14 Oct 2015 18:46 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, 14 Oct 2015 18:45 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
re-use a previous execution, the output trace must
be the final outputs, not the preliminary outputs at
the end of the initialization section.
References to 8.1.12 refer to the new text from the
QVT13-99 resolution.
- Revised Text:
-
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 operations.
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. This includes any mappings executed by
accessed or extended transformations or libraries,
but not those by transformation invocations. Each
trace record comprises:
- context-parameter - the context (or
source) 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 (and inout)
parameter objects or values
- result-parameters - the result (or
target) parameter object or objects
The invoked-mapping and executed-mapping
operations may differ when a disjuncting
mapping is invoked. The invoked-mapping
is the disjuncting mapping. The executed-mapping
is the successfully selected candidate
mapping or null.
inout parameters are traced twice, once as in-parameters
and again as out-parameters.
The trace record is created with context-parameter,
in-parameters, invoked-mapping
and executed-mapping fields at the start
of the initialization section of the selected candidate
mapping. This is after predicates have been
executed as guards or pre-conditions. The
initially null value of the out-parameters
and result-parameters fields is updated
at the end of the candidate mapping
execution.
A trace record is created by every
mapping execution. If execution fails, the out-parameters
and result-parameters are null.
A trace record is created or re-used by
every mapping invocation. 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 trace record traces the
source/target relationship; it does not trace
object construction or helpers. If a trace is
needed, these untraced facilities must be wrapped
up inside a mapping.
8.1.x.2 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.3 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 operation.
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))->flatten() in
selectedTargets->selectByKind(TYPE)->select(T | CONDITION)
8.1.x.4 invresolve() - Resolution of source
objects by Type or Mapping
The corresponding inverse queries are available
using the invresolve or invresolveIn
operations. These identify source objects mapped
to a given type or by a given mapping.
target.invresolve(c : Class | c.name.startsWith('_'))
target.invresolveIn(Class2Table, c : Class | c.name.startsWith('_'))
8.1.x.5 resolveone() - Resolution of a single
source or target object by Type or Mapping
The four resolveone variants of the
four resolve operations 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.
source.resolveone(t : Table | t.name.startsWith('_'))
source.resolveoneIn(Class2Table, t : Table | t.name.startsWith('_'))
target.invresolveone(c : Class | c.name.startsWith('_'))
target.invresolveoneIn(Class2Table, c : Class | c.name.startsWith('_'))
8.1.x.6 Late resolution
The resolve operations 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. 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.7 Redundant execution
The trace data is used to suppress
re-execution of any previously executed mapping in
favor of the previous execution.
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. The out-parameters
and result-parameters fields of the
previous execution are re-used as the
corresponding returns of the re-execution attempt.
Note that traced Class instances are mutable and
so the re-used value may have changed in the
interim.
8.1.x.8 Persisted Trace Data
The trace data may be persisted and
reloaded to support a re-execution. However since
the trace record does not trace multiple
object states, configuration data, transformation
context or intermediate data, it is not possible
to use a persisted form of the trace data
to support incremental re-execution of an
arbitrary QVTo transformation. A well-behaved
transformation that avoids mutating objects 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 first define the semantic of the execution of
a mapping operation in absence of any inheritance
or merge reuse facility, then we describe the
effect of using these facilities.
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, 14 Oct 2015 18:44 GMT
- Discussion:
- QVT13-102
- Title:
- Undefined semantics for unsatisfied "when"
and "where" in inherited mapping
- Summary:
-
In operational QVT, it is not clear what happens when
the "when" or "where" clause of an inherited mapping
does not hold.
Suggestion:
Considering inheritance is a type (or, maybe, a synonym)
of generalization, it would be expected that the
semantics of inheritance mimics the semantics of
generalization in MOF. The UML, which defines
generalization used by CMOF and EMOF, states: "...
features specified for instances of the general
classifier are implicitly specified for instances of the
specific classifier. Any constraint applying to
instances of the general classifier also applies to
instances of the specific classifier." (UML
Infrastructure 2.4.1, p.51). If the "when" and "where"
clauses are considered as features of a mapping, the
clauses of the inherited mapping should be implicitly
specified. Similarly, if they are considered as
constraints applying to a mapping, the clauses defined
in the inherited mapping should apply to the inheriting
mapping. Therefore, a possible solution in both
situations is to consider that the "when" and "where"
clauses must hold in the inheriting mapping.
Commentary:
An interesting discussion is if something similar to the
Liskov substitution principle should be applied in this
situation.
- Source:
- formal/11-01-01
— Chapter/Section: 8.2.1.15 — Page Number/s: 93
- Legacy
Issue Number:
- 18363
- Reporter:
- Fáo Levy Siqueira, gmail.com
(levy.siqueira@xxxxxxxxx)
- Reported:
- Fri, 4 Jan 2013 05:00 GMT on QVT
1.1
- Updated:
- Wed, 14 Oct 2015 08:26 GMT
- Discussion:
- QVT13-24
- Summary:
-
Undefined semantics for
unsatisfied "when" and "where" in inherited mapping
In operational QVT, it is not clear what happens
when the "when" or "where" clause of an inherited
mapping does not hold.
Suggestion:
Considering inheritance is a type (or, maybe, a
synonym) of generalization, it would be expected
that the semantics of inheritance mimics the
semantics of generalization in MOF. The UML, which
defines generalization used by CMOF and EMOF,
states: "... features specified for instances of the
general classifier are implicitly specified for
instances of the specific classifier. Any constraint
applying to instances of the general classifier also
applies to instances of the specific classifier."
(UML Infrastructure 2.4.1, p.51). If the "when" and
"where" clauses are considered as features of a
mapping, the clauses of the inherited mapping should
be implicitly specified. Similarly, if they are
considered as constraints applying to a mapping, the
clauses defined in the inherited mapping should
apply to the inheriting mapping. Therefore, a
possible solution in both situations is to consider
that the "when" and "where" clauses must hold in the
inheriting mapping.
Commentary:
An interesting discussion is if something similar to
the Liskov substitution principle should be applied
in this situation.
Discussion
The suggestions regarding constraint inheritance
and LSP are appropriate for a declarative language;
they are not appropriate for a pragmatic imperative
language such as QVTo. Each mapping can be
independently specified.
It can be made clearer that pre and post conditions
are assertions that fail accordingly.
Comparison of QVTr/QVTo when and where highlights
the fallacy that a QVTo mapping is a refinement of
QVTr relation. In QVTo, failure of a where
post-condition is a catastrophic assertion failure,
whereas a QVTr where clause is a corrollary to be
attempted afterwards and ignored if it fails/fails
to match. The claim in 8.1.4 that the QVTo when and
where clauses are owned by QVTr is untrue; QVTo owns
its own when and where clauses and works very well
without any QVTr objects.
- Revised Text:
-
In 8.1.4 correct
A mapping operation is syntactically described by
a signature, a guard (a when clause) or
precondition, a mapping body, and a
postcondition (a where clause). Even if it is not
explicitly notated in the concrete syntax, a
mapping operation is always a refinement of an
implicit relation that is the owner of the
when and where clauses.
in 8.1.4 append
In strict invocation mode, a precondition (a when
clause) is executed as an assertion before any
other execution. Failure of the assertion causes a
fatal execution failure. A postcondition (a where
clause) is similarly executed as an assertion
after all other execution has completed.
In 8.2.1.15 following
The when clause acts either as a pre-condition or
as a guard, depending on the invocation mode of
the mapping operation. The where clause always
acts as a post-condition for the mapping
operation.
append
pre-conditions and post-conditions are
assertions; any execution failure is fatal.
- Extent Of Change:
- Minor
- Created:
- Sat, 10 Oct 2015 19:34 GMT
- Updated:
- Wed, 14 Oct 2015 08:26 GMT
- Discussion:
- QVT13-110
- Title:
- Enhance ObjectExp to allow constructors
invocation
- Summary:
-
Problem:
ObjectExp seems to be an enhancement to the
InstantationExp due to the additional semantics, however
it gets limited due to the fact that every time we need
to use it we have to define the constructor body (in
constrast to the instantiation _expression_ usage).
Although, ObjectExp was conceived to inline object
instantiations, this limitation is not justified.
However, this limitation could be removed by also
allowing an ObjectExp-Constructor combination, in the
same way we have for InstantiationExp. The problem
relies on a flaky concrete syntax which we could enhance
to exploit an ObjectExp with an already defined
constructor operation:
constructor Column::ColumnConstructor (n:String,t:
String)
{ name:=n; type:=t; }
object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);
Providing a constructor body (from ObjectExp) and a
list of arguments (from InstantiationExp) should be
prohibited in both, the concrete syntax and the abstract
syntax. Regarding the abstract syntax this could be
_expression_ with a constraint.
context ObjectExp
inv : argument->size() > 0 implies
body.oclIsUndefined()
Discussion:
This enhancement seems convenient with no apparent
drawbacks, since the old ObjectExp usage remains valid.
Proposed solution:
In section 8.2.1.24 add the following subsection:
Constraints
If an object _expression_ contains a constructor body, no
arguments for a constructor are allowed (and vice
versa):
context ObjectExp
inv: argument->notEmpty() > 0 implies
body.oclIsUndefined() and
not body.oclIsUndefined() implies argument->isEmpty()
In section 8.2.1.24 add the following to the the end
notation subsection:
Similarly to InstantiationExp, an object _expression_
could be used to invoke a constructor operation, rather
than inlining a constructor body:
object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);
Note that this notation allows us to use object
_expression_ to instantiate (or update) objects, while
having a reusable constructor in order to initialize (or
update) the properties of the object subject to be
created (or updated).
In section 8.4.7:
Replace:
<object_exp> ::= 'object' ('('
<iter_declarator> ')')? <object_declarator>
<expression_block>
By:
<object_exp> ::= 'object' ('('
<iter_declarator> ')')? <object_declarator>
(<expression_block> | '('
(<declarator_list>)? ')' )
- Source:
- formal/11-01-01
— Chapter/Section: 8.2.1.24 — Page Number/s: 102
- Legacy
Issue Number:
- 19023
- Reporter:
- Adolfo Sanchez-Barbudo Herrera,
Open Canarias, SL (adolfosbh@xxxxxxxxxxxxxxxx)
- Reported:
- Wed, 23 Oct 2013 04:00 GMT on QVT
1.1
- Updated:
- Wed, 14 Oct 2015 07:48 GMT
- Discussion:
- QVT13-25
- Summary:
-
Enhance ObjectExp to
allow constructors invocation
Problem:
ObjectExp seems to be an enhancement to the
InstantationExp due to the additional semantics,
however it gets limited due to the fact that every
time we need to use it we have to define the
constructor body (in constrast to the instantiation
_expression_ usage). Although, ObjectExp was conceived
to inline object instantiations, this limitation is
not justified.
However, this limitation could be removed by also
allowing an ObjectExp-Constructor combination, in
the same way we have for InstantiationExp. The
problem relies on a flaky concrete syntax which we
could enhance to exploit an ObjectExp with an
already defined constructor operation:
constructor Column::ColumnConstructor (n:String,t:
String)
{ name:=n; type:=t; }
object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);
Providing a constructor body (from ObjectExp) and a
list of arguments (from InstantiationExp) should be
prohibited in both, the concrete syntax and the
abstract syntax. Regarding the abstract syntax this
could be _expression_ with a constraint.
context ObjectExp
inv : argument->size() > 0 implies
body.oclIsUndefined()
Discussion:
This enhancement seems convenient with no apparent
drawbacks, since the old ObjectExp usage remains
valid.
Proposed solution:
In section 8.2.1.24 add the following subsection:
Constraints
If an object _expression_ contains a constructor
body, no arguments for a constructor are allowed
(and vice versa):
context ObjectExp
inv: argument->notEmpty() > 0 implies
body.oclIsUndefined() and
not body.oclIsUndefined() implies
argument->isEmpty()
In section 8.2.1.24 add the following to the the
end notation subsection:
Similarly to InstantiationExp, an object _expression_
could be used to invoke a constructor operation,
rather than inlining a constructor body:
object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);
Note that this notation allows us to use object
_expression_ to instantiate (or update) objects, while
having a reusable constructor in order to initialize
(or update) the properties of the object subject to
be created (or updated).
In section 8.4.7:
Replace:
<object_exp> ::= 'object' ('('
<iter_declarator> ')')?
<object_declarator>
<expression_block>
By:
<object_exp> ::= 'object' ('('
<iter_declarator> ')')?
<object_declarator>
(<expression_block> | '('
(<declarator_list>)? ')' )
Discussion
This was extensively discussed on the Eclipse
qvto-dev mailing list.
The conclusion was that the inheritance of
ObjectExp from InstantiationExp is pragmatic and
causes more problems that it solves. It should be
eliminated.
Allowing objects to be constructed by a constructor
_expression_ rather field assignment is a nice syntax
enhancement for significant utility classes.
It is hoped that a resolution will be prototyped
by:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=479657
- Created:
- Tue, 13 Oct 2015 14:32 GMT
- Updated:
- Tue, 13 Oct 2015 14:33 GMT
- Discussion:
- QVT13-122
- Title:
- invalid in QVT
- Summary:
-
OCL defines invalid as the result of a failed
evaluation. The QVT specification is almost totally
silent on invalid, except for a few library operations
that may generate it.
Presumably an invalid not 'caught' by
oclIsInvalid/oclIsUndefined in QVTo causes a
to-be-specifued exception to be raised in the problem
statement.
Presumably an invalid not 'caught' by
oclIsInvalid/oclIsUndefined in QVTc/QVTr inhibits the
detection of matches.
- Source:
- ptc/14-03-38
— Chapter/Section: 8 — Page Number/s: n/a
- Legacy
Issue Number:
- 19548
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Mon, 28 Jul 2014 04:00 GMT on QVT
1.2
- Updated:
- Wed, 14 Oct 2015 07:52 GMT
- Discussion:
- QVT13-29
- Summary:
-
invalid in QVT
OCL defines invalid as the result of a failed
evaluation. The QVT specification is almost totally
silent on invalid, except for a few library
operations that may generate it.
Presumably an invalid not 'caught' by
oclIsInvalid/oclIsUndefined in QVTo causes a
to-be-specifued exception to be raised in the
problem statement.
Presumably an invalid not 'caught' by
oclIsInvalid/oclIsUndefined in QVTc/QVTr inhibits
the detection of matches.
Discussion
But invalid may be temporarily caught by a let
variable of QVTo var. It is the use that is a
problem.
- Revised Text:
-
After 8.1.17 Null add
8.1.18 Invalid
When an OCL evaluation fails it does not raise an
Exception, rather it returns the invalid
value. The invalid may be the result of
a hard error such as divide-by-zero, or an
ordered-collection-index-out-of-bounds or a
programming problem such as navigation of a null
object.
Every use of a source value by an ImperativeExpression
has an implicit assertion that the source value is
not invalid, therefore using invalid
is an assertion failure.
Initialization of, or assignment to, a variable
stores rather than uses the value. invalid
may be stored in a variable, however subsequent
access of the variable will probably use it and
encounter an assertion failure. An invalid
value may be tested by the oclIsInvalid()
operation without causing a failure.
- Extent Of Change:
- Significant
- Created:
- Sat, 10 Oct 2015 18:08 GMT
- Updated:
- Wed, 14 Oct 2015 07:52 GMT
- Discussion:
- QVT13-105
- 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:
- Wed, 14 Oct 2015 13:00 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) {
var target := BODY;
if (target <> null) res += target->flatten();
};
}->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, 14 Oct 2015 13:00 GMT
- Discussion:
- QVT13-125
- Title:
- Support abstract mappings/relations
- Summary:
-
When mapping/relation refinement is used, it should be
possible to specify via the abstract keyword that a
mapping/relation is only intended for use in a refined
form.
Thus in A.3.1, declaring classAttributes abstract could
determine whether the execution needs to consider
matches not covered by the classPrimitiveAttributes and
classComplexAttributes refinements.
- Source:
- formal/11-01-01
— Chapter/Section: 7, 9 — Page Number/s: n/a
- Legacy
Issue Number:
- 19275
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Thu, 27 Feb 2014 05:00 GMT on QVT
1.1
- Updated:
- Wed, 14 Oct 2015 06:18 GMT
- Discussion:
- QVT13-40
- Summary:
-
Support abstract
mappings/relations
When mapping/relation refinement is used, it should
be possible to specify via the abstract keyword that
a mapping/relation is only intended for use in a
refined form.
Thus in A.3.1, declaring classAttributes abstract
could determine whether the execution needs to
consider matches not covered by the
classPrimitiveAttributes and classComplexAttributes
refinements.
Discussion
A simple enhancement
- Revised Text:
-
In Figure 7.4 and the QVTbase models add
Rule::isAbstract : Boolean [1].
In 7.11.1.4 Rule add
An abstract rule provides functionality that can
be exploited by refined rules. An abstract rule is
never matched directly and so never executes
directly.
In 7.11.1.4 Rule Associations add
isAbstract : Boolean[1]
indicates that the rule is abstract. Default is
false.
In 7.13.5 correct
<relation> ::= ['top'] ['abstract']
'relation' <identifier>
In 9.18 correct
Mapping ::=
['abstract'] 'map' MappingName ['in'
TransformationName] ['refines' MappingName] '{'
In A.3.1 correct
abstract map attributes in umlRdbms
refines flattening {
In A.3.1 correct
abstract map classAttributes in
umlRdbms refines attributes {
In A.3.1 correct
abstract map primitiveAttribute in
umlRdbms refines attributes {
In A.3.1 correct
abstract map
complexAttributeAttributes in umlRdbms refines
attributes {
In A.3.1 correct
abstract map complexAttribute in
umlRdbms refines attributes {
- Extent Of Change:
- Minor
- Created:
- Sat, 10 Oct 2015 21:22 GMT
- Updated:
- Wed, 14 Oct 2015 06:18 GMT
- Discussion:
- QVT13-111
- Title:
- Exact QVTr Collection match
- Summary:
-
The QVTr AS allows CollectionTemplateExp::rest to be
null corresponding to a precisely enumerated list of
collection members to be matched.
The QVTr CS does not support this.
Suggest changing the
'++' (restIdentifier=[pivot::Variable|UnrestrictedName]
| '_')
sub-parsing rule to
('++' (restIdentifier=[pivot::Variable|UnrestrictedName]
| '_'))?
- Legacy
Issue Number:
- 19663
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Fri, 28 Nov 2014 05:00 GMT on QVT
1.2
- Updated:
- Wed, 14 Oct 2015 05:10 GMT
- Discussion:
- QVT13-41
- Summary:
-
Exact QVTr Collection
match
The QVTr AS allows CollectionTemplateExp::rest to
be null corresponding to a precisely enumerated list
of collection members to be matched.
The QVTr CS does not support this.
Suggest changing the
'++' (restIdentifier=[pivot::Variable|UnrestrictedName]
| '_')
sub-parsing rule to
('++' (restIdentifier=[pivot::Variable|UnrestrictedName]
| '_'))?
- Revised Text:
-
In 7,13.5 replace
'++'
(<identifier> | '_')
by
['++' (<identifier> | '_')]
- Extent Of Change:
- Minor
- Created:
- Sat, 10 Oct 2015 21:51 GMT
- Updated:
- Sat, 10 Oct 2015 21:55 GMT
- Discussion:
- QVT13-112
- Title:
- QVTr Multi-root match
- Summary:
-
The QVTr AS and CS permit only a single pattern to be
matched in the input (and output) domains. QVTc permits
multi-matches.
This can be worked around with nested collections as
demonstrated by RDomainToMBottomPredicateForEnforcement
in RelToCore
remainingUnBoundDomainVars:
Set(essentialocl::Variable);
predicatesWithVarBindings:Set(qvtbase::Predicate);
domain relations rdtVarsSeq:Sequence(Set(Element)) {
rdtSet:Set(Element) {
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}}
++ _
}
++ _
};
rdtVarsSeq->at(2) = predicatesWithoutVarBindings;
rdtVarsSeq->at(3) = unboundDomainVars;
The above is hard to read and uses nested collections
in ways that are claimed to be unsupported. Much simpler
to just write:
domain relations
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}},
predicatesWithVarBindings:Set(qvtbase::Predicate) {},
remainingUnBoundDomainVars: Set(essentialocl::Variable)
{}
;
Suggest in the AS, RelationDomain.pattern changes to
RelationDomain.patterns, RelationDomain.rootVariable
moves to DomainPattern.rootVariable.
Suggest in the DomainCS CS, "pattern=DomainPatternCS"
changes to "patterns+=DomainPatternCS (','
patterns+=DomainPatternCS)*"
As a consequence additional variables may be passed in
a RelationCallExp. These can still be in rootVariable
order.
- Legacy
Issue Number:
- 19664
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Fri, 28 Nov 2014 05:00 GMT on QVT
1.2
- Updated:
- Wed, 14 Oct 2015 08:18 GMT
- Discussion:
- QVT13-42
- Summary:
-
QVTr Multi-root match
The QVTr AS and CS permit only a single pattern to
be matched in the input (and output) domains. QVTc
permits multi-matches.
This can be worked around with nested collections
as demonstrated by
RDomainToMBottomPredicateForEnforcement in RelToCore
remainingUnBoundDomainVars:
Set(essentialocl::Variable);
predicatesWithVarBindings:Set(qvtbase::Predicate);
domain relations rdtVarsSeq:Sequence(Set(Element))
{
rdtSet:Set(Element) {
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}}
++ _
}
++ _
};
rdtVarsSeq->at(2) =
predicatesWithoutVarBindings;
rdtVarsSeq->at(3) = unboundDomainVars;
The above is hard to read and uses nested
collections in ways that are claimed to be
unsupported. Much simpler to just write:
domain relations
r:Relation{},
rd:RelationDomain{},
te:ObjectTemplateExp {bindsTo = v:Variable {}},
predicatesWithVarBindings:Set(qvtbase::Predicate)
{},
remainingUnBoundDomainVars:
Set(essentialocl::Variable) {}
;
Suggest in the AS, RelationDomain.pattern changes
to RelationDomain.patterns,
RelationDomain.rootVariable moves to
DomainPattern.rootVariable.
Suggest in the DomainCS CS,
"pattern=DomainPatternCS" changes to
"patterns+=DomainPatternCS (','
patterns+=DomainPatternCS)*"
As a consequence additional variables may be passed
in a RelationCallExp. These can still be in
rootVariable order.
Discussion
This seems to be a completely unnecessary
restriction that caused the author of relToCore
significant difficulties.
The only downside seems to be a slight increase in
complexity of a RelationCallExp. No longer exactly
one argument per domain, but linearizing the roots
per domain is not exactly hard.
(The spelling in the discussion is that of the
Eclipse QVTr prototype. Changing pattern to patterns
is not appropriate for QVT1.x where property names
tend to be simple-singulars. Perhaps a change to
owned-plurals and so ownedPatterns may be
appropriate for QVT 2.0.)
Exploiting this in relToCore should wait until an
executable version has been debugged.
- Revised Text:
-
In the QVTr models and Fig 7.8 change
RelationDomain::pattern : DomainPattern[0..1]
to
RelationDomain::pattern : DomainPattern[*]
{ordered}
and
RelationDomain::rootVariable: Variable[1]
to
RelationDomain::rootVariable: Variable[+]
{ordered}
In 7.11.3.3 RelationDomain correct
A relation domain has aone
or more distinguished typed variablevariables
called the root variablevariables
that can be matched in a model of a given model
type. A relation domain specifies a set of model
elements of interest by means of a domain
pattern, which can be viewed as a
graph of object nodes, their properties and
association links, with aone or
more distinguished root nodenodes
that isare bound to the corresponding
root variable of the relation domain.
and
rootVariable: Variable[1+]
{ordered}
The distinguished typed variablevariables
of the relation domain that can be matched in a
model of a given model type.
and
pattern: DomainPattern [0..1] {composes ,ordered}
The domain patternpatterns
that specifiesspecify the
model elements of the relation domain. The root object
template _expression_ (i.e., the root node)
of theeach domain pattern
must be bound to the corresponding
root variable of the relation domain.
In 7.11.3.8 replace
The number and types of the arguments must match
the number of domains and types of the root
variables of the domains respectively.
by
The number and types of the arguments must match
the total number and types of the root variables
of the domains. The arguments are ordered firstly
by the order of the domains in the called
relation, and then by the order of the patterns of
each domain.
In 7.13.5 replace
<domain> ::=
[<checkEnforceQualifier>] 'domain'
<modelId> <template>
by
<domain> ::=
[<checkEnforceQualifier>] 'domain'
<modelId> <template> (','
<template>)*
- Extent Of Change:
- Significant
- Created:
- Sun, 11 Oct 2015 12:09 GMT
- Updated:
- Wed, 14 Oct 2015 08:17 GMT
- Discussion:
- QVT13-114
- Title:
- allInstances() needs clarification
- Summary:
-
OCL's allInstances() applies to the one and only
immutable model extent.
The meaning of this in QVT with multiple, some mutable,
extents/domains/typedModels is unclear.
Suggest that allInstances applies to all the input and
original inout extents only.
Obtaining instances from other domains is available
through alternate library operations such as
objectsOfType in QVTo.
- Source:
- ptc/14-03-38
— Chapter/Section: all — Page Number/s: all
- Legacy
Issue Number:
- 19621
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Thu, 25 Sep 2014 04:00 GMT on QVT
1.2
- Updated:
- Wed, 14 Oct 2015 07:47 GMT
- Discussion:
- QVT13-48
- Summary:
-
allInstances() needs
clarification
OCL's allInstances() applies to the one and only
immutable model extent.
The meaning of this in QVT with multiple, some
mutable, extents/domains/typedModels is unclear.
Suggest that allInstances applies to all the input
and original inout extents only.
Obtaining instances from other domains is available
through alternate library operations such as
objectsOfType in QVTo.
Discussion - QVTo
allInstances() could be defined to apply to the
initial, prevailing or final state. Since a QVTo
execution proceeds through a predictable sequence of
states limiting allInstances() to the initial state
is unhelpful. A limitation to the final state is
almost unuseable and may require a tool to introduce
another form of late processing. Therefore the
prevailing state is most appropriate for a QVTo
allInstances().The returned instances are the
mutable instances since any form of caching would
impose an unjustified overhead.
Discussion - QVTr/QVTc
allInstances() could be defined to apply to the
initial, prevailing or final state. The initial
state is easy. The prevailing state does not exist
declaratively. The final state is harder but may be
useful for computing derived output values based on
the outputs.
However consider a cascade of endogeneous
transformations A2B, B2C, C2D in which B2C performs
an allInstances(). If we now compose the trio into
A2B2C2D, the functionality of the allInstances()
must not change. Therefore neither initial nor final
state will do, since the initial state changes from
B to A and the final state from C to D. We must use
a prevailing state, which we can define as the final
state of the domain in which the invocation of
allInstances() occurs. For our example this is one
of B or C and does not change as a consequence of
the cascade.
- Revised Text:
-
Add a new sub-clause
6.5 OCL usage in QVT
The QVT languages introduce controlled mechanisms
for object mutation that conflict with OCL's
expectations of stability. These conflicts are
clarified in this subclause. .
Essential OCL is used as the expressions language
for QVT Relations, Core and Operational Mappings.
It is a side effect free language that supports
evaluation of constraints on the unchanging state
of the objects in a model. (<footnote>
Operation pre- and post-conditions and @pre extend
this to two states.)
The declarative QVTc and QVTr languages may
cascade mappings in which OCL evaluations access
intermediate objects. These evaluations occur
predictably for either an old or a new state of an
object. An old state is inherently stable. The new
state is stabilized by the declarative computation
of values before usage. An exception however
arises for allInstances() for which the
declarative mapping execution order is difficult
for a programmer to predict with certainty. allInstances()
is therefore defined to return the final state of
instances in the domain within which allInstances()
is invoked.
Imperative OCL is an extension of Essential OCL
with additional facilities to realize the side
effects required by QVT Operational Mappings.
The imperative QVTo language performs object
mutations as it advances from one program state to
another in a predictable order. OCL evaluation may
be used within each state. The functionality of allInstances()
is clarified in the Section 8.3.18.
Before "8.3.18 predefined tags" add
Operations on Classifiers
Classifier::allInstances() : Set(T)
The OCL definition is: The operation
allInstances() returns all instances of the
classifier and the classifiers specializing it.
May only be used for classifiers that have a
finite number of instances. This is the case,
for example, for user defined classes because
instances need to be created explicitly, and for
enumerations, the standard Boolean type, and
other special types such as OclVoid. This is not
the case, for example, for data types such as
collection types or the standard String,
UnlimitedNatural, Integer, and Real types.
This needs clarification for use in an imperative
QVTo context for which OCL's expectation of an
unchanging context is only valid within
sub-expressions of an ImperativeExpression.
For QVTo, the prevailing state is used; successive
calls to allInstances() may return
different sets of mutable instances.
Instances are returned from all the model extents
for input, inout and output models. Instances of
intermediate objects are not returned unless they
have been added to an extent. Instances from a
metamodel are not returned unless the metamodel is
also an input model. The Model::objectsOfKind()
operation may be used to return selected instances
from a particular model extent.
- Extent Of Change:
- Minor
- Created:
- Fri, 25 Sep 2015 10:25 GMT
- Updated:
- Wed, 14 Oct 2015 07:47 GMT
- Discussion:
- QVT13-66
- Title:
- QVTo Standard Library mode and namespace
- Summary:
-
The QVTo Standard Library has no model and consequently
no namespace.
This encourages a major confusion:
The QVToLib::Model and QVToLib::Transformation types
used in the QVTo Standard Library are at a different
meta-level to UML::Model and QVTbase::Transformation. We
have the uncomfortable situation that a QVToLib::Model
is an instance of a QVTbase::TypedModel and a
QVToLib::Transformation is an instance of a
QVTbase::Transformation.
As a minimum the distinct namespaces should be
identified and modeled.
Possibly QVToLib::Model and QVToLib::Transformation
should be renamed. Since they have no namespace they are
currently unuseable in code; their sole purpose is for
specification of implementation behavior.
- Source:
- formal/15-02-01
— Chapter/Section: 8.3 — Page Number/s: 124
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Thu, 30 Apr 2015 08:21 GMT on QVT
1.2
- Updated:
- Wed, 14 Oct 2015 07:47 GMT
- Discussion:
- QVT13-52
- Summary:
-
QVTo Standard Library
mode and namespace
The QVTo Standard Library has no model and
consequently no namespace.
This encourages a major confusion:
The QVToLib::Model and QVToLib::Transformation
types used in the QVTo Standard Library are at a
different meta-level to UML::Model and
QVTbase::Transformation. We have the uncomfortable
situation that a QVToLib::Model is an instance of a
QVTbase::TypedModel and a QVToLib::Transformation is
an instance of a QVTbase::Transformation.
As a minimum the distinct namespaces should be
identified and modeled.
Possibly QVToLib::Model and QVToLib::Transformation
should be renamed. Since they have no namespace they
are currently unuseable in code; their sole purpose
is for specification of implementation behavior.
Discussion
It is difficult to make sensible progress until the
OCL work in progress modeling libraries provides the
solution.
- Created:
- Sat, 10 Oct 2015 19:06 GMT
- Updated:
- Sat, 10 Oct 2015 19:07 GMT
- Discussion:
- QVT13-108
- Title:
- Define return type for objectsOf...(T)
operations more precisely
- Summary:
-
The objectsOf...(T) family of operations (e.g.
Element::subobjectsOfKind(T), or
Element::allSubobjectsOfType(T), or
Model::objectsOfType(T)) returns a set of Elements.
It should be possible to infer the precise return type
from the given T, i.e., return a Set(T) instead of
Set(Element).
BTW, why is there no Model::objectsOfKind(T) ?
- Legacy
Issue Number:
- 19760
- Reporter:
- Anonymous
- Reported:
- Tue, 19 May 2015 04:00 GMT on QVT
1.2
- Updated:
- Wed, 14 Oct 2015 07:38 GMT
- Discussion:
- QVT13-53
- Summary:
-
Define return type for
objectsOf...(T) operations more precisely
The objectsOf...(T) family of operations (e.g.
Element::subobjectsOfKind(T), or
Element::allSubobjectsOfType(T), or
Model::objectsOfType(T)) returns a set of Elements.
It should be possible to infer the precise return
type from the given T, i.e., return a Set(T) instead
of Set(Element).
BTW, why is there no Model::objectsOfKind(T) ?
Discussion
We can make the declaraions using the same
approximation to a rigorous declaration as used by
selectByKind in OCL 2.4.
Omission of objectsOfKInd is an easily corrected
oversight.
The incorrect objectsOfKind usage by the current
objectsOfType is a confusing error that gets worse
when the correct operation is provided. Better to
correct it.
clone and deepClone from QVT13-12
can similarly exploit a T.
The confusing wording of Model::createEmptyModel
can be clarified,
- Revised Text:
-
In 8.3.4.6 subobjectsOfType correct
Element::subobjectsOfType(OclTypetype
: Classifier) : Set(ElementT)
add
The returned Set element type T is the type
specified as type.
In 8.3.4.7 allSubobjectsOfType correct
Element::allSubobjectsOfType(OclTypetype
: Classifier) : Set(ElementT)
add
The returned Set element type T is the type
specified as type.
In 8.3.4.8 subobjectsOfKind correct
Element::subobjectsOfKind(OclTypetype
: Classifier) : Set(ElementT)
add
The returned Set element type T is the type
specified as type.
In 8.3.4.9 allSubobjectsOfKind correct
Element::allSubobjectsOfKind(OclTypetype
: Classifier) : Set(ElementT)
add
The returned Set element type T is the type
specified as type.
In 8.3.4.10 clone correct
Element::clone() : ElementT
add
The returned type T is the type of the source
element as known at compile time.
In 8.3.4.11 deepclone correct
Element::deepclone() : ElementT
add
The returned type T is the type of the source
element as known at compile time.
Before 8.3.5.2 objectsOfType add
8.3.5.2 objectsOfKind
Model::objectsOfKind(type : Classifier) : Set(T)
Returns the list of the objects in the model
extent that have the type given.
The returned Set element type T is the type
specified as type.
In 8.3.5.2 objectsOfType correct
Model::objectsOfType(OclTypetype
: Classifier) : Set(ElementT)
Returns the list of the objects in the model
extent that have the exact type given.
The returned Element type is the type denoted
by the type _expression_.The returned
Set element type T is the type specified as type.
in 8.3.5.7 createEmptyModel correct
Creates and initializes a model of the
giventhis model's model type.
- Extent Of Change:
- Significant
- Created:
- Sat, 10 Oct 2015 18:36 GMT
- Updated:
- Wed, 14 Oct 2015 07:37 GMT
- Discussion:
- QVT13-106
- Title:
- Unspecified handling of imports without
access/extends
- Summary:
-
For imported compilation units, the specification
should clearly state what happens if there is no
corresponding ModuleImport for any of the modules
included inside the imported unit.
The Eclipse QVTo implementation applies extends
semantics by default. A very bad idea, because it leads
to undesired extensions and overridings (especially in
case of multiple modules per unit).
Using access as a default is a much better idea, but
maybe clutters the namespaces at AST level with needless
module imports.
Therefore applying neither access nor extends could be
another good idea, but lacks a helpful default behavior.
- Source:
- formal/15-02-01
— Chapter/Section: 8.2.1.4 ModuleImport — Page Number/s:
85
- Legacy
Issue Number:
- 19816
- Reporter:
- Christopher Gerking, Heinz
Nixdorf Institute, University of Paderborn
(christopher.gerking@xxxxxx)
- Reported:
- Thu, 9 Jul 2015 04:00 GMT on MOF
1.2
- Updated:
- Wed, 14 Oct 2015 12:58 GMT
- Discussion:
- QVT13-58
- Summary:
-
Unspecified handling of
imports without access/extends
For imported compilation units, the specification
should clearly state what happens if there is no
corresponding ModuleImport for any of the modules
included inside the imported unit.
The Eclipse QVTo implementation applies extends
semantics by default. A very bad idea, because it
leads to undesired extensions and overridings
(especially in case of multiple modules per unit).
Using access as a default is a much better idea,
but maybe clutters the namespaces at AST level with
needless module imports.
Therefore applying neither access nor extends could
be another good idea, but lacks a helpful default
behavior.
Discussion
Following some off-JIRA correspondence, the
original issue is clearer and simpler.
The 8.2.1.4 words say that ImportKind has only two
possibilities. But the words and model omit a [1]
multiplicity or defaultValue so that null is a third
possibility. The grammar also permits a missing
ImportKind.
So as suggested we could introduce a third null
semantics, or define one of access/extends as the
default.
I see no benefit in a third semantics.
"extends" is a very serious mutating activity, not
a default.
"access" is harmless and non-mutating. Hardly AST
clutter. If the user didn't want the names the user
should not have specified an import.
Let "access" be the default.
- Revised Text:
-
In 8.2.1.4 ModuleImport
The semantics of the library import. Possible
values are access and extension. access is the
default.
In the QVTo model change ModuleImport.kind
lowerbound to 0..11 and
defaultValue to unspecifiedaccess.
Consequently show the [1] multiplicity in 8.2.1.4
and Figure 8.1.
- Extent Of Change:
- Minor
- Created:
- Fri, 25 Sep 2015 09:48 GMT
- Updated:
- Wed, 14 Oct 2015 12:58 GMT
- Discussion:
- QVT13-63
- Title:
- What are the QVTo mapping overloading
semantics?
- Summary:
-
QVTo has one form of mapping overloading provided by
disjuncts. This is poorly specified.
It probably has another provided by name collision.
This is unspecified.
- Source:
- formal/15-02-01
— Chapter/Section: 8.1.13 — Page Number/s: 73
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Tue, 6 Oct 2015 19:34 GMT on MOF
1.2
- Updated:
- Wed, 14 Oct 2015 18:46 GMT
- Discussion:
- QVT13-99
- Summary:
-
What are the QVTo mapping
overloading semantics?
QVTo has one form of mapping overloading provided
by disjuncts. This is poorly specified.
It probably has another provided by name collision.
This is unspecified.
- Revised Text:
-
Replace Section 8.1.13 with the following text to
be placed before the current 8.1.12.
8.1.12 Mapping Overloading
Invocation of a mapping selects a disjunction of
one or more candidate mapping's at
compile time. At run-time, the first matching candidate
mapping is selected and invoked. The
disjunction may be specified explicitly using the
disjuncts keyword or implicitly by an
overloaded mapping.
8.1.12.1 Explicit Disjuncts
In the following example, the explicit
disjunction defines convertFeature as a
disjuncting mapping name that may be
invoked on a UML::Feature with a Boolean
argument. convertAttribute, convertConstructor
and convertOperation are candidate
mapping names.
mapping UML::Feature::convertFeature(asUpper: Boolean) : JAVA::Element
disjuncts convertAttribute, convertOperation, convertConstructor {}
mapping UML::Attribute::convertAttribute(asUpper: Boolean) : JAVA::Field {
name := if asUpper then name.toUpper() else name endif;
}
mapping UML::Operation::convertConstructor(asUpper: Boolean) : JAVA::Constructor
when {self.name = self.namespace.name;} {
name := if asUpper then name.toUpper() else name endif;
}
mapping UML::Operation::convertOperation(asUpper: Boolean) : JAVA::Constructor
when {self.name <> self.namespace.name;} {
name := if asUpper then name.toUpper() else name endif;
}
The explicit disjuncts causes the
mapping invocation to successively assess the
implicit and explicit predicates of convertAttribute,
convertConstructor and convertOperation
to identify the first match. If no match is found
the mapping invocation returns null.
The explicit predicates are provided by arbitrary
constraints specified in when clauses.
Implicit predicates are provided by the type
signatures; each source and argument must conform
to the type of the corresponding candidate
mapping parameter.
The candidate return type must be
covariant, that is the same as, or derived from
that of, the disjuncting return type to
ensure that no result incompatibility arises.
Since the argument types contribute to implicit
predicates, the candidate parameter
types may be supertypes or subtypes of the disjuncting
mapping parameter type. The number of candidate
and disjuncting parameter types must be
the same.
An explicit candidate mapping is
identified by its mapping identifier
which may contribute to more than one disjunction.
8.1.12.2 Implicit Disjuncts
An implicit disjunction groups overloaded
mappings. One mapping overloads another when the
overloading source type extends the overloaded
source type and when the overloading and
overloaded mappings have same name and parameter
count. Every mapping declaration establishes an
implicit disjunction of itself and all its
overloads, which may be in an extending
transformation.
When UML::Attrbute and UML::Operation
extend UML::Feature, the previous
example may be simplified to use an implicit
disjunction.
mapping UML::Feature::convertFeature(asUpper: Boolean) : JAVA::Element {}
mapping UML::Attribute::convertFeature(asUpper: Boolean) : JAVA::Field {
name := if asUpper then name.toUpper() else name endif;
}
mapping UML::Operation::convertFeature(asUpper: Boolean) : JAVA::Constructor
when {self.name = self.namespace.name;} {
name := if asUpper then name.toUpper() else name endif;
}
mapping UML::Operation::convertFeature(asUpper: Boolean) : JAVA::Constructor
when {self.name <> self.namespace.name;} {
name := if asUpper then name.toUpper() else name endif;
}
he explicit disjuncts provides distinct names and
so facilitates explicit calls direct to the candidate
mappings. The implicit disjuncts requires no disjuncting
declaration and so faciltates extension by
addition of further contributions.
8.1.12.3 Disjunct candidates
All mappings with the required name, parameter
count and matching or derived source type are candidate
mapping's for the invocation of a disjuncting
mapping. This includes mappings inherited
from extended transformations. The candidate
mapping's referenced in a disjuncting
mapping may introduce new names and
consequently a further disjunction of candidate
mapping's; the explicit disjunct is
transitive.
For instance invocation of convertFeature
for a Property in the explicit disjuncts
example should consider a Property::convertOperation(Boolean)
inherited from an extended transformation since
the explicit disjunct adds convertOperation
to the transitive candidates. Conversely, the
implicit disjunct example considers only
candidates whose signature is convertFeature(Boolean).
For standard evaluation, a deterministic
selection order for evaluation of the predicates
of the candidates as guards is established by
sorting using the following proritized criteria. A
distinction by an earlier criteria overrules all
later criteria.
- directly invoked explicitly disjuncted
candidate mappings are evaluated in declaration
order
- mappings in the current transformation are
selected before those in an extended
transformation, then mappings in an extended
transformation before those in an extended
extended transformation, and so forth
- mappings for a more derived type are selected
before those for a less derived type
- mappings are prioritized by alphabetical
mapping name order
- mappings are prioritized by alphabetical
context type name order
- mappings are prioritized by alphabetical
context type containing package name order, then
by containing package containing package name
order, and so forth
The ordering above ensures that an extending
transformation can occlude a mapping in an
extended transformation and that a mapping for a
derived type occludes that for a base type. (An
implementation may use static analysis of the
predicates to eliminate occluded candidates
completely and to provide reduced candidate lists
according to the source type of the mapping
invocation.)
For strict evaluation, the same ordering applies
but the first candidate for which the source type
conforms is selected without evaluating the
predicate as a guard. The predicate is instead
evaluated as a pre-condition giving an assertion
failue when not satisfied.
In 8.2.1.15 Replace
Resolving the mapping call implies finding the
operation to call on the basis of the actual type
of the source (self variable). This follows usual
object-oriented virtual call semantics.
by
Resolving the mapping call implies building a
prioritized list of candidate mapping's
then selecting the first candidate mapping
for which, using standard invocation mode, all
predicates are satisfied. For strict invocation
mode, the first candidate mapping for
which the source object (self variable) conforms
to the context type is selected and predicates are
executed as pre-conditions. If no candidate
mapping is identified, null is
returned to all results. Building the prioritized
candidate mapping list is described as
part of the Mapping Overloading description in
Section 8.1.12.
In 8.2.1.16 Delete
Executing mappings defined as disjunction of
other mappings
An invocation of a mapping operation defined as a
disjunction of other mapping operations is done in
two steps: firstly,
the guards of the disjuncted mappings are executed
in sequence until one of the guards succeeds. If
no guard succeeds, the
null value is immediately returned. Otherwise, the
body of the mapping which guard has succeeded is
executed. The
signature of the disjuncting mapping must conform
to the signature of the disjuncted mappings,
following ordinary
constraints between the caller and the callee.
Specifically, the result of the disjunction needs
to be a super type of the
result type of the composed mappings.
I
- Extent Of Change:
- Significant
- Created:
- Tue, 6 Oct 2015 19:59 GMT
- Updated:
- Mon, 12 Oct 2015 11:08 GMT
- Discussion:
- QVT13-100
- Title:
- QVTc/QVTo/QVTr acronyms
- Summary:
-
The full names of the QVT languages are a bit
cumbersome and so QVTc/QVTo/QVTr are often found in
non-OMG usage.
Suggest that the QVT specification at least define them
and perhaps use them a little too.
- Source:
- formal/15-02-01
— Chapter/Section: 1 — Page Number/s: 1
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Wed, 7 Oct 2015 11:51 GMT on MOF
1.2
- Updated:
- Wed, 14 Oct 2015 07:39 GMT
- Discussion:
- QVT13-101
- Summary:
-
QVTc/QVTo/QVTr acronyms
The full names of the QVT languages are a bit
cumbersome and so QVTc/QVTo/QVTr are often found in
non-OMG usage.
Suggest that the QVT specification at least define
them and perhaps use them a little too.
- Revised Text:
-
Correct
6.1.1 QVTr - Relations Language
Correct
6.1.2 QVTc - Core Language
Correct
6.2.1 QVTo - Operational Mappings
Language
- Extent Of Change:
- Support Text
- Created:
- Sat, 10 Oct 2015 19:14 GMT
- Updated:
- Sat, 10 Oct 2015 19:19 GMT
- Discussion:
- QVT13-109
The OMG Team
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4447/10823 - Release
Date: 10/15/15
|
