MOF Query/View/Transformation Avatar
  1. OMG Specification

MOF Query/View/Transformation — All Issues

  • Acronym: QVT
  • Issues Count: 21
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
QVT12-8 abstract/concrete syntax for try/catch in clauses 8.2.2.13 & 8.2.2.14 lacks support for retrieving the exception caught QVT 1.1 QVT 1.2 Resolved closed
QVT12-7 bug in the uml to rdbms transformation example QVT 1.1 QVT 1.2 Resolved closed
QVT12-6 Rule Overriding in QVTr QVT 1.1 QVT 1.2 Resolved closed
QVT12-5 Figure 7.3 QVT 1.1 QVT 1.2 Resolved closed
QVT12-3 QVT1.1: Add an operation Model::getURI() QVT 1.1 QVT 1.2 Resolved closed
QVT12-2 Please provide a non-null text in the Scope section of documents ptc/09-12-06 and ptc/09-12-05 QVT 1.1 QVT 1.2 Resolved closed
QVT12-1 QVT 1.1 Opposite navigation scoping operator (Correction to Issue 11341 resolution) QVT 1.1 QVT 1.2 Resolved closed
QVT12-4 Derived properties in QVTr QVT 1.1 QVT 1.2 Resolved closed
QVT12-18 Specify List::reject and other iterations QVT 1.1 QVT 1.2 Resolved closed
QVT12-13 Inconsistent description about constructor names QVT 1.1 QVT 1.2 Resolved closed
QVT12-12 QVT atomicity QVT 1.1 QVT 1.2 Resolved closed
QVT12-17 Imprecise result types of resolveIn expressions QVT 1.1 QVT 1.2 Resolved closed
QVT12-16 Resolve expressions without source variable QVT 1.1 QVT 1.2 Resolved closed
QVT12-15 Not possible to remove from a mutable List QVT 1.1 QVT 1.2 Resolved closed
QVT12-14 ObjectExp Abstract Syntax misses a ConstructorBody QVT 1.1 QVT 1.2 Resolved closed
QVT12-9 clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1 QVT 1.1 QVT 1.2 Resolved closed
QVT12-11 Intermediate data not allowed for libraries QVT 1.1 QVT 1.2 Resolved closed
QVT12-10 Consider submitting the QVTO profile out of UML Profile for NIEM, section 9-2 to QVT 1.2 QVT 1.1 QVT 1.2 Resolved closed
QVT12-21 Issue 19178 resolution is rubbish QVT 1.1 QVT 1.2 Resolved closed
QVT12-20 What happens when an exception is thrown by an exception handler QVT 1.1 QVT 1.2 Resolved closed
QVT12-19 List does not support asList() QVT 1.1 QVT 1.2 Resolved closed

Issues Descriptions

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

  • Key: QVT12-8
  • Legacy Issue Number: 15977
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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) { // there is no syntax to bind the actual exception caught to a variable or to retrieve it in an except expression. };


    One possibility would be to introduce a variable in the catch expression (clause 8.2.2.14), e.g.:


    try { // ... }

    except (Exception e)

    { // do something with the exception caught: e }

    ;

    or:

    try

    { // ... }

    except (Exception1 e1, Exception2 e2)

    { // do something with the exception caught: e1 or e2 }

    ;

  • Reported: QVT 1.1 — Fri, 21 Jan 2011 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

bug in the uml to rdbms transformation example

  • Key: QVT12-7
  • Legacy Issue Number: 15917
  • Status: closed  
  • Source: laposte.net ( Xavier Dolques)
  • Summary:

    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

    {self.isPersistent();}

    {
    init

    {result := self.destination.resolveone(Table);}

    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 ;

  • Reported: QVT 1.1 — Fri, 7 Jan 2011 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rule Overriding in QVTr

  • Key: QVT12-6
  • Legacy Issue Number: 15524
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.1 — Fri, 13 Aug 2010 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7.3

  • Key: QVT12-5
  • Legacy Issue Number: 15424
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    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?

  • Reported: QVT 1.1 — Tue, 3 Aug 2010 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QVT1.1: Add an operation Model::getURI()

  • Key: QVT12-3
  • Legacy Issue Number: 15215
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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.

  • Reported: QVT 1.1 — Tue, 20 Apr 2010 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: QVT12-2
  • Legacy Issue Number: 14835
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

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

  • Reported: QVT 1.1 — Mon, 7 Dec 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QVT 1.1 Opposite navigation scoping operator (Correction to Issue 11341 resolution)

  • Key: QVT12-1
  • Legacy Issue Number: 14619
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.1 — Wed, 11 Nov 2009 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Derived properties in QVTr

  • Key: QVT12-4
  • Legacy Issue Number: 15416
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    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

    { self->closure(self.superClass) // closure might not be standard collection op but I used it just to demonstrate the point }

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

    {...}

    }
    }

    }

    does this make sense?

  • Reported: QVT 1.1 — Fri, 13 Aug 2010 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify List::reject and other iterations

  • Key: QVT12-18
  • Legacy Issue Number: 19146
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.1 — Wed, 18 Dec 2013 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent description about constructor names

  • Key: QVT12-13
  • Legacy Issue Number: 19021
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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)

    { name := name }

    constructor MyClass::MyClass(name : String)

    { name := name + "v2" }

    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."

  • Reported: QVT 1.1 — Wed, 23 Oct 2013 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

QVT atomicity

  • Key: QVT12-12
  • Legacy Issue Number: 18572
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.1 — Thu, 21 Mar 2013 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Imprecise result types of resolveIn expressions

  • Key: QVT12-17
  • Legacy Issue Number: 19121
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    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.

  • Reported: QVT 1.1 — Fri, 22 Nov 2013 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    OclAny rather Object is of course the top type

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resolve expressions without source variable

  • Key: QVT12-16
  • Legacy Issue Number: 19096
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    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

  • Reported: QVT 1.1 — Tue, 19 Nov 2013 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Not possible to remove from a mutable List

  • Key: QVT12-15
  • Legacy Issue Number: 19095
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    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

  • Reported: QVT 1.1 — Tue, 19 Nov 2013 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectExp Abstract Syntax misses a ConstructorBody

  • Key: QVT12-14
  • Legacy Issue Number: 19022
  • Status: closed  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    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]

    {composes}

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

  • Reported: QVT 1.1 — Wed, 23 Oct 2013 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

clause 8.3.1.4 Exception needs to document the taxonomy of Exception types in QVT1.1

  • Key: QVT12-9
  • Legacy Issue Number: 15978
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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)

  • Reported: QVT 1.1 — Fri, 21 Jan 2011 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Intermediate data not allowed for libraries

  • Key: QVT12-11
  • Legacy Issue Number: 18325
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: QVT 1.1 — Thu, 27 Dec 2012 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consider submitting the QVTO profile out of UML Profile for NIEM, section 9-2 to QVT 1.2

  • Key: QVT12-10
  • Legacy Issue Number: 17538
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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.

  • Reported: QVT 1.1 — Fri, 3 Aug 2012 04:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 19178 resolution is rubbish

  • Key: QVT12-21
  • Legacy Issue Number: 19208
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.1 — Sat, 8 Feb 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What happens when an exception is thrown by an exception handler

  • Key: QVT12-20
  • Legacy Issue Number: 19178
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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.

  • Reported: QVT 1.1 — Fri, 10 Jan 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

List does not support asList()

  • Key: QVT12-19
  • Legacy Issue Number: 19174
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    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)

  • Reported: QVT 1.1 — Mon, 6 Jan 2014 05:00 GMT
  • Disposition: Resolved — QVT 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT