Current abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught.

That is, QVT1.1 is currently limited to the following style of try/catch logic:

try

except (Exception e)

;

or:

try

except (Exception1 e1, Exception2 e2)

;

Yes. Unuseable caught exceptions are clearly of limited utility.
There can only be one exception variable name for many exception types; what is its type? Cannot be
any of the listed types so it will have to be the common super type. Introduce a new exceptionVariable.
Of course the lower bound on the exception type should be 1. If a catch all is required then the type
can be Exception. If a finally is required then we need a wrapper or specification enhancement.

In the UML to rdbms transformation code given in section A.2.3 :

– mapping to update a Table with new columns of foreign keys
mapping Association::asso2table() : Table
when

{
init

foreignKey := self.map asso2ForeignKey();
column := result.foreignKey->column ;
}

The mapping asso2table is supposed to update a table by adding new columns, but with the last line of the mapping, the existing columns are all replaced by the new ones. I suggest to replace the last line with :
column += result.foreignKey->column ;

yes

You have reached the edge of the specification as written.

1: Yes
2: Yes
3: Yes
4: Yes

I gave some consideration to this for UMLX.

I felt that an abstract 'rule' could define a 'subrule' obligation, which would require an identical match signature, since if the override was narrower it would not fulfill the obligation and if it was wider the additional width would not be permitted by the invocation of the abstract 'rule'.

I felt that all concrete rules should always be matched to ensure that addition of extended functionality did not change previous behaviour. This complies with UMLX's all maximal matches philosophy. Keys in QVTr, Evolution Ids in UMLX can ensure that derived rules reuse inherited matches.

I think a transformation being both a package and a class introduces some difficult compatibility issues to be studied.

Transformation extension is also poorly defined giving additional imprecision when considering the combination of transformation extension and rule override.

My ideas for UMLX were not complete but I think that they may be sounder than QVTr's.

This issue was inadvertently raised from Issue 15417 correspondence. Close it as merged even though
Issue 15417 needs further work.
Disposition: See issue 15417 for disposition

I am confused by something in the MOF QVT specification (version 1.1) and am not sure if it’s an error or my own misunderstanding. Figure 7.3 (p. 24) has links from two instances of ObjectTemplateExp to a single instance of PropertyTemplateItem (the one in the middle). Figure 7.6 (p. 30) shows a composite association between ObjectTemplateExp and PropertyTemplateItem. Why then are there two links to the instance in Figure 7.3? Doesn’t a composite association mean that a PropertyTemplateItem can be owned by only one ObjectTemplateExp?

The problem is that UML Object diagrams omit the decorations from instantiated relationships. Shrt of
moving to a non-standard UMLX diagram, we can perhaps get away with some explanations.

Sometimes, it is useful to get the URI corresponding to the resource of a given transformation input model parameter.

I suggest adding an operation for this purpose in clause 8.3.5 Operations on models.

Model::getURI() : String

Returns the string of the URI corresponding to the model's resource. This operation produces an empty string for a model corresponding to an output parameter

For what it's worth, below is a patch for the Eclipse M2M implementation of QVTOperational where I prototyped such an operation.

No Data Available

Please provide a non-null text in the Scope section of documents ptc/09-12-06 and ptc/09-12-05

No Data Available

The resolution for Issue 11341 uses '.' as a property scoping operator.

This is inconsistent with OCL for which class scoping always uses '::' e.g
enumeration is class::literal operation call is class::operation.

Note the clarifying discussion in OCL, justifying Class.allInstances,
explains
that dot is only for operations on instances.

Simple correction of '.' to '::' in the grammar.

If I want to specify a uni-directional transformation using QVTr, is it ok to use "derived" properties in source domains' object templates? I guess since the transform is not meant to be run in the opposite direction, this will not create a problem?

If that is allowed, it would be a good additional feature of QVTr to allow the definition of new derived properties right in the transform, instead of having them only in the source metamodel.

For example

transform A (...) {

property Class::allSuperClass : Class

relation B {
checkonly domain source c:Class {
allSuperClass = super:Class

}
}

}

does this make sense?

No Data Available

The current specification of List has a vague claim that all OCL Collection operations are available.

Are iterations available?

Are Sequence operations and iterations not available?

Are return types adjusted to List?

The specification needs to provide a clear model defining all the operations and iterations.

Specifying the operations is straightforward, but highlights some nasty inconsistencies such as two
versions of insertAt.
The OCL 2.4 operations are included.
From Issue 13223 clarify wording of insertAt:
From Issue 13251 add remove operations.
A model must wait till OCL 2.5 provides an extensible library model

Problem:

Specification first says in the Constructor concept description:

"The name of the constructor is usually the name of the class to be
instantiated. However this is not mandatory. Giving distinct names allows having more than one constructor."

Later on in the Constructor notation:

"The name of the constructor is necessarily the name of the context type"

This is inconsistent.

Discussion:
Indeed, the notation section statement seems to be correct since:
1. Looks like other programming languages, like Java.
2. More importantly, the instantiation expression would not be so obvious when constructing new objects, and would required to be changed.

Example:

If we have the following constructors:

constructor MyClass::MyClassConstructor(name : String)

constructor MyClass::MyClass(name : String)

How can the instantiation expression refer the different constructor ?

• new MyClass("abc")
• new MyClassConstructor("abc")
• new MyClass::Constructor("abc")

The referred class in a InstantiationExp would not be enough. Changing instantiation expression to provide different name constructor doesn't seem sensible.

Proposed solution:

In section 8.2.1.13

Replace:

"A constructor does not declare result parameters. The name of the constructor is usually the name of the class to be
instantiated. However this is not mandatory. Giving distinct names allows having more than one constructor."

by

"A constructor does not declare result parameters and its name must be the name of the class to be instantiated."

This was discussed on https://bugs.eclipse.org/bugs/show_bug.cgi?id=421621.
Unless we abandon constructor diversity completely, the current AS imposes a needless
implementation difficulty by requiring dynamic resolution of a statically known constructor. This can be
avoided by augmenting InstantiationExp.instantiatedClass with
InstantiationExp.initializationOperation , which can refer to any statically determined constructor. We
can therefore relax the contradictory restrictions on constructor name spelling.
Unfortunately Constructor is not available in ImperativeOCL. Promoting Constructor to ImperativeOCL
would appear easy, unfortunately its superclass ImperativeOperation is also not available. Promoting
ImperativeOperation requires … too hard. So we must instead introduce InstantiationExp.
initializationOperation and redefine it in ObjectExp.

Clause 7.7 mandates fixed-point semantics for in-place transformations.

Please ask my bank to use a repeat-until-no-change in-place transformation for my next pay cheque:

new-balance = old-balance + deposit.

More seriously, the repeat is at the relation level, so if there are multiple applicable relations, the in-place result is specified to experience multiple updates in an indeterminate order. If relation A and then relation B are repeated to exhaustion, is relation A repeated again to accommodate relation B's changes?

Start again. QVTr and QVTc are declarative, therefore they express a single complex truth about the final outputs with respect to the original inputs. There are no observable intermediate steps. It is the responsibility of the transformation engine to ensure that the multiple actual output changes are observed as a single atomic transaction. In particular for in-place transformations, the engine must ensure that no input value is accessed after it is updated for output.

In regard to fixed-point semantics, repetition can only be determinate if it is the entire tranformation that is repeated, and whether to do so would seem to be a legitimate execution option. Therefore QVT should either not specify repetition at all, leaving it to the invoking engine, or specify it as an invocation option for a RelationCallExp.

If an in-place transformation does perform fixed-point repetition at the transformation level, it would seem that the whole repetition should still be a single atomic transaction so that outputs are never observable in an inconsistent partially transformed state between iterations. The engine must therefore iterate over candidate outputs rather than actual outputs.

Fixed point semantics can be achieved by a has-it-changed loop.

Section 8.2.1.22 ResolveExp states the following about the result type of a resolve expression:

"If no target variable is provided, the type is either Object (the type representing all types, see Section 8.3.1) either a Sequence of Objects - depending on the multiplicity."

On top of that, Section 8.2.1.23 ResolveInExp states:

"The type of a ResolveInExp expression is computed using the same rules as for the type of a ResolveExp."

In case of a ResolveInExp, why can't we obtain the result type from the respective mapping?

Consider the following example

mapping EClass :: EClass2EPackage() : EPackage

The result of any resolveIn expression for that mapping is necessarily a subtype of EPackage. No need to cast this up to Object.

OclAny rather Object is of course the top type

In contrast to 8.2.1.23 ResolveInExp, the prior section 8.2.1.22 ResolveExp does not explicitly state whether the source variable is optional for resolve expressions. For Eclipse QVTo, this leads to the situation the source variable is assumed to be mandatory. Consequently, the resolve expression in following snippet is invalid in Eclipse:

var p : EPackage = resolveone(EPackage);

I don't think that this restriction is desirable from the specification viewpoint.

Eclipse bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=392156

The resolve needs a domain in which to search for target objects. For ResolveInExp this can be the
traces of a designated mapping. For ResolveExp it would seem that some source objects must be
supplied. However there seems no reason to prohibit a search everywhere and this could be achieved
by specifying Element.allInstances(). Therefore an omitted ResolveExp sources can mean search all
traces.

A List is a mutable type. However, there is only an interface for adding to a List, not for removing from a List. Analogously to the operation

List(T)::add(T) : Void

there should be something like:

List(T)::remove(T) : Void

Duplicates in part Issue 13251.
Disposition: See issue 19146 for disposition

Problem:

ObjectExp enhances an InstationExp with additional abstract syntax and semantics what respect to the association of the object to be created/updated to a variable.

Likewise, the object expression provides concrete syntax to specify the set of expressions to be executed in order to intialize/update the properties of the object to be created. However this is not reflected in the abstract sytanx.

Discussion:
Indeed, ObjectExp should contain a containment reference to comprise the block of expressions used to initialize/update the object properties.

The best AS candidate is ConstructorBody. Note that this is supported by the own description of the ConstructorBody (section 8.2.1.18):

"A constructor body contains the implementation of a constructor operation or the implementation of an inline constructor
(see ObjectExp)."

This ConstructorBody should be optional, as a result of an enhancement I'll raise in a different issue.

Proposed resolution:

Add the following association to ObjectExp in section 8.2.1.24

body: ConstructorBody [0..1]

The object expression body comprising the expressions to initialize (or update) the properties of the object to be instantiated (or updated).

The required association is already shown in Fig 8.3; just need to add the missing text

In particular, this taxonomy should explicitly include the AssertionFailed exception type that clause 8.2.2.20 refers to for an AssertExp.
Suggest defining a String message attribute for Exception; this would facilitate retrieving the message from a raise expression (clause 8.2.2.15)
Suggest defining AssertionFailed as a subtype of Exception.
Suggest defining 2 attributes in AssertionFailed corresponding to the severity and log expressions of the AssertExp (clause 8.2.2.20)

Yes. We need a toxonomy.
At the root is clearly Exception and this needs no parameters.
We need to introduce a derived StringException for the standard string-valued RaiseExp, and oops we
need to modify the grammar to support this shorthand.
The LogExp-valued AssertionFailed is another derivation of Exception; no severity since it is always
fatal.

The QVT spec says that "an operational transformation may use for its definition intermediate classes and intermediate properties."

Is intermediate data actually restricted to plain transformations? In other words, is intermediate data unsupported for libraries? The eclipse QVTo implementation sticks to this interpretation and actually supports intermediate data only for plain transformations, which is a limitation I don't see a reason for.

No Data Available

Section 9-2 in the UML Profile for NIEM Beta2 document describes an interesting diagrammatic notation for describing the salient organization of a QVTO transformation.

Based on the notation shown in figures 9-2, 9-3, 9-4 and others, this notation clearly involves some kind of UML profile for describing a QVTO transformation whose stereotypes
include <<OperationalTransformation>>, <<MappingOperation>>, <<disjuncts>> and <<inherits>>. The figures in section 9 make a compelling illustration of the utility of a UML Profile for QVTO Transformation.
I believe this UML profile for QVTO is a novel contribution of the UML Profile for NIEM FTF; unfortunately, the document does not describe it and this QVTO Transformation profile
is not mentioned anywhere in the UML Profile for NIEM inventory or in any of the machine readable artifacts.

No Data Available

The proposed resolution for Issue 19178 'clarifies' nested exceptions.

It is wrong. The confusion arises from C++'s problem with a nested exception in a destructor not in a handler. QVTo has no destructors so there is no problem.

Issue 19178 should be closed without change.

Do not apply chnages from Issue 19178 resolution.

For ease of reference, the erroneous 19178 revised text was:
In 8.2.2.13 TryExp add
The selected exceptClause completes before the TryExp completes. Consequently if an exception is
raised during execution of the exceptClause, the execution of the exceptClause cannot complete and so
execution of the transformation terminates without any further changes occurring. The trace records
may be examined to determine what actions the transformation performed prior to termination.
We just need to make clear that the handling of nested exceptions is normal.

QVTo provides no guidance as to how a nested exception should be handled.

Suggest that like C++, a nested exception is ill-formed and the transformation terminates.

The QVTo exception mechanism is lightweight.
Throwing an exception while handling another makes it very difficult to guarantee that the handler for
the first executes correctly.
Therefore declare nested exceptions as ill-formed.

The asList() operation is defined for all concrete collection types. Consequently, it should be defined on List itself (returning self).

Suggestion: specify the operation for the Collection type:

Collection(T)::asList() : List(T)

Add another redefinition for the List type:

List(T)::asList() : List(T)

The additional operation is shown in the Issue 19146 resolution..
Disposition: See issue 19146 for disposition