Hi
The more significant issues for ballot 2 are previewed below.
Comments welcome.
I don't think anything changes, but a number of things are
clarified. QVT13-26 is perhaps the
only extension definitely requiring some code.
Oops I see that I scheduled QVT13-58
which we are still discussing. May need to withdraw it.
(Somehow JRA is confused. The ballot opens on 15th Oct.)
Regards
Ed Willink
-------- Forwarded Message --------
- Issues:
- 25
- Ballot
Opens:
- Wed, 7 Oct 2015 06:40 GMT
- Ballot
Closes:
- Fri, 23 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 semantics
- Summary:
-
The whole Concrete Syntax section deserves a much more
substantial description.
In particular...
The mechanism by which a package name is located is
unresolved, perhaps deliberately,
but the omission should be explicit.
What constraints exist on forward referencing of names?
Transformations and mappings could be ordered so that
forward references are avoided,
but large modules benefit from an alphabetical ordering
of elements, so requiring
a parser friendly order is not user friendly.
- Legacy
Issue Number:
- 10936
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Sun, 25 Mar 2007 04:00 GMT on QVT
1.0
- Updated:
- Wed, 7 Oct 2015 06:36 GMT
- Discussion:
- QVT13-3
- Summary:
-
9.18 Undefined semantics
The whole Concrete Syntax section deserves a much
more substantial description.
In particular...
The mechanism by which a package name is located is
unresolved, perhaps deliberately,
but the omission should be explicit.
What constraints exist on forward referencing of
names?
Transformations and mappings could be ordered so
that forward references are avoided,
but large modules benefit from an alphabetical
ordering of elements, so requiring
a parser friendly order is not user friendly.
Discussion
This isn't going to happen until a QVT 2.0 rewrite
adopts the autogeneration approaches underway for
OCL.
- Created:
- Mon, 5 Oct 2015 16:49 GMT
- Updated:
- Mon, 5 Oct 2015 16:51 GMT
- Discussion:
- QVT13-83
- Title:
- current abstract syntax of ImperativeOCL
introduces a couple of unclear situations
- Summary:
-
Major Problem:
(1) The current abstract syntax of ImperativeOCL
introduces a couple of
unclear situations. This may lead to incompatible QVT
implementations.
Further Problems:
(2) Control flow constructs introduced by ImperativeOCL
are redundant
compared with existing conventional OCL constructs.
(3) Several OCL equivalence rules break when
ImperativeOCL is present.
Detailed problem description:
(1) The current abstract syntax of ImperativeOCL
introduces a couple of
unclear situations. This may lead to incompatible QVT
implementations.
In the abstract syntax, ImperativeOCL expressions /
statements are
inherited from OclExpression. Therefore, conventional
OCL
expressions may (and will) contain sub-expressions that
are
actually ImperativeOCL expressions.
In conventional OCL, the interpretation of an _expression_
under a
given environment is a value. In ImperativeOCL, the
interpretation
of an _expression_ is a value and a new environment
(state,variables). This extended interpretation is not
given for
conventional OCL expressions, leading to undefined
operational
semantics of those expressions.
Example: Given the following compute _expression_:
compute(z:Boolean) {
var x : Boolean := true
var y : Boolean := true
if ((x:=false) and (y:=false))
{ ... }
z := y
}
What is the value of this _expression_: is it true or
false (It
depends on whether the 'and' operator is evaluated
short-circuit
or strict). The situation is similar for the evaluation
of the
other logical connectives, forAll, and exists when these
expressions contain imperative sub-expressions.
(2) Control flow constructs introduced by ImperativeOCL
are redundant
compared with existing conventional OCL constructs.
Some of the new language features in ImperativeOCL such
as forEach
and the imperative conditional are not really necessary.
Their
effect can already be achieved using conventional OCL
expressions:
For example:
company.employees->forEach(c)
{ c.salary := c.salary * 1.1}
has the same effect as
company.employees->iterate(c; r:OclAny=Undefined |
c.salary := c.salary * 1.1
)
and
if ( x < 0 )
{ x := 0 }
else
{ x := 1 }
endif is the same as
if x < 0 then x := 0 else x := 1 endif
(3) Several OCL equivalence rules break when
ImperativeOCL is present.
In conventional OCL, several equivalence rules well
known from
logic hold. Allowing OCL _expression_ to contain
imperative
sub-expressions breaks these equivalence rules.
Examples:
let x=e1 in e2 equiv. e2
{ all occurences of x replaced by e1 }
e1 and e2 equiv. e2 and e1
These equivalences do not necessarily hold if e1 or e2
are allowed
to have side-effects.
Proposed solution:
(A) - (The cheap solution.) State textually that
conventional OCL
expressions (as described in the OMG OCL spec.) are not
allowed to have side effects unless used as part of a
top
level ImperativeOCL _expression_. Therefore, even in a
system
supporting ImperativeOCL, class invariants, and pre- and
postconditions (e.g.) will not be allowed to contain
ImperativeOCL sub-expressions.
State explicitly that the redundant flow control
statements
have been introduced (solely) to write concise
imperative
programs and that the side-effect free forms of
conditional
evaluation ( 'if-then-else-endif' and 'iterate' ) shall
not be
used to program side-effects (instead, the ImperativeOCL
forms
shall be used).
(B) - (Major rework.) Rework the abstract syntax to
reuse OCL
expressions by composition rather than by inheritance.
Imperative expressions ( => rename to 'statements' )
then may
contain sub-statements and OCL expressions; OCL
expressions
are reused unchanged from the OCL spec (no imperative
sub-expressions, no side-effects).
These issues have been discussed on the MoDELS 2008 OCL
Workshop,
more details can be found at
http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf
- Legacy
Issue Number:
- 13082
- Reporter:
- Anonymous
- Reported:
- Sat, 15 Nov 2008 05:00 GMT on QVT
1.0
- Updated:
- Wed, 7 Oct 2015 06:33 GMT
- Discussion:
- QVT13-8
- Summary:
-
current abstract syntax
of ImperativeOCL introduces a couple of unclear
situations
Major Problem:
(1) The current abstract syntax of ImperativeOCL
introduces a couple of unclear situations. This may
lead to incompatible QVT implementations.
Further Problems:
(2) Control flow constructs introduced by
ImperativeOCL are redundant compared with existing
conventional OCL constructs.
(3) Several OCL equivalence rules break when
ImperativeOCL is present.
Detailed problem description:
(1) The current abstract syntax of ImperativeOCL
introduces a couple of unclear situations. This may
lead to incompatible QVT implementations.
In the abstract syntax, ImperativeOCL expressions /
statements are inherited from OclExpression.
Therefore, conventional OCL expressions may (and
will) contain sub-expressions that are actually
ImperativeOCL expressions. In conventional OCL, the
interpretation of an _expression_ under a given
environment is a value. In ImperativeOCL, the
interpretation of an _expression_ is a value and a new
environment (state,variables). This extended
interpretation is not given for conventional OCL
expressions, leading to undefined operational
semantics of those expressions.
Example: Given the following compute _expression_:
compute(z:Boolean) {
var x : Boolean := true
var y : Boolean := true
if ((x:=false) and (y:=false))
{ ... }
z := y
}
What is the value of this _expression_: is it true or
false (It depends on whether the 'and' operator is
evaluated short-circuit or strict). The situation is
similar for the evaluation of the other logical
connectives, forAll, and exists when these
expressions contain imperative sub-expressions.
(2) Control flow constructs introduced by
ImperativeOCL are redundant compared with existing
conventional OCL constructs.
Some of the new language features in ImperativeOCL
such as forEach and the imperative conditional are
not really necessary. Their effect can already be
achieved using conventional OCL expressions:
For example:
company.employees->forEach(c)
{ c.salary := c.salary * 1.1}
has the same effect as
company.employees->iterate(c; r:OclAny=Undefined
|
c.salary := c.salary * 1.1
)
and
if ( x < 0 )
{ x := 0 }
else
{ x := 1 }
endif is the same as
if x < 0 then x := 0 else x := 1 endif
(3) Several OCL equivalence rules break when
ImperativeOCL is present.
In conventional OCL, several equivalence rules well
known from logic hold. Allowing OCL _expression_ to
contain imperative sub-expressions breaks these
equivalence rules.
Examples:
let x=e1 in e2 equiv. e2
{ all occurences of x replaced by e1 }
e1 and e2 equiv. e2 and e1
These equivalences do not necessarily hold if e1 or
e2 are allowed to have side-effects.
Proposed solution:
(A) - (The cheap solution.) State textually that
conventional OCL expressions (as described in the
OMG OCL spec.) are not allowed to have side effects
unless used as part of a top level ImperativeOCL
_expression_. Therefore, even in a system supporting
ImperativeOCL, class invariants, and pre- and
postconditions (e.g.) will not be allowed to contain
ImperativeOCL sub-expressions.
State explicitly that the redundant flow control
statements have been introduced (solely) to write
concise imperative programs and that the side-effect
free forms of conditional evaluation (
'if-then-else-endif' and 'iterate' ) shall not be
used to program side-effects (instead, the
ImperativeOCL forms shall be used).
(B) - (Major rework.) Rework the abstract syntax to
reuse OCL expressions by composition rather than by
inheritance.
Imperative expressions ( => rename to
'statements' ) then may contain sub-statements and
OCL expressions; OCL expressions are reused
unchanged from the OCL spec (no imperative
sub-expressions, no side-effects).
These issues have been discussed on the MoDELS 2008
OCL Workshop, more details can be found at http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf
Discussion - 1 short circuit semantics
It is possible to weasel out of this narrowly
described problem by observing that OCL only
supports short-circuit semantics once it is proven
that no invalid lurks beyond the short-circuit. An
extension to this could inhibit short-circuit
semantics if any imperative _expression_ is involved.
Discussion - (2) redundant control flow
The first suggestion is contradictory. The
replacement for forEach is noticeably longer and
uses a side effect within an iterate, which the
author argues against elsewhere.
The second suggestion incorrectly assumes that an
else clause is present. The imperative if
(SwitchExp) allows one-sided functionality including
selective control flow adjustment.
Discussion - (3) broken equivalence
The example is unreadable, but the point is
unarguable; imperative semantics within functional
semantics subvert the functional.
(A) - (The cheap solution.) is simple and adopted
here.
(B) - (Major rework.) is a breaking structural
change and so forked off to http://solitaire.omg.org/browse/QVT13-87
for consideration by QVT 2.0.
- Revised Text:
-
In 8.2.2.1 Add
Note also that since an ImperativeExpression
can introduce side effects, it may not be used in
a side effect free OclExpression even
though its inheritance from OclExpression
might suggest that it can. When side effects are
required, imperative constructs such as ImperativeLoopExp,
SwitchExp or VariableInitExp
should be used in place of LoopExp, IfExp
or LetExp.
Constraint
Every containment ancestor of an ImperativeExpression
that is an OclExpression must also be an
ImperatveExpression.
context ImperativeExpression
inv IsInImperativeContext: let ancestors = self->closure(oclContainer())
in ancestors->forAll(oclIsKindOf(OclExpression) implies oclIsKindOf(ImperativeExpression))
- Extent Of Change:
- Minor
- Created:
- Mon, 5 Oct 2015 17:08 GMT
- Updated:
- Mon, 5 Oct 2015 18:36 GMT
- Discussion:
- QVT13-85
- Title:
- section (8.3.2) is very confusing for the
reader
- Summary:
-
his section (8.3.2) is very confusing for the reader.
What does synonym means ? - Is just like a shorthand of
the concrete syntax ? - Is just a new operation included
in the QVTo Standard Library semantically equivalent?.
Ideally, just one type/operation must exist (the OCL
predefined type and the operation of an OCL predefined
type), so that, writing Void (a type) or asType
(operation) should produce the same AST as if I write
OclVoid or oclAsType. With this idea, I'm really puzzled
with the third paragraph of the section. Please revise
this section so that it is less confusing.
- Source:
- formal/08-04-03
— Chapter/Section: 8.3.2 — Page Number/s: 108
- Legacy
Issue Number:
- 13180
- Reporter:
- Adolfo Sanchez-Barbudo Herrera,
Open Canarias, SL (adolfosbh@xxxxxxxxxxxxxxxx)
- Reported:
- Fri, 19 Dec 2008 05:00 GMT on QVT
1.0
- Updated:
- Wed, 7 Oct 2015 06:35 GMT
- Discussion:
- QVT13-11
- Summary:
-
section (8.3.2) is very
confusing for the reader
This section (8.3.2) is very confusing for the
reader. What does synonym means ? - Is just like a
shorthand of the concrete syntax ? - Is just a new
operation included in the QVTo Standard Library
semantically equivalent?. Ideally, just one
type/operation must exist (the OCL predefined type
and the operation of an OCL predefined type), so
that, writing Void (a type) or asType (operation)
should produce the same AST as if I write OclVoid or
oclAsType. With this idea, I'm really puzzled with
the third paragraph of the section. Please revise
this section so that it is less confusing.
Discussion - Ocl type prefixes
As an OCL user, I find the attempt and
recommendation to hide the underlying OCL
functionality very confusing, particularly when it
introduces potential collisions whose prevention is
inaccurately described.
Since the description of the M1 types does not
enumerate them, I am not clear which types are
intended. If Eclipse QVTo is any guide, it would be
OclAny/Any, OclVoid/Void, but not OclElement,
OclInvalid, OclMessage, OclState, OclType.
If this policy is to remain recommended, it must
also apply to all of the above. I find the injection
of Element and Type into the user's namespace
particularly offensive.
I recommend that the recommendation be reversed, so
that we just observe that QVTo implementations
offering backward compatibility may permit the seven
enumerated synonyms to be used as shortforms of the
full spelling.
Discussion - ocl operation prefixes
The references to the "Ocl" prefix are inaccurate
for operations where it is "ocl".
As an OCL user, I find the attempt and
recommendation to hide the underlying OCL
functionality a bit confusing, particularly since
the abbreviated forms are used very little used in
the editorial text and have no definition.
I recommend eliminating their editorial usage and
defining them as synonyms that a QVTo implementation
offering backward compatibility may support as an
alternate spelling that is mapped to the full
spelling when used within the abstract syntax
Discussion - Operation name synonyms
This section was written for OCL 2.0 which has no
String::+ operator. String::+ is available in OCL
2.4 so there is no need for QVT 1.2 to define it as
a synonym.The other mathematical operators have
always been part of OCL, so the purpose of
enumerating them is unclear and indeed confusing. Is
there actually an operation with the spelling
"operator+"? I see no need for one. In the concrete
syntax, "+" is fully available. In UML and OCL "+"
is a permissible internal spelling for an operation
name. The _'+' escape enables its use in arbitrary
name contexts.
The only question is whether a particular
implementation might choose to use "plus" as a
spel;ling to avoid problems in languages that do not
allow arbitrary spellings. But that is an
implementation language-specific choice that does
not affect QVT or OCL; perhaps relevant to the
Java-binding for OCL specification if written. FWIW,
Eclipse QVTo has no "operator+" operation.
Conversely, is the specification actually saying
that "plus" may be used rather than "+"? This might
be a way of elevating an implementation language
workaround into the source, which seems rather
perverse. FWIW, Eclipse QVTo provides no "divide"
operation.
The operation synonym sentences can be eliminated
without any loss.
- Revised Text:
-
In 8.1.14, 8.1.15, 8.2.2.6, A.2.3 replace
isKindOf
by
oclIsKindOf.
In 8.1.14, 8.2.12, 8.2.13, 8.2.15 replace
isTypeOf
by
oclIsTypeOf.
In A.2.3 replace
asType
by
oclAsType
In 8.3.2.
Replace
All the OCL operations starting with “Ocl” prefix
have a synonym operation in the QVT library where
the prefix is
skipped. For instance: isKindOf is a synonym of
oclIsKindOf.
All the predefined OCL types M1 starting with
“Ocl” prefix have a synonym type in the QVT
library where the prefix is
skipped.
The Ocl prefix in types and operations, can still
be used but its usage is not recommended since
name conflicts can be
avoided by qualifying with the name of the library
(StdLib).
by
QVT 1.0, 1.1 and 1.2 encouraged the use of the
simpler "asType", "isKindOf" and "isTypeOf"
synonyms for "ocl"-prefixed operation names such
as "oclAsType", "oclisKindOf" and "oclIsTypeOf" .
Use of "Any" and "Void" synonyms were similarly
encouraged in preference to "Ocl"-prefix types
such as "OclAny" and "OclVoid".
Since these synonyms may introduce conflicts and
since few QVTo users can avoid also being OCL
users, the use of these synonyms is deprecated. A
QVTo implementation may support these deprecated
synonyms by translating them to their prefixed
form before using them in any Abstract Syntax
representation. Any conflicting usage of the
synonyms must ignore the synonym in favor of the
user declaration.
Delete
The following synonyms are defined for the
following pre-defined OCL operations:
String : operator+ -> concat
Integer: operator+ -> plus,
operator- (binary) -> minus,
operator- (unary) -> unaryminus
operator* -> multiply
operator/ -> divide
Real: operator+ -> plus,
operator- (binary) -> minus,
operator- (unary) -> unaryminus
operator* -> multiply
operator/ -> divide
- Extent Of Change:
- Minor
- Created:
- Sun, 4 Oct 2015 14:33 GMT
- Updated:
- Sun, 4 Oct 2015 15:34 GMT
- Discussion:
- QVT13-72
- Title:
- QVTo Standard Library and typedefs Issue.
Extending OCL predefined types
- Summary:
-
As interpretated from the especification (pag 104), the
way of adding new operations to OCL predefined types is
creating new Typedef instances
which must have the OCL predefined type as the base
type. The new operations are added to this new typedef.
However there are several problems:
1. The specification doesn't provide any name for these
typedefs.
2. The specification doesn't specify which type (QVT
typedef or OCL predefined type) should be used when
referencing such OCL predefined types in a QVTo
transformation.
Solution for 1).
Suggestion a: Name the typedef with the same name of the
base type. This provokes name's clash with the
predefined type's name, due to there are two different
types from two standard libraries
which have the same name. A possible solution, would be
expliciting that typedefs (aliases) will never clash its
name with its base type.
Suggestion b: Name the tpyedef with a different name,
such as QVToXXXXXX or XXXX_Alias.
Solution for 2).
Suggestion a: Taking the typedef as the referenced type
in QVTo transformations.
Suggestion b: Taking the OCL predefined type as the
referenced type in QVTo transformations.
Suggestion c: Considering resolution of issue 13168, so
that only OCL predefined exists, and therefore, the only
type which can be referenced.
It's a little bit weird having 2 different types (a
type, and its alias typedef) which represent just the
same type, specially when they are related by a
reference.
My solution's preference in order are:
Suggestion c: Just having one type to refer.
Suggestion a: Since the typedef "extends" the behaviour
of the predefined type (adding new operations), the
former must be the referred one.
Suggestion b: The OCL predefined type is referenced, but
we must take into account that the operations added to
the typedef are also available.
- Legacy
Issue Number:
- 13252
- Reporter:
- Adolfo Sanchez-Barbudo Herrera,
Open Canarias, SL (adolfosbh@xxxxxxxxxxxxxxxx)
- Reported:
- Tue, 13 Jan 2009 05:00 GMT on QVT
1.0
- Updated:
- Wed, 7 Oct 2015 06:33 GMT
- Discussion:
- QVT13-13
- Summary:
-
QVTo Standard Library and
typedefs Issue. Extending OCL predefined types
As interpretated from the especification (pag 104),
the way of adding new operations to OCL predefined
types is creating new Typedef instances
which must have the OCL predefined type as the base
type. The new operations are added to this new
typedef. However there are several problems:
1. The specification doesn't provide any name for
these typedefs.
2. The specification doesn't specify which type (QVT
typedef or OCL predefined type) should be used when
referencing such OCL predefined types in a QVTo
transformation.
Solution for 1).
Suggestion a: Name the typedef with the same name of
the base type. This provokes name's clash with the
predefined type's name, due to there are two
different types from two standard libraries
which have the same name. A possible solution, would
be expliciting that typedefs (aliases) will never
clash its name with its base type.
Suggestion b: Name the tpyedef with a different
name, such as QVToXXXXXX or XXXX_Alias.
Solution for 2).
Suggestion a: Taking the typedef as the referenced
type in QVTo transformations.
Suggestion b: Taking the OCL predefined type as the
referenced type in QVTo transformations.
Suggestion c: Considering resolution of issue 13168,
so that only OCL predefined exists, and therefore,
the only type which can be referenced.
It's a little bit weird having 2 different types (a
type, and its alias typedef) which represent just
the same type, specially when they are related by a
reference.
My solution's preference in order are:
Suggestion c: Just having one type to refer.
Suggestion a: Since the typedef "extends" the
behaviour of the predefined type (adding new
operations), the former must be the referred one.
Suggestion b: The OCL predefined type is referenced,
but we must take into account that the operations
added to the typedef are also available.
Discussion
The offending sentence is:
This is specifically used in the QVT standard
library to attach operations to pre-defined
primitive types, like String and Collections.
This facility is not used anywhere in the
specification and there is no grammar that
facilitates it. No model of the QVTo library is
provided that exploits it. The sentence is therefore
just an observation on a particular implementation
approach.
The approach takes no account of the very similar
requirement for Complete OCL to extend types. This
is being resolved by work towards OCL 2.5 / 3.0 with
which QVTo will almost certainly have to comply.
Therefore, tomorrow this sentence will be
embarassing and incompatible. Today it is just
irrelevant and confusing.
- Revised Text:
-
In 8.2.2.24 Typedef delete
This is specifically used in the QVT standard
library to attach operations to pre-defined
primitive types, like String and Collections.
- Extent Of Change:
- Minor
- Created:
- Mon, 5 Oct 2015 19:08 GMT
- Updated:
- Tue, 6 Oct 2015 18:57 GMT
- Discussion:
- QVT13-88
- Title:
- QVT 1.1 Inappropriate ListLiteralExp
inheritance (Correction to issue 12375 resolution)
- Summary:
-
The resolution for Issue 12375 specifies that
ListLiteralExp has
CollectionLiteralExp
as a superclass.
This leaves the behaviour of the inherited kind and
part attributes
unspecified and
rather embarrassing.
ListLiteralExp (like DictLiteralExp) should inherit
directly from
LiteralExp.
- Legacy
Issue Number:
- 14620
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Wed, 11 Nov 2009 05:00 GMT on QVT
1.1
- Updated:
- Wed, 7 Oct 2015 06:35 GMT
- Discussion:
- QVT13-14
- Summary:
-
Inappropriate
ListLiteralExp inheritance (Correction to issue
12375 resolution)
The resolution for Issue 12375 specifies that
ListLiteralExp has CollectionLiteralExp as a
superclass.
This leaves the behaviour of the inherited kind and
part attributes unspecified and rather embarrassing.
ListLiteralExp (like DictLiteralExp) should inherit
directly from LiteralExp.
Discussion
The lack of specification of ListLiteralExp::kind
and ListLiteralExp::part is indeed a problem.
CollectionLiteralExp::kind is inextensible bloat
that OCL could usefully eliminate, so no
ListLiteralExp::kind is needed in QVTo.
ListLiteralExp::part is needed if QVTo is truly an
extension of OCL. Unfortunately the QVTo BNF omits
the ".." operator and support for CollectionRanges.
Therefore we need to introduce the missing
CollectionRange parsing. ListLiteralExp can inherit
LiteralExp adding CollectionLiteralExp::part but not
CollectionLiteralExp::kind. ListLiteralExp::element
is misguided; ListLiteralExp::part replaces it.
- Revised Text:
-
In the QVTo model and Fig 8.11, where
ListLiteralExp already inherits directly from
LiteralExp, replace element:OclExpression[*]
{composes,ordered} by
part:CollectionPart[*]{composes,ordered}
In 8.2.2.9 ListLiteralExp replace the
CollectionLiteralExp superclass by LiteralExp, and
replace element:OclExpression[*]
{composes,ordered} by
part:CollectionPart[*]{composes,ordered}
In 8.4.7 BNF replace
<collection_item_list> ::=
<expression_comma_list>
by
<collection_item> ::= <_expression_>
('..' <_expression_>)?
<collection_item_list> ::=
<collection_item> (','
<collection_item>)*
Add to 8.2.2.24 ListType:
Notation
An initialized list literal may be created in the
same way as an initialized sequence literal.
List{1,2,3} List{1..10,12,14..16}
Implementation Note
ListLiteralExp will become obsolete once OCL
eliminates the prohibition on extension of
CollectionLiteralExp imposed by the redundant
CollectionLiteralExp::kind attribute.
- Extent Of Change:
- Significant
- Created:
- Sat, 3 Oct 2015 19:34 GMT
- Updated:
- Sun, 4 Oct 2015 10:31 GMT
- Discussion:
- QVT13-70
- Title:
- QVT 1.1 8.1.10 Errors in Examples
- Summary:
-
The second example contains
"if result then return;"
which has a non-boolean condition _expression_ and a
missing endif.
In the first example, it is not clear that the revisit
adds rather than overwrites.
In the third and fourth examples it is not clear why
the second pass reuses the context for the first rather
than creates new objects.
- Legacy
Issue Number:
- 15376
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Sun, 18 Jul 2010 04:00 GMT on QVT
1.1
- Updated:
- Wed, 7 Oct 2015 06:34 GMT
- Discussion:
- QVT13-16
- Summary:
-
8.1.10 Errors in Examples
The second example contains
"if result then return;"
which has a non-boolean condition _expression_ and a
missing endif.
In the first example, it is not clear that the
revisit adds rather than overwrites.
In the third and fourth examples it is not clear
why the second pass reuses the context for the first
rather than creates new objects.
Discussion
The examples are much worse than suggested; verging
on the diabolical.
- Revised Text:
-
In 8.1.10 Replace
The example below
illustrates its usage: given a list of java
classes (JClass instances) that have a packageName
field indicating the name of
the owning Package, the JClass2JPackage
transformation creates a Java Package (JPackage)
for each package name
found in the list of java classes.
transformation JClass2JPackage(inout
javamodel:JAVA);
main () {
javamodel->objectsOfType(JClass)->jclass2jpackage();}
mapping Class::jclass2jpackage() : JPackage () {
init {
result := resolveIn(jclass2jpackage,true)
->select(p|self.package=p.name)->first();
if result then return;
}
name := self.package;
}
In the example above, return is used to avoid
creating more than two packages having the same
name.
by:
modeltype JAVA uses 'http:
transformation JClass2JPackage(inout javamodel : JAVA);
main () {
javamodel.objectsOfType(JClass)->jclass2jpackage();
}
mapping JClass::jclass2jpackage() : JPackage {
init {
var resolved := resolveoneIn(JClass::jclass2jpackage,
p : JPackage | self.packageName = p.name);
result := resolved;
}
if (resolved = null) {
name := self.packageName;
}
}
In the example above, the JClass::jclass2jpackage
mapping is invoked for each JClass.
Within the mapping, resolveoneIn,
without a source _expression_, is used to examine
all JPackage's created by the JClass::jclass2jpackage
mapping. The p iterator traverses the JPackage's
and the condition selects only those whose name
matches the JClass's packageName.
Using resolveoneIn rather than resolveIn
ensures that at most one match is returned. The
match is assigned to resolved and then
to result so that when a match is found
the non-null result re-uses the old
JPackage, whereas a null result causes a
new JPackage to be created. The
assignment to resolved is used by the
conditional clause to avoid the redundant
re-assignment of name to a re-used JPackage.
Replace
The example below treats potential cyclic due to
class inheritance dependencies.
transformation Uml2Java(in uml:UML,out java:JAVA)
main() : JAVA::Interface {
uml->objectsOfType(Class)->map
transformClass();
}
mapping UML::transformClass() : JAVA::Interface ()
{
name := "Ifce".concat(self.name);
base := self.superClass->late
resolve(JAVA::Interface);
}
by
modeltype JAVA uses 'http:modeltype UML uses 'http:
transformation Uml2Java(in uml:UML,out java:JAVA);
main() {
uml.objectsOfType(Class)->map transformClass();
}
mapping UML::Class::transformClass() : JAVA::Interface {
name := "Ifce" + self.name;
base := self.superClass->late resolve(JAVA::Interface);
}
In the example above, the UML::Class::transformClass()
mapping is invoked for each Class in the
uml model. The mapping causes a
corresponding JAVA::Interface to be
created with name and base
property initialization. The name is
initialized by a simple String concatenation. The
base requires the JAVA::Interface's
corresponding to each self.superClass to
be resolved and referenced. The resolve,
with a source _expression_, locates the JAVA::Interface
created by any mapping from the object referenced
by the source _expression_. Application of this on a
collection resolves all creations from each of the
collection elements.
Since it is awkward to ensure that the order of
mapping execution is shallowest superClass-first,
a late resolve is used thereby
deferring the assignment of the base
property until all possible superClass'es
have been created by all possible UML::Class::transformClass()
executions.
A late resolve _expression_ is always
executed in conjunction with an assignment. The
assignment initially returns null, and the context
that is required to execute the assignment later
is stored as part of the trace state.
Replace
transformation Uml2Java(in uml:UML,out java:JAVA)
main() : JAVA::Interface {
uml->objectsOfType(Class)->map
transformClass();
uml->objectsOfType(Class)->map
transformClassInheritance();
}
mapping UML::transformClass() : JAVA::Interface {
name := "Ifce".concat(self.name);
}
mapping UML::transformClassInheritance() :
JAVA:Interface {
base :=
self.superClass->resolveIn(transformClass,JAVA::Interface);
}
In terms of execution, the ‘late resolve’
_expression_ is always related to an assignment.
Conceptually it returns null but in
the meantime it stores all the information that is
required to re-execute later the trace inspection
and the assignment.
by
modeltype JAVA uses 'http:modeltype UML uses 'http:
transformation Uml2Java(in uml:UML,out java:JAVA);
main() {
uml.objectsOfType(Class)->map transformClass();
uml.objectsOfType(Class)->map transformClassInheritance();
}
mapping UML::Class::transformClass() : JAVA::Interface {
name := "Ifce" + self.name;
}
mapping UML::Class::transformClassInheritance() : JAVA::Interface {
init {
result := self.resolveoneIn(UML::Class::transformClass);
}
base := self.superClass->resolveIn(UML::Class::transformClass);
}
The main program now invokes the UML::Class::transformClass()
mapping for each Class in the uml
model to perform the first pass, then it invokes
the UML::Class::transformClassInheritance()
mapping for each Class to perform the
second pass. The first mapping just creates a
corresponding JAVA::Interface with a name
initialized by a simple String concatenation. The
second mapping relocates the JAVA::Interface
created by the first mapping using an init
section within which resolveoneIn, with
self as a source _expression_, locates the
result of the UML::Class::transformClass()
mapping when applied to self. base
is initialized by assigning the results of each of
the superClass resolutions..
At the end of 8.2.1.22 ResolveExp Notation add
See also the third and fourth examples of Section
8.1.10.
At the end of 8.2.1.23 ResolveInExp Notation add
See also the second and fourth examples of
Section 8.1.10.
- Extent Of Change:
- Significant
- Created:
- Mon, 5 Oct 2015 14:10 GMT
- Updated:
- Mon, 5 Oct 2015 15:23 GMT
- Discussion:
- QVT13-80
- Title:
- Specification of deletion semantics
- Summary:
-
I’m having trouble with the semantics of DELETE on p.
189 of the QVT Specification (v1.1). It reads in part:
FORALL OBJVAR IN MAKESET(<DOMAIN_K_VARIABLE_SET>)
(
AND BELONGSTO(OBJVAR,
MAKESET(<DOMAIN_K_VARIABLE_SET>))
I guess I don’t understand MAKESET and BELONGSTO. First
of all, <DOMAIN_K_VARIABLE_SET> is already a set,
so what’s the MAKESET function do? Second, the FORALL
iterates OBJVAR over the results of the same MAKESET
that BELONGSTO tests. So how can BELONGSTO be false?
That is, I would assume BELONGSTO is defined as follows:
BELONGSTO(e, S) º e ÎS
except that under this definition the _expression_ above
is always satisfied.
Any and all help appreciated. Thank you very much.
- Legacy
Issue Number:
- 15886
- Reporter:
- Steven Wartik, Institute for
Defense Analyses (swartik@xxxxxxx)
- Reported:
- Tue, 12 Oct 2010 04:00 GMT on QVT
1.1
- Updated:
- Wed, 7 Oct 2015 06:36 GMT
- Discussion:
- QVT13-21
- Summary:
-
Specification of deletion
semantics
I’m having trouble with the semantics of DELETE on
p. 189 of the QVT Specification (v1.1). It reads in
part:
FORALL OBJVAR IN
MAKESET(<DOMAIN_K_VARIABLE_SET>) (
AND BELONGSTO(OBJVAR,
MAKESET(<DOMAIN_K_VARIABLE_SET>))
I guess I don’t understand MAKESET and BELONGSTO.
First of all, <DOMAIN_K_VARIABLE_SET> is
already a set, so what’s the MAKESET function do?
Second, the FORALL iterates OBJVAR over the results
of the same MAKESET that BELONGSTO tests. So how can
BELONGSTO be false? That is, I would assume
BELONGSTO is defined as follows:
BELONGSTO(e, S) º e ÎS
except that under this definition the _expression_
above is always satisfied.
Any and all help appreciated. Thank you very much.
Discussion
Well this is very embarrassing. I don't understand
it all either, and I certainly do not understand why
it is not written using OCL.
I'm not convinced that QVTr has any delete
semantics since declaratively delete occurs as an
absence of creation.
Must await the Eclipse QVTr prototype.
- Created:
- Mon, 5 Oct 2015 15:37 GMT
- Updated:
- Mon, 5 Oct 2015 15:37 GMT
- Discussion:
- QVT13-82
- Title:
- Dynamic set of input models
- Summary:
-
This is a suggestion:
A developer may need to take a set of in models that
may vary in size each time he runs the transformation.
So, instead of hard-coding the input/out put models
when defining the transformation like this:
transformation Uml2Rdbms(in uml:UML,out rdbms:RDBMS)
The developer should be able to define a dynamic set of
input models. So that he will not be obligated to change
the transformation definition if the number of input
models change every time he runs the transformation.
For example, I defined a transformation that takes
multiple input models (conforming to the same
meta-model) to merge them. Now, I got different number
of in models every time I run the transformation. To
make this more dynamic, I need to take an array of
models as an input to my transformation without
specifying their numbers in the transformation
definition each time I run the transformation.
- Source:
- formal/11-01-01
— Chapter/Section: 8.1.1 — Page Number/s: 79
- Legacy
Issue Number:
- 19428
- Reporter:
- Fatma Mohamed, kustar.ac.ae
(fatma.mohamed@xxxxxxxxxxxx)
- Reported:
- Thu, 22 May 2014 04:00 GMT on QVT
1.1
- Updated:
- Wed, 7 Oct 2015 06:35 GMT
- Discussion:
- QVT13-26
- Summary:
-
Dynamic set of input
models
This is a suggestion:
A developer may need to take a set of in models
that may vary in size each time he runs the
transformation.
So, instead of hard-coding the input/out put models
when defining the transformation like this:
transformation Uml2Rdbms(in uml:UML,out
rdbms:RDBMS)
The developer should be able to define a dynamic
set of input models. So that he will not be
obligated to change the transformation definition if
the number of input models change every time he runs
the transformation.
For example, I defined a transformation that takes
multiple input models (conforming to the same
meta-model) to merge them. Now, I got different
number of in models every time I run the
transformation. To make this more dynamic, I need to
take an array of models as an input to my
transformation without specifying their numbers in
the transformation definition each time I run the
transformation.
Discussion - imperative
This is already supported by the QVTo grammar. Just
define a Collection of models as input or output.
transformation Uml2Rdbms(in uml:Sequence(UML),out
rdbms:Sequence(RDBMS))
and use collection operations to access the
individual models.
Discussion - declarative
- Revised Text:
-
At the end of 7.1 add
A declarative transformation is not restricted to a
fixed number of models. Collections of input models
may be provided and transformed as a single
multi-rooted input model.
At the end of 8.1.1 add.
A transformation is not restricted to a fixed
number of models. Collections of in and inout models
may also be transformed.
transformation Uml2Rdbms(in uml:Sequence(UML),out
rdbms:RDBMS);
The multiple models can be distinguished using
collection operations.
- Extent Of Change:
- Minor
- Created:
- Mon, 5 Oct 2015 21:07 GMT
- Updated:
- Tue, 6 Oct 2015 19:04 GMT
- Discussion:
- QVT13-92
- Title:
- Inadequate definition of "late" semantics
- Summary:
-
The specification of "late" semantics uses the
"conceptually" word; a sure sign of missing semantics.
It is followed by a magic null value that stores
information for later use and with an unspecified trace
interaction.
The interaction of "late" and implicit collect is not
handled so in
generalizations := self.eSuperTypes->collect(t |
t.late resolve(UML::Generalization))
the direct association of "late" with asssignment is no
longer direct; the "late"s must be aggregated.
Potentuially this may occur in arbitrary complexd
expressions including mapping calls!
An alternate multi-pass interpretation of "late" is
given.
This seems like the correct approach; an MtoM
transformation from a with-late to multi-pass
without-late transformation.
- Legacy
Issue Number:
- 19429
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Thu, 22 May 2014 04:00 GMT on QVT
1.2
- Updated:
- Wed, 7 Oct 2015 06:37 GMT
- Discussion:
- QVT13-27
- Summary:
-
Inadequate definition of
"late" semantics
The specification of "late" semantics uses the
"conceptually" word; a sure sign of missing
semantics. It is followed by a magic null value that
stores information for later use and with an
unspecified trace interaction.
The interaction of "late" and implicit collect is
not handled so in
generalizations := self.eSuperTypes->collect(t |
t.late resolve(UML::Generalization))
the direct association of "late" with asssignment
is no longer direct; the "late"s must be aggregated.
Potentially this may occur in arbitrary complex
expressions including mapping calls!
An alternate multi-pass interpretation of "late" is
given.
This seems like the correct approach; an MtoM
transformation from a with-late to multi-pass
without-late transformation.
Discussion
Yes, but such an MtoM is non-trivial. Needs
development and testing before it can be included as
part of the specification.
- Created:
- Mon, 5 Oct 2015 20:37 GMT
- Updated:
- Mon, 5 Oct 2015 20:38 GMT
- Discussion:
- QVT13-90
- Title:
- Inadequate helper/query distinction
- Summary:
-
The Helper class in the AS syntax supports both helpers
and queries.
These two concepts have important distinctions that are
poorly differentiated in 8.2.1.12, where as a minimum
the two italicized terms 'helper' and 'query' should be
used when defining the semantics of each.
Presumably a 'query' cannot modify anything (other than
the log file) anywhere.
Presumably a 'helper' can modify anything anywhere,
except of course sets and tuples that are always
immutable.
The current wording suggests that a 'helper' can modify
sets and tuples but cannot modify objects or create
objects. Surely a 'helper' cannot modify sets or tuples
but can create or update objects?
- Source:
- ptc/14-03-38
— Chapter/Section: 8.2.1.12 — Page Number/s: 90
- Legacy
Issue Number:
- 19571
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Wed, 6 Aug 2014 04:00 GMT on QVT
1.2
- Updated:
- Wed, 7 Oct 2015 06:35 GMT
- Discussion:
- QVT13-30
- Summary:
-
Inadequate helper/query
distinction
The Helper class in the AS syntax supports both
helpers and queries.
These two concepts have important distinctions that
are poorly differentiated in 8.2.1.12, where as a
minimum the two italicized terms 'helper' and
'query' should be used when defining the semantics
of each.
Presumably a 'query' cannot modify anything (other
than the log file) anywhere.
Presumably a 'helper' can modify anything anywhere,
except of course sets and tuples that are always
immutable.
The current wording suggests that a 'helper' can
modify sets and tuples but cannot modify objects or
create objects. Surely a 'helper' cannot modify sets
or tuples but can create or update objects?
See Issue QVT13-33 for disposition
- Created:
- Sat, 3 Oct 2015 20:01 GMT
- Updated:
- Sat, 3 Oct 2015 20:06 GMT
- Discussion:
- QVT13-71
- Title:
- QVT Relations and working with
stereotypes:
- Summary:
-
QVT Relations and working with stereotypes: Is there
something like a QVT-R standard library with methods on
stereotypes in it? There is none in the specification;
compare QVT-R, there are some methods. Are there some
else options for accessing stereotypes with QVT-R?
- Source:
- formal/08-04-03
— Chapter/Section: 7 — Page Number/s: 13ff
- Legacy
Issue Number:
- 13158
- Reporter:
- Siegfried Nolte, Siegfried Nolte
(siegfried@xxxxxxxxxxxxxxxxxx)
- Reported:
- Mon, 15 Dec 2008 05:00 GMT on QVT
1.0
- Updated:
- Wed, 7 Oct 2015 06:36 GMT
- Discussion:
- QVT13-31
- Summary:
-
QVT Relations and working
with stereotypes:
QVT Relations and working with stereotypes: Is
there something like a QVT-R standard library with
methods on stereotypes in it? There is none in the
specification; compare QVT-R, there are some
methods. Are there some else options for accessing
stereotypes with QVT-R?
Discussion
Good question. Recent progress on ensuring that
typesafe OCL navigation works for stereotypes may
render the answer trivial, but until such time as a
stereotyped QVTr transformation has been executed it
is too soon to respond.
- Created:
- Mon, 5 Oct 2015 16:52 GMT
- Updated:
- Mon, 5 Oct 2015 16:53 GMT
- Discussion:
- QVT13-84
- Title:
- Inconsistent multiple inheritance
- Summary:
-
The pragmatic decision to define Module/Transformation
as inheriting both Package and Class violates UML
inheritance.
For a Package:
self.nestingPackage.nestedPackages->includes(self)
For a Class:
self.package.ownedTypes->includes(self)
But self cannot have two containers.
The problem is easily resolved by extending only
Package and adding those Class features that are
actually required.
- Source:
- formal/11-01-01
— Chapter/Section: Many — Page Number/s: Many
- Legacy
Issue Number:
- 18912
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Mon, 16 Sep 2013 04:00 GMT on QVT
1.1
- Updated:
- Wed, 7 Oct 2015 06:36 GMT
- Discussion:
- QVT13-32
- Summary:
-
Inconsistent multiple
inheritance
The pragmatic decision to define
Module/Transformation as inheriting both Package and
Class violates UML inheritance.
For a Package:
self.nestingPackage.nestedPackages->includes(self)
For a Class:
self.package.ownedTypes->includes(self)
But self cannot have two containers.
The problem is easily resolved by extending only
Package and adding those Class features that are
actually required.
Discussion
Transformation is mostly a Class that may have
arbitrary Package scoping. This has been
successfully prototyped by the Eclipse QVT projects,
but not in sufficient detail to justify this
slightly breaking change.
- Created:
- Mon, 5 Oct 2015 20:46 GMT
- Updated:
- Mon, 5 Oct 2015 20:47 GMT
- Discussion:
- QVT13-91
- Title:
- List and Dict are Classes rather than
DataTypes
- Summary:
-
Intuitively List and Dict are objects, so if you pass
them to a mapping/query/helper as an inout parameter,
the object in the caller may be updated by the call.
This is the behaviour of a Class Instance not a
DataType Value.
Please use the open https://bugs.eclipse.org/bugs/show_bug.cgi?id=420150
to discuss this topic.
- Source:
- formal/11-01-01
— Chapter/Section: 8.2.2.25/26 — Page Number/s: 121
- Legacy
Issue Number:
- 19019
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Wed, 23 Oct 2013 04:00 GMT on QVT
1.1
- Updated:
- Wed, 7 Oct 2015 06:34 GMT
- Discussion:
- QVT13-33
- Summary:
-
List and Dict
Class/DataType confusion
Intuitively List and Dict are objects, so if you
pass them to a mapping/query/helper as an inout
parameter, the object in the caller may be updated
by the call.
This is the behaviour of a Class Instance not a
DataType Value.
Discussion
Equally intuitively List (and Dict) are values. Two
distinct 'occurrences' may be equal. This is the
behavior of a DataType not a Class.
List and Dict are specified as CollectionType
(DataType) derivations so we just need to fix up
indications that List and Dict are Classes.
- Revised Text:
-
In 8.2.1.15 MappingOperation Executing a mapping
operation replace:
All out parameters, including result parameters,
have their value initialized to null. All in or
inout non null values, except for the primitive
types are passed by reference. However it is not
legal to change the value when an object is
declared with in direction kind.
by:
All Class parameters are passed or returned by
reference. An in Class parameter may not
be modified.
in DataType parameters are passed by
value and may be modified by the mapping without
affecting the caller.
result DataType parameters are returned
by value.
inout and out DataType
parameters are passed by variable, that is the
caller passes a variable whose value may be
updated zero or more times by the mapping. These
updates are visible to the caller.
out and result parameters are
initialized to null which must be a
legal value for the parameter.
out and inout parameters may
be assigned zero or more times by the mapping. The
initial or last assigned value is visible to the
caller.
in 8.2.1.12 Helper replace:
A helper is an operation that performs a
computation on one or more source objects and
provides a result. The body of a helper is an
ordered list of expressions that is executed in
sequence. When more than one result is declared in
the signature of the helper operation, the
invocation of the operation returns a tuple.
Unless the isQuery property is true, a helper may
have side-effects on the parameters; for instance,
a list may be passed and changed within the body
and its effect is visible after the operation call
termination. However it is illegal to create or
update object instances within a helper operation
except for pre-defined types like sets, tuples,
and for intermediate properties.
by
Helpers and queries are operations that perform a
computation on one or more source objects and
provide a result. The body is an ordered list of
expressions that are executed in sequence.
A query has no side-effects. The
isQuery property is true. All parameters are
implicitly in.
A helper may have side-effects; for
instance, a list may be passed and changed within
the body and its effect is visible after the
operation call termination. The isQuery property
is false. Parameters may be in, inout
or out. A helper may modify but not
create Class instances. A helper may modify
mutable DataType values such as List or Dict.
A helper or query may create mutable DataType
values such as List or Dict or immutable DataType
values such as Tuple, Set or String.
When more than one result is declared in the
signature of a helper operation, the invocation of
the operation returns a tuple.
All Class parameters are passed or returned by
reference. An in Class parameter may not
be modified.
in DataType parameters are passed by
value and may be modified by a helper without
affecting the caller.
result DataType parameters are returned
by value.
inout and out DataType
parameters are passed by variable, that is the
caller passes a variable whose value may be
updated zero or more times by the helper. These
updates are visible to the caller.
out and result parameters are
initialized to null which must be a
legal value for the parameter.
out and inout parameters may
be assigned zero or more times by the helper. The
initial or last assigned value is visible to the
caller.
- Extent Of Change:
- Minor
- Created:
- Fri, 25 Sep 2015 13:12 GMT
- Updated:
- Sat, 3 Oct 2015 20:05 GMT
- Discussion:
- QVT13-69
- 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, 7 Oct 2015 06:36 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
- Revised Text:
-
In 8.2.2.7 ImperativeIterateExp
Collection(T)::xcollect(source, iterator, body)
replace
source->forEach (iterator:T)
by
source->flatten()->forEach (iterator:T)
In 8.2.2.7 ImperativeIterateExp
Collection(T)::xcollectselect(source, iterator,
target, body, condition) replace
source->forEach (iterator:T)
by
source->flatten()->forEach (iterator:T)
In 8.2.2.7 ImperativeIterateExp
Collection(T)::xcollectselectOne(source, iterator,
target, body, condition) replace
source->forEach (iterator:T)
by
source->flatten()->forEach (iterator:T)
- Extent Of Change:
- Minor
- Created:
- Tue, 6 Oct 2015 18:34 GMT
- Updated:
- Tue, 6 Oct 2015 18:39 GMT
- Discussion:
- QVT13-96
- Title:
- Incorrect ModelType.additionalCondition
multiplicity
- Summary:
-
The EBNF:
<modeltype> ::= 'modeltype' <identifier>
<compliance_kind>?
'uses' <packageref_list> <modeltype_where>?
';'
<modeltype_where> ::= 'where'
<expression_block>
allows only a single where which may be a BlockExp, so
ModelType.additionalCondition should be [0..1] rather than [*].
- Source:
- formal/11-01-01
— Chapter/Section: 8.2.1.6 — Page Number/s: 85
- Legacy
Issue Number:
- 19201
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Thu, 30 Jan 2014 05:00 GMT on QVT
1.1
- Updated:
- Wed, 7 Oct 2015 06:34 GMT
- Discussion:
- QVT13-35
- Summary:
-
Incorrect
ModelType.additionalCondition multiplicity
The EBNF:
<modeltype> ::= 'modeltype'
<identifier> <compliance_kind>?
'uses' <packageref_list>
<modeltype_where>? ';'
<modeltype_where> ::= 'where'
<expression_block>
allows only a single where which may be a BlockExp,
so ModelType.additionalCondition should be [0..1]
rather than [*].
Discussion
Yes, but
<expression_block> ::= '{'
<expression_list>? '}'
which allows for the multiple expressions.
The multiple expressions could be shown more
clearly by flattening as:
<modeltype> ::= 'modeltype'
<identifier> <compliance_kind>?
'uses' <packageref_list> ('where' '{'
<expression_list>? '}')? ';'
But in the absence of a CS2AS mapping,
implementations are not obliged to create the
inappropriate BlockExp.
- Created:
- Sun, 4 Oct 2015 16:13 GMT
- Updated:
- Sun, 4 Oct 2015 16:15 GMT
- Discussion:
- QVT13-73
- Title:
- AssignExp unclear for OrderedSet
- Summary:
-
AssignExp to an Collection should make clear that the
results is
target->including(source)->excluding(null)
which should exploit an OCL definition of
OrderedSet::including to be add at end if necessary.
- Source:
- formal/11-01-01
— Chapter/Section: 8.2.2.11 — Page Number/s: 112
- Legacy
Issue Number:
- 19238
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Wed, 12 Feb 2014 05:00 GMT on QVT
1.1
- Updated:
- Wed, 7 Oct 2015 06:34 GMT
- Discussion:
- QVT13-38
- Summary:
-
AssignExp unclear for
OrderedSet
AssignExp to an Collection should make clear that
the results is
target->including(source)->excluding(null)
which should exploit an OCL definition of
OrderedSet::including to be add at end if necessary.
See Issue QVT13-51 for disposition
- Created:
- Mon, 5 Oct 2015 08:28 GMT
- Updated:
- Mon, 5 Oct 2015 08:28 GMT
- Discussion:
- QVT13-75
- Title:
- Rewind Issues 9379, 10938
- Summary:
-
The author of Issue 9379 misunderstood the poor
description of Pattern::bindsTo and consequently removed
the
{composes} qualifier.
Issue 10938 observed that this totally broke QVTc and
introduced CorePattern::variables to compensate.
The QVTr to QVTc transformation remains broken since it
continues to assume that bindsTo {composes}
.
There was actually nothing wrong with bindsTo that
could not have been fixed by clearer wording to the
effect that bindsTo was a dustbin container for
variables not contained elsewhere.
The above kind of emphasises the benefits of an
ownedPlurals naming policy. Therefore suggest that:
a) the AST bloat from the redundant bindsTo be replaced
by definition of a suitable derived property that
satisfies the intent of all variables.
b) that variables be renamed ownedVariables and used
throughout the QVTr to QVTc transformation
- Legacy
Issue Number:
- 19673
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Tue, 9 Dec 2014 05:00 GMT on QVT
1.2
- Updated:
- Wed, 7 Oct 2015 06:38 GMT
- Discussion:
- QVT13-45
- Summary:
-
Rewind Issues 9379, 10938
The author of Issue 9379 misunderstood the poor
description of Pattern::bindsTo and consequently
removed the
{composes} qualifier.
Issue 10938 observed that this totally broke QVTc and
introduced CorePattern::variables to compensate.
The QVTr to QVTc transformation remains broken since
it continues to assume that bindsTo {composes}
.
There was actually nothing wrong with bindsTo that
could not have been fixed by clearer wording to the
effect that bindsTo was a dustbin container for
variables not contained elsewhere.
The above kind of emphasises the benefits of an
ownedPlurals naming policy. Therefore suggest that:
a) the AST bloat from the redundant bindsTo be
replaced by definition of a suitable derived
property that satisfies the intent of all variables.
b) that variables be renamed ownedVariables and
used throughout the QVTr to QVTc transformation
Discussion
The problem is genuine, but further Eclipse QVTr
prototyping reveals two distinct cases, one
requiring containment, another not. Further work is
needed to specify these accurately.
- Created:
- Mon, 5 Oct 2015 15:29 GMT
- Updated:
- Mon, 5 Oct 2015 15:30 GMT
- Discussion:
- QVT13-81
- Title:
- Unclear multi-valued initialisation from
single value
- Summary:
-
The two examples
mymultivaluedproperty += object Node
{
}; // additive semantics
mymultivaluedproperty := object Node {
}
; // the list is reset and re-assigned
are simple assignments from single valued RHS. These
are not covered in the preceding description.
I consider both to be errors since the RHS is
unsuitable for assignment to the LHS. In both cases an
asSet() or whatever should be appended.
More generally, the library operation that exhibits the
"additive semantics" should be clearly identified.
Since addition to OCL collections is not permissible,
it may be necessary to define constructors, so that
var c : Set(String) := Set
{"a"}
;
invokes the Set(T)(Set(T)) constructor.
This would allow initialization for a Sequence from a
List and vice-versa that is otherwise magic.
- Legacy
Issue Number:
- 19687
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Mon, 15 Dec 2014 05:00 GMT on QVT
1.2
- Updated:
- Wed, 7 Oct 2015 06:38 GMT
- Discussion:
- QVT13-46
- Summary:
-
Unclear multi-valued
initialisation from single value
The two examples
mymultivaluedproperty += object Node
{
}; // additive semantics
mymultivaluedproperty := object Node {
}
; // the list is reset and re-assigned
are simple assignments from single valued RHS.
These are not covered in the preceding description.
I consider both to be errors since the RHS is
unsuitable for assignment to the LHS. In both cases
an asSet() or whatever should be appended.
More generally, the library operation that exhibits
the "additive semantics" should be clearly
identified.
Since addition to OCL collections is not
permissible, it may be necessary to define
constructors, so that
var c : Set(String) := Set
{"a"}
;
invokes the Set(T)(Set(T)) constructor.
This would allow initialization for a Sequence from
a List and vice-versa that is otherwise magic.
Issue Links
See Issue QVT13-51 for disposition
- Created:
- Mon, 5 Oct 2015 08:32 GMT
- Updated:
- Mon, 5 Oct 2015 08:32 GMT
- Discussion:
- QVT13-76
- Title:
- Section 8.7.1a production rule seems to be
missing
- Summary:
-
a production rule seems to be missing:
<module_element> ::= <modeltype> Since, a
transformation file can define several transformations
and libraries (modules), it is desirable having the
possibility of defining modeltypes exclusively to a
module. These "local" modelTypes should belong to the
scope of a module, and it shouldn't be accessible to the
remaining defined modules (unless the use of extension
mechanisms is specified).
- Source:
- formal/11-01-01
— Chapter/Section: 8.7.1 — Page Number/s: 120
- Legacy
Issue Number:
- 12370
- Reporter:
- Adolfo Sanchez-Barbudo Herrera,
Open Canarias, SL (adolfosbh@xxxxxxxxxxxxxxxx)
- Reported:
- Fri, 4 Apr 2008 04:00 GMT on QVT
1.1
- Updated:
- Wed, 7 Oct 2015 06:35 GMT
- Discussion:
- QVT13-47
- Summary:
-
Section 8.7.1a production
rule seems to be missing
a production rule seems to be missing:
<module_element> ::= <modeltype> Since,
a transformation file can define several
transformations and libraries (modules), it is
desirable having the possibility of defining
modeltypes exclusively to a module. These "local"
modelTypes should belong to the scope of a module,
and it shouldn't be accessible to the remaining
defined modules (unless the use of extension
mechanisms is specified).
Discussion
A transformation is a major programming element so
multiple transformations per file seems as unusual
as multiple Java classes per file.
But we do already support
transformation X(...) {...}
transformation Y(...) {...}
so perhaps we need per transformation modeltypes.
But if we provided them as suggested: we would have
transformation X(in q : Q) {
modeltype Q uses ....;
}
allowing an outer declaration to depend on an
inner.
If a user really wants many transformations per
file with many distinct conflicting modeltypes, then
the user has the option to use distinctive names for
each modeltype.
Much more sensible to use multiple files in the
first place.
Similarly we don't want or support
per-transformation imports.
- Created:
- Sun, 4 Oct 2015 16:34 GMT
- Updated:
- Sun, 4 Oct 2015 16:38 GMT
- Discussion:
- QVT13-74
- Title:
- Conflicting exclusion of null during
assign
- Summary:
-
"A compound assignment is equivalent to perform as much
simple assignments as there are expressions. Null values
are skipped."
This is poor English and it conflicts with the OCL
specification.
Pedantically it only skips "Null" values so "null
values" are allowed anyway.
"An assignment may receive a future variable produced
by a deferred resolve _expression_ (see ResolveExp). The
effect is equivalent to receive a null value except that
a side-effect action occurs in order to allow
re-executing the assignment at the end of the
transformation.
An assignment _expression_ returns the assigned value
unless it is a future value, in which case null is
returned."
This is barely intelligible and presumably related to
the SmartQVT implementation. It certainly has confusion
about nulls.
I recommend following OCL and allowing null values.
->excluding(null) is easily added.
- Source:
- formal/15-02-01
— Chapter/Section: 8.2.2.11. — Page Number/s: 115
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Tue, 31 Mar 2015 16:15 GMT on QVT
1.2
- Updated:
- Wed, 7 Oct 2015 06:38 GMT
- Discussion:
- QVT13-51
- Summary:
-
Conflicting exclusion of
null during assign
"A compound assignment is equivalent to perform as
much simple assignments as there are expressions.
Null values are skipped."
This is poor English and it conflicts with the OCL
specification.
Pedantically it only skips "Null" values so "null
values" are allowed anyway.
"An assignment may receive a future variable
produced by a deferred resolve _expression_ (see
ResolveExp). The effect is equivalent to receive a
null value except that a side-effect action occurs
in order to allow re-executing the assignment at the
end of the transformation.
An assignment _expression_ returns the assigned value
unless it is a future value, in which case null is
returned."
This is barely intelligible and presumably related
to the SmartQVT implementation. It certainly has
confusion about nulls.
I recommend following OCL and allowing null values.
->excluding(null) is easily added.
Issue 19238
AssignExp to an Collection should make clear that
the results is
target->including(source)->excluding(null)
Issue 19687
The two examples
mymultivaluedproperty += object Node
{
}; // additive semantics
mymultivaluedproperty := object Node {
}
; // the list is reset and re-assigned
are simple assignments from single valued RHS.
These are not covered in the preceding description.
I consider both to be errors since the RHS is
unsuitable for assignment to the LHS. In both cases
an asSet() or whatever should be appended.
More generally, the library operation that exhibits
the "additive semantics" should be clearly
identified.
Since addition to OCL collections is not
permissible, it may be necessary to define
constructors, so that
var c : Set(String) := Set
{"a"}
;
invokes the Set(T)(Set(T)) constructor.
This would allow initialization for a Sequence from
a List and vice-versa that is otherwise magic.
which should exploit an OCL definition of
OrderedSet::including to be add at end if necessary.
Discussion - nulls
UML does not allow nulls in multi-values, therefore
nulls must be excluded during assignments to
properties.
OCL does allow nulls, and even though this may
appear to be a mistake, QVTo must support nulls in
OCL collections until OCL is changed.
Discussion - multiple values
The current wording leaves open the design choice
between:
a) perfect fidelity of nested types, i.e. addition
of a Collection of Collections adds the one
Collection of Collection element
b) perfect flattening, i.e. addition of a
Collection of Collections adds all the elements in
the nested collections.
c) something in between, perhaps behaving
differently depending whether the LHS is a nested
collection or not,
OCL unfortunately started without nested
collections so that imploicit-collect flattens
requiring the explicit collectNested for perfect
Collection type fidelity. a) is not really an
option. c) risks a confusing anarchy. b) is what is
often wanted. If users want nested collections they
can use more explicit operations.
Discussion - future values
Premature access to yet-to-be initialized values is
obviously bad. Making this an error is an option,
but it would be a breaking change; there may be
users who poll the variable awaiting initialization.
Simplest to just clarify the words to indicate that
the value of any yet-to-be-initialized value is
null, even when null is not assignable to the value.
It is not initialized to null; it is null until
initialized.
- Revised Text:
-
In 8.2.2.10 VariableInitExp add
Initialization of a multiple valued Variable uses
the value of the variable's initializer without
conversion or modification. This is unlike an
AssignExp which flattens multiple values and
optionally replaces nulls. The initializer must
therefore conform to any explicit Variable type.
In 8.2.2.11 AssignExp replace:
An assignment _expression_ represents the
assignment of a variable or the assignment of a
Property. In this description we
refer to “target field” the referred variable or
property. If the variable or the property is
monovalued, the effect is to reset
the target field with the new value. If it is
multivalued, the effect is to reset the field or
to append it depending on the
isReset property. If the provided value is made of
more than one _expression_, then the assignment is
said to be a
compound assignment, otherwise it is a simple
assignment. An _expression_ in a compound assignment
is called a
contribution.
For a simple assignment, if the right-_expression_
is a collection, assigning the variable or the
property means adding each
of the items of the collection (additive
semantics). Note that this is only valid for a
multivalued target field. Duplicate
elements are removed if the target field are Sets
- this is the case for property elements. In
addition null values are
automatically skipped.
A compound assignment is equivalent to perform as
much simple assignments as there are expressions.
Null values are
skipped.
An assignment may receive a future variable
produced by a deferred resolve _expression_ (see
ResolveExp). The effect is
equivalent to receive a null value except that a
side-effect action occurs in order to allow
re-executing the assignment at
the end of the transformation.
An assignment _expression_ returns the assigned
value unless it is a future value, in which case
null is returned.
by
An assignment _expression_ assigns or appends one
or more right hand side values to a left hand side
Variable or to a Property.
A simple single valued assignment assigns the
single value RHS to the LHS, optionally replacing
a null value by a defaultValue.
A simple multiple valued assignment assigns or
appends the multiple flattened RHS values to the
LHS optionally replacing null values by a
defaultValue. In the case of an assignment to a
Property any residual null values are omitted.
A complex assignment is equivalent to a
simple assignment comprising a Sequence of the
compound _expression_ values.
A deferred assignment is an assignment
in which one or more of the RHS expressions
involves a deferred resolve _expression_ (see
ResolveExp). The entire assignment is deferred
until the late resolution has been performed. Any
premature access to the yet-to-be-assigned
Variable or Property yields a null value.
For all assignments, the type of the LHS is
unchanged by the assignment.
The return value of an AssignExp is the value of
the RHS in the following equivalent assignments
that clarify the various possibilities.
append is one of the following
operations: Bag::including, List::append,
OrderedSet::append, Sequence::append,
Set::including,
defaultValue is the
AssignExp::defaultValue
late denotes the late keyword for
a deferred assignment or nothing
otherwise.
left denotes the AssignExp::left property
identifying the LHS Variable or Property
LEFT denotes the type of left
such as Set(String)
value is the AssignExp::value property
identifying the RHS _expression_ value or values
Equivalent Single valued Property or Variable
assign: left := value
left := late if value->at(1)
<> null
then value->at(1)
else defaultValue
endif
Equivalent Multiple valued Property assign: left
:= value
left := late value->flatten()->iterate(c;
acc :LEFT = LEFT{} |
let v = if c <> null then c else defaultValue
endif
in if v <> null then acc->append(v)
else acc endif)
Equivalent Multiple valued Variable assign: left
:= value
left := late value->flatten()->iterate(c;
acc LEFT = left |
let v = if c <> null then c else defaultValue
endif
in acc->append(v))
Equivalent Single valued Property or Variable
append: left += value
invalid – append is not possible for single
values.
Equivalent Multiple valued Property append: left
+= value
left := late value->flatten()->iterate(c;
acc : LEFT = left |
let v = if c <> null then c else defaultValue
endif
in if v <> null then acc->append(v)
else acc endif)
Equivalent Multiple valued Variable append: left
+= value
left := late value->flatten()->iterate(c;
acc : LEFT = left |
let v = if c <> null then c else defaultValue
endif
in acc->append(v))
- Extent Of Change:
- Significant
- Created:
- Mon, 5 Oct 2015 08:53 GMT
- Updated:
- Mon, 5 Oct 2015 11:36 GMT
- Discussion:
- QVT13-77
- 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, 7 Oct 2015 06:38 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:
- Mon, 5 Oct 2015 14:57 GMT
- Discussion:
- QVT13-63
- Title:
- Calling the super implementation of an
overriding operation
- Summary:
-
There is currently no way for an overriding operation
to call its overridden super implementation.
ImperativeOCL should provide something similar to the
'super' reference which is available in Java.
- Source:
- formal/15-02-01
— Chapter/Section: 8.2.1.10 ImperativeOperation — Page
Number/s: 89
- Legacy
Issue Number:
- 19823
- Reporter:
- Christopher Gerking, Heinz
Nixdorf Institute, University of Paderborn
(christopher.gerking@xxxxxx)
- Reported:
- Mon, 3 Aug 2015 04:00 GMT on MOF
1.2
- Updated:
- Wed, 7 Oct 2015 06:39 GMT
- Discussion:
- QVT13-61
- Summary:
-
Calling the super
implementation of an overriding operation
There is currently no way for an overriding
operation to call its overridden super
implementation. ImperativeOCL should provide
something similar to the 'super' reference which is
available in Java.
Discussion
QVT13-93 clarifies
the concept of a mapping identifier. An arbitrary
mapping may therefore be called:
self.map My::Tx::Your::Type::doIt(withSomething);
See Issue QVT13-93
for disposition
- Created:
- Tue, 6 Oct 2015 17:58 GMT
- Updated:
- Tue, 6 Oct 2015 17:59 GMT
- Discussion:
- QVT13-95
- Title:
- Unfortunate VariableInitExp wording for
missing initializer
- Summary:
-
8.2.2.10 VariableInitExp says
A variable may not declare an initialization value.
when surely it means
A variable may omit an initialization value.
- Source:
- formal/15-02-01
— Chapter/Section: 8.2.2.10 — Page Number/s: 115
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Mon, 5 Oct 2015 11:32 GMT on MOF
1.2
- Updated:
- Wed, 7 Oct 2015 06:38 GMT
- Discussion:
- QVT13-78
- Summary:
-
Unfortunate
VariableInitExp wording for missing initializer
8.2.2.10 VariableInitExp says
A variable may not declare an initialization
value.
when surely it means
A variable may omit an initialization value.
- Revised Text:
-
In 8.2.2.10 VariableInitExp replace
A variable may not declare an initialization
value.
by
A variable may omit an initialization value.
- Extent Of Change:
- Minor
- Created:
- Mon, 5 Oct 2015 11:34 GMT
- Updated:
- Mon, 5 Oct 2015 11:35 GMT
- Discussion:
- QVT13-79
- Title:
- Undefined rulerefs
- Summary:
-
The <rulerefs> between mappings has no defined
semantics.
Presumably:
<package-name>*::<transformation-name>::<context-type>::<mapping-name>
allowing
<package-name>*::<transformation-name> to be
omitted defauklting to the current transdformation, and,
preserving the current example semantics, resolving an
omitted <context-type> by serching all mapping
names in the transformation.
- Source:
- formal/15-02-01
— Chapter/Section: 8.2.1.5 — Page Number/s: 94
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Tue, 6 Oct 2015 12:29 GMT on MOF
1.2
- Updated:
- Wed, 7 Oct 2015 06:37 GMT
- Discussion:
- QVT13-93
- Summary:
-
Undefined rulerefs
The <rulerefs> between mappings has no
defined semantics.
Presumably:
<package-name>*::<transformation-name>::<context-type>::<mapping-name>
allowing
<package-name>*::<transformation-name>
to be omitted defauklting to the current
transdformation, and, preserving the current example
semantics, resolving an omitted <context-type>
by serching all mapping names in the transformation.
Issue Links
Discussion
Since <mapping_id> needs definition, we can
take the opportunity to rename the strange
<rulerefs>.
- Revised Text:
-
In 8.2.1.15 Notation Replace
mapping inout
<contexttype>::<mappingname>
(<parameters>,) : <result-parameters>
inherits <rulerefs>, merges
<rulerefs>, disjuncts <rulerefs>,
refines <rulerefs> when {<exprs>}
where { <exprs>}
by
mapping inout
<contexttype>::<mappingname>
(<parameters>,) : <result-parameters>
inherits <mappingids>, merges
<mappingids>, disjuncts <mappingids>,
refines <mappingids> when {<exprs>}
where {<exprs>}
where <mappingids> is one or more
comma-separated mapping identifiers.
Replace
8.4.8. Solving Type Identifiers
When referring to a type within an operational
transformation definition it is possible to either
qualify the type name with
a model type or a package name, or, alternatively,
leave the name of the type unqualified.
by
8.4.8. Scoped Identifiers
The usage of <scoped_identifier> are
clarified in this subclause.
8.4.8.1 Type Identifiers
When referring to a type within an operational
transformation definition it is possible to either
qualify the type name with
a model type or a package name, or, alternatively,
leave the name of the type unqualified.
<package_name> ::= <identifier>
<model_type> ::= <identifier>
<type_name> ::= <identifier>
<type_id> ::= ((<package_name> '::')+
| (<model_type> '::'))? <type_name>
Add
8.4.8.2 Transformation Identifiers
A transformation identifier consists of the name
of the transformation prefixed by the ::-separated
names of any containing packages.
<transformation_name> ::=
<identifier>
<transformation_id> ::=
(<package_name> '::')*
<transformation_name>
When a <transformation_id> is referenced
within a transformation, the shared package path
between referenced and referencing transformations
may be omitted.
8.4.8.3 Mapping Identifiers
A mapping identifier is used to reference a
contribution to a disjuncted, inherited or merged
mapping. It is also used to disambiguate a mapping
call. A mapping identifier is the ::-separated
concatenation of a transformation identifier,
context type identifier and the mapping name.
<mapping_name> ::= <identifier>
<mapping_id> ::= (<transformation_id>
'::')? (<type_id> '::')?
<mapping_name>
The transformation identifier map be omitted
completely for a reference to mapping in the
current transformation.
The context type identifier may be omitted
completely provided the mapping name is unique
within the transformation and provided there is no
ambiguity between the transformation name and the
context type name or package names.
- Extent Of Change:
- Minor
- Created:
- Tue, 6 Oct 2015 17:04 GMT
- Updated:
- Tue, 6 Oct 2015 18:08 GMT
- Discussion:
- QVT13-94
- Title:
- xselectOne, xcollectselectOne is Sequence
of One not One
- Summary:
-
The return type of xselectOne, xcollectselectOne
returns a SEquence rather than an optional value.
- Source:
- formal/15-02-01
— Chapter/Section: 8.2.2.7 — Page Number/s: 112
- Reporter:
- Ed Willink, Model Driven
Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Tue, 6 Oct 2015 18:42 GMT on MOF
1.2
- Updated:
- Wed, 7 Oct 2015 06:37 GMT
- Discussion:
- QVT13-97
- Summary:
-
xselectOne,
xcollectselectOne is Sequence of One not One
The return type of xselectOne, xcollectselectOne
returns a Sequence rather than an optional value.
- Revised Text:
-
In 8.2.2.7 Collection(T)::xselectOne(source,
iterator, condition) replace
: Sequence(T) =
by
: T =
and
res += target
by
res := target
In 8.2.2.7 Collection(T)::xcollectselectOne(source,
iterator, target, body, condition) replace
: Sequence(TT) =
by
: TT =
and
res += target
by
res := target
- Extent Of Change:
- Minor
- Created:
- Tue, 6 Oct 2015 18:44 GMT
- Updated:
- Tue, 6 Oct 2015 18:52 GMT
- Discussion:
- QVT13-98
The OMG Team
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10770 - Release
Date: 10/06/15
.
|