Hi
I hope that all the discussions on important issues are correctly
reflected in the text that is now up for voting.
Regards
Ed Willink.
-------- Forwarded Message --------
- Issues:
- 25
- Ballot
Opens:
- Wed, 14 Oct 2015 04:00 GMT
- Ballot
Closes:
- Thu, 22 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:44 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:43 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:
- Tue, 13 Oct 2015 17:08 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:44 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:
- Wed, 7 Oct 2015 16:36 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:43 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:
- Tue, 13 Oct 2015 09:26 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:CollectionLiteralPart[*]{composes,ordered}
In 8.2.2.29 ListLiteralExp replace the CollectionLiteralExp superclass by LiteralExp, and replace element:OclExpression[*]
{composes,ordered} by part:CollectionLiteralPart[*]{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:
- Tue, 13 Oct 2015 09:26 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:
- Tue, 13 Oct 2015 09:44 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 {
result := resolveoneIn(JClass::jclass2jpackage,
p : JPackage | self.packageName = p.name);
}
if (name = 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 result for re-use avoiding the creation associated with a null result. A redundant re-assignment of name in the re-used JPackage is avoided by testing whether it has already been assigned.
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:
- Tue, 13 Oct 2015 09:43 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:45 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:
- Tue, 13 Oct 2015 09:50 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.
In 8.2.1.5 replace
Each model parameter refers implicitly to a model participating in the query or transformation.
by
Each model parameter refers implicitly to a model or collection of models participating in the query or transformation.
and
The type of an instance of ModelParameter is an instance of ModelType.
self.type.oclIsKindOf(ModelType)
by
The type of a ModelParameter is a ModelType or Collection of a ModelType.
self.type.oclIsKindOf(ModelType) or (self.type.oclIsKindOf(CollectionType) and self.type.oclAsType(CollectionType).elementType.oclIsKindOf(ModelType))
and
Model parameters are notated as simple parameters within the signature of a transformation.
by
Model parameters are notated as simple or collection parameters within the signature of a transformation.
transformation ManyToOne(in many:Sequence(Mine),out one:Mine)
- Extent Of Change:
- Minor
- Created:
- Mon, 5 Oct 2015 21:07 GMT
- Updated:
- Tue, 13 Oct 2015 09:50 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:44 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:44 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:46 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:45 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:
- Tue, 13 Oct 2015 10:15 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.
While clarifying wording, QVT13-120 is merged to remove the prohibition on object creation/update in helpers.
- 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 reference-to-variable, that is the caller passes a reference to a variable whose value may be updated zero or more times by the mapping. These updates are visible to the caller.
The initial value of each out and result parameter is null.
The value of out, inout and result parameters may be updated many times by assignments.
The final value of each out, inout and result parameter is returned 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 create or modify Class instances or 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 reference-to-variable, that is the caller passes a reference to a variable whose value may be updated zero or more times by the helper. These updates are visible to the caller.
The initial value of each out and result parameter is null.
The value of out, inout and result parameters may be updated many times by assignments.
The final value of each out, inout and result parameter is returned to the caller.
- Extent Of Change:
- Minor
- Created:
- Fri, 25 Sep 2015 13:12 GMT
- Updated:
- Tue, 13 Oct 2015 10:15 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:
- Tue, 13 Oct 2015 18:27 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 : TT := 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:
- Tue, 13 Oct 2015 18:29 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:46 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:
- Thu, 8 Oct 2015 11:21 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:46 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:48 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:48 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:43 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:47 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:
- 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:47 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:47 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:
- Thu, 8 Oct 2015 12:19 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:
- Tue, 13 Oct 2015 11:33 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 usages 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>
Leading parts of the <package_name> may be omitted provided the omission introduces no ambiguity.
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 and ::-separated concatenation of a transformation identifier, context type identifier and the mapping name.
<mapping_name> ::= <identifier>
<mapping_id> ::= (<transformation_id> ':::')? (<type_id> '::')? <mapping_name>
Part or all of <transformation_id> and <type_id> may be omitted provided the omission introduces no ambiguity.
- Extent Of Change:
- Minor
- Created:
- Tue, 6 Oct 2015 17:04 GMT
- Updated:
- Tue, 13 Oct 2015 11:33 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:
- Tue, 13 Oct 2015 11: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.
Discussion
QVT13-34 revealed numerous errors in the pseudocode. This error is just one of many fixed by its resolution.
See Issue QVT13-34 for disposition
- Created:
- Tue, 6 Oct 2015 18:44 GMT
- Updated:
- Tue, 13 Oct 2015 11:37 GMT
- Discussion:
- QVT13-98
- Title:
- Allow object creation in helpers
- Summary:
The prohibition on creation or update of instances in helpers has no justification. Why?
- Source:
-
formal/15-02-01
— Chapter/Section: 8.2.1.12
— Page Number/s: 90
- Reporter:
- Ed Willink, Model Driven Solutions (ed@xxxxxxxxxxxxx)
- Reported:
- Tue, 13 Oct 2015 09:58 GMT on MOF 1.2
- Updated:
- Tue, 13 Oct 2015 10:04 GMT
- Discussion:
- QVT13-120
- Summary:
-
Allow object creation in helpers
The prohibition on creation or update of instances in helpers has no justification. Why?
Discussion
This came up while clarifying wording for QVT13-33.
The prohibition is presumably intended to ensure that all object creation has a corresponding trace record. A good idea but beyond the pragmatic integrity of QVTo. Untraced objects can be created in mappings anyway, so prohibiting their creation in helpers is just an unhelpful restriction on programming flexibility.
See Issue QVT13-33 for disposition
- Created:
- Tue, 13 Oct 2015 10:03 GMT
- Updated:
- Tue, 13 Oct 2015 10:03 GMT
- Discussion:
- QVT13-121
The OMG Team
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4447/10815 - Release Date: 10/14/15
.
|
