[qvto-dev] Fwd: [omg] [QVT13] Ballot #2 is open for voting until Fri, 23

OMG Issue: QVT13-3

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

Proposal: Deferred

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

OMG Issue: QVT13-8

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

Proposal: Resolved

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

OMG Issue: QVT13-11

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

Proposal: Resolved

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

OMG Issue: QVT13-13

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

Proposal: Resolved

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

OMG Issue: QVT13-14

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

Proposal: Resolved

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

OMG Issue: QVT13-16

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

Proposal: Resolved

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:

JClass2JPackage.qvto
modeltype JAVA uses 'http://www.omg.org/qvt/examples/javamodel';

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

UML2JavaLate.qvto
modeltype JAVA uses 'http://www.omg.org/qvt/examples/javamodel';
modeltype UML uses 'http://www.omg.org/qvt/examples/umlmodel';

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

UML2JavaTwoPass.qvto
modeltype JAVA uses 'http://www.omg.org/qvt/examples/javamodel';
modeltype UML uses 'http://www.omg.org/qvt/examples/umlmodel';

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

OMG Issue: QVT13-21

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

Proposal: Deferred

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

OMG Issue: QVT13-26

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

Proposal: Resolved

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

OMG Issue: QVT13-27

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

Proposal: Deferred

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

OMG Issue: QVT13-30

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

Proposal: Duplicate or Merged

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

OMG Issue: QVT13-31

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

Proposal: Deferred

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

OMG Issue: QVT13-32

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

Proposal: Deferred

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

OMG Issue: QVT13-33

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

Proposal: Resolved

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

OMG Issue: QVT13-34

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

Proposal: Resolved

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

OMG Issue: QVT13-35

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

Proposal: Closed; No Change

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

OMG Issue: QVT13-38

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

Proposal: Duplicate or Merged

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

OMG Issue: QVT13-45

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

Proposal: Deferred

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

OMG Issue: QVT13-46

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

Proposal: Duplicate or Merged

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

OMG Issue: QVT13-47

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

Proposal: Closed; No Change

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

OMG Issue: QVT13-51

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

Proposal: Resolved

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

OMG Issue: QVT13-58

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

Proposal: Resolved

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..1~~1 and defaultValue to ~~unspecified~~access. 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

OMG Issue: QVT13-61

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

Proposal: Duplicate or Merged

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

OMG Issue: QVT13-78

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

Proposal: Resolved

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

OMG Issue: QVT13-93

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

Proposal: Resolved

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

OMG Issue: QVT13-97

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

Proposal: Resolved

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

Breadcrumbs

Issues Summary

Issues Descriptions

OMG Issue: QVT13-3

Proposal: Deferred

OMG Issue: QVT13-8

Proposal: Resolved

OMG Issue: QVT13-11

Proposal: Resolved

OMG Issue: QVT13-13

Proposal: Resolved

OMG Issue: QVT13-14

Proposal: Resolved

OMG Issue: QVT13-16

Proposal: Resolved

OMG Issue: QVT13-21

Proposal: Deferred

OMG Issue: QVT13-26

Proposal: Resolved

OMG Issue: QVT13-27

Proposal: Deferred

OMG Issue: QVT13-30

Proposal: Duplicate or Merged

OMG Issue: QVT13-31

Proposal: Deferred

OMG Issue: QVT13-32

Proposal: Deferred

OMG Issue: QVT13-33

Proposal: Resolved

OMG Issue: QVT13-34

Proposal: Resolved

OMG Issue: QVT13-35

Proposal: Closed; No Change

OMG Issue: QVT13-38

Proposal: Duplicate or Merged

OMG Issue: QVT13-45

Proposal: Deferred

OMG Issue: QVT13-46

Proposal: Duplicate or Merged

OMG Issue: QVT13-47

Proposal: Closed; No Change

OMG Issue: QVT13-51

Proposal: Resolved

OMG Issue: QVT13-58

Proposal: Resolved

OMG Issue: QVT13-61

Proposal: Duplicate or Merged

OMG Issue: QVT13-78

Proposal: Resolved

OMG Issue: QVT13-93

Proposal: Resolved

OMG Issue: QVT13-97

Proposal: Resolved