1. OMG Mailing List
  2. MOF QVT 1.3 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: qvt-rtf
  • Issues Count: 51

Issues Summary

Key Issue Reported Fixed Disposition Status
QVT14-54 QVT - Copy semantics QVT 1.3 open
QVT14-53 QVTr - templated relations QVT 1.3 open
QVT14-16 QVTr: Declaration Order QVT 1.2 open
QVT14-6 QVTr: Rule Overriding semantics QVT 1.1 open
QVT14-52 QVTc - overrides/overidden are confusing QVT 1.3 open
QVT14-50 QVTr - how does a Key handle inheritance? QVT 1.3 open
QVT14-49 QVTo - log should not provoke exceptions QVT 1.3 open
QVT14-48 QVTr - multi-rooted primitive domain QVT 1.3 open
QVT14-47 QVTr - Fixed-point semantics QVT 1.3 open
QVT14-46 QVTc - Partial Assignment QVT 1.3 open
QVT14-33 QVTo : Missing % specification QVT 1.3 open
QVT14-45 QVTo - obscure % shorthand QVT 1.3 open
QVT14-44 QVTo - Confusing reference to modulo operator QVT 1.3 open
QVT14-37 [QVTr] Add CollectionTemplate comprehension content QVT 1.3 open
QVT14-43 QVTr - Ordered Collection Template semantics QVT 1.3 open
QVT14-42 QVTo: re-raising an exception QVT 1.3 open
QVT14-41 Stereotype transformation QVT 1.3 open
QVT14-40 QVTo: Inconsistent != / <> QVT 1.3 open
QVT14-39 QVTc/QVTr : (Guard)Variable is not an OCL Variable QVT 1.3 open
QVT14-38 QVTr - Missing UML2RDBMS application QVT 1.3 open
QVT14-36 QVTr : Redundant opposite notation QVT 1.3 open
QVT14-34 QVTo : use-traditional-comparison-sysntax typo QVT 1.3 open
QVT14-32 QVTo : Missing !-> specification QVT 1.3 open
QVT14-31 QVTo : Missing indexing disambiguation. QVT 1.3 open
QVT14-30 QVTo : Missing shorthands QVT 1.3 open
QVT14-27 QVTo : Unclear isBlackbox attribute for libraries QVT 1.3 open
QVT14-28 QVTr : Missing Collection support QVT 1.3 open
QVT14-29 QVTo : Unclear collection test shorthand QVT 1.3 open
QVT14-26 QVTo: How is an inherited mapping traced QVT 1.3 open
QVT14-23 QVTo: How can an UnlinkExp.target be a Property QVT 1.2 open
QVT14-18 QVTo: Enhance Status to support access to nested transformation trace data MOF 1.2 open
QVT14-19 QVTo: Eliminate deprecated Typedef class MOF 1.2 open
QVT14-22 QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL MOF 1.2 open
QVT14-24 CLONE - current abstract syntax of ImperativeOCL introduces a couple of unclear situations QVT 1.0 open
QVT14-14 Rationalize title MOF 1.2 open
QVT14-15 Trace Record not suitable for Incremental Execution MOF 1.2 open
QVT14-21 QVTo: Late resolution is unuseable in multi-pass transformations QVT 1.2 open
QVT14-20 QVTo: What are the operation overloading semantics? MOF 1.2 open
QVT14-17 QVTr: Missing TracePackage QVT 1.2 open
QVT14-13 QVTo: Standard Library mode and namespace QVT 1.2 open
QVT14-12 QVTc/QVTr: Pattern.bindsTo composition QVT 1.2 open
QVT14-11 Inconsistent multiple inheritance QVT 1.1 open
QVT14-10 QVTr: working with stereotypes: QVT 1.0 open
QVT14-9 QVTo: Inadequate definition of "late" semantics QVT 1.2 open
QVT14-8 QVTo: Enhance ObjectExp to allow constructors invocation QVT 1.1 open
QVT14-7 QVTr: Deletion semantics QVT 1.1 open
QVT14-5 QVTc/QVTr: View/Transformation discrepancy QVT 1.1 open
QVT14-4 QVTo: Relationship between QVTo Mapping and QVTr Relation QVT 1.1 open
QVT14-3 QVTr: syntax mapping (correction to Issue 10646 resolution) QVT 1.1 open
QVT14-2 QVTr: BlackBox operation signature difficulties QVT 1.0 open
QVT14-1 QVTr: Undefined semantics QVT 1.0 open

Issues Descriptions

QVT - Copy semantics

  • Key: QVT14-54
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Model copy is a potentially well-defined behavior that can have a useful default implicit functionality.

    QVTr and QVTc have no copy.

    QVTo has a deep copy but since it is a library operation it is not part of the language and so it has no associated traceability. A first class copy is needed. See ICMT 2017: Christopher Gerking, David Schubert and Ingo Budde: Reducing the Verbosity of Imperative Model Refinements by using General-Purpose Language Facilities.

  • Reported: QVT 1.3 — Mon, 17 Jul 2017 20:55 GMT
  • Updated: Mon, 24 Jul 2017 16:01 GMT

QVTr - templated relations

  • Key: QVT14-53
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    UML supports templated types.
    OCL is aligned with UML.
    QVT extends OCL.
    Therefore QVT supports templated types possibly just through grammar inheritance.

    For relations, that have some similarities to operations, a template signature is required in order to allow a user to bind a specific enforced type. In the absence of templates, a relation defined on the template parameter lowerbound can only enforce the lowerbound.

  • Reported: QVT 1.3 — Tue, 20 Jun 2017 07:23 GMT
  • Updated: Tue, 20 Jun 2017 07:23 GMT

QVTr: Declaration Order

  • Key: QVT14-16
  • Legacy Issue Number: 19667
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVTr imposes an unnatural declaration order in the exposition of a RelationCS. Surely the when clause should be early and variable declarations where initializeable?

    Suggest relaxing the ordering constraint on declarations in a RelationCS to permit the more readable order

    • variable declarations used by when
    • when clauses
    • variable declarations used by check domains
    • check domains
    • variable declarations used by enforce domains
    • enforce domains
    • variable declarations used by where
    • where clauses
  • Reported: QVT 1.2 — Fri, 28 Nov 2014 05:00 GMT
  • Updated: Sat, 17 Jun 2017 08:08 GMT

QVTr: Rule Overriding semantics

  • Key: QVT14-6
  • Legacy Issue Number: 15417
  • Status: open  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    The abstract syntax of QVTr allows a rule to be an override of another rule.

    Rule::overrides: Rule [0..1]
    The rule that this rule overrides.

    The concrete syntax of QVT allows it too:

    <relation> ::= ['top'] 'relation' <identifier>
    ['overrides' <identifier>]
    '

    {' .... '}

    '

    However, the only semantics I can see for 'overrides' is in clause 7.11.1.4 that says:

    "A rule may conditionally override another rule. The overriding rule is executed in place of the overridden rule when the overriding conditions are satisfied. The exact semantics of overriding are subclass specific. "

    Questions:

    1- What are the overriding conditions? are they implied or specified and if so how?

    2- I have not seen any other discussion of overriding in a subclass or Rule so not sure what is meant by "The exact semantics of overriding are subclass specific"?

    3- I have not seen any example of using 'overrides' what so ever in the spec, shouldn't there be one?

    4 - What is the semantics of overriding? is it related to inheritance in the OO sense ? I think QVTr needs a good "inheritance" model where you can relations can be called polymorphically.

  • Reported: QVT 1.1 — Fri, 13 Aug 2010 04:00 GMT
  • Updated: Sun, 21 May 2017 11:24 GMT

QVTc - overrides/overidden are confusing

  • Key: QVT14-52
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Rule::overrides specifies the Rule that this Rule overrides; no problem.

    The remote Rule is overridden by this rule.

    But the opposite of Rule::overrides is called overidden.Wrong way round, It should be called overriding. Rule::overriding navigates to the (many) Rules that override (not are overridden by) this Rule.

  • Reported: QVT 1.3 — Thu, 18 May 2017 17:13 GMT
  • Updated: Thu, 18 May 2017 17:32 GMT

QVTr - how does a Key handle inheritance?

  • Key: QVT14-50
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The semantics of Keys wrt to derived types is unspecified and as discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=512532 far from obvious.

    What are the WFRs for Keys?

    Are multiple keys per type allowed?

    Is key uniqueness applicable to derived types? or does each key have an implicit, distinct derived key for each derived and miltiply-derived type?

    Can a realized access of a Keyed variable return a differenr class that shares the same key?

  • Reported: QVT 1.3 — Sun, 26 Feb 2017 09:12 GMT
  • Updated: Sun, 26 Feb 2017 09:12 GMT

QVTo - log should not provoke exceptions

  • Key: QVT14-49
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    If a variable has an invalid value and that variable is used by passing it to log(), it should not cause an assertion failure on the use of invalid.

  • Reported: QVT 1.3 — Mon, 20 Feb 2017 15:22 GMT
  • Updated: Mon, 20 Feb 2017 15:22 GMT

QVTr - multi-rooted primitive domain

  • Key: QVT14-48
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVT 1.3 removed the artificial restriction on 1 root variable per QVTr domain, but neglected to provide the elaboration for multiple roots per primitive domain. THis is needed to pass 2 parameters to a relation as is required by draft OWL <-> UML transformations.

    Suggest allowing a comma-separated list of roots.

  • Reported: QVT 1.3 — Sat, 11 Feb 2017 14:41 GMT
  • Updated: Sat, 11 Feb 2017 14:41 GMT

QVTr - Fixed-point semantics

  • Key: QVT14-47
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 18572 highlighted that QVT 1.1 seemed to require inconsistent fixed-point semantics. The resolution solved the inconsistency by requiring repeated execution to be external to QVT.

    However some transformations such as the TTC PetriNet to StateChart require repeated transforming.

    If QVTr supported the TypedModel::uses property then an endogeneous transformation whose input TypedModel uses its output TypedModel makes the repeated execution for fixed-point semantics consistent.

    Need to update 7.7/add a fixed-point semantics section.

    Need to add TypedModel::uses to the QVTr concrete syntax.

  • Reported: QVT 1.3 — Fri, 3 Feb 2017 18:28 GMT
  • Updated: Fri, 3 Feb 2017 18:28 GMT

QVTc - Partial Assignment

  • Key: QVT14-46
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    It is unclear how multiple mappings may conspire to populate the children property of a parent. Is the final truth of

    parent.children := aChild

    parent.children = Collection

    {aChild}

    or parent.children->includes(aChild)

    Suggest the latter, since the former can easily be programmed explicitly. This avoids the need to re-interpret a clarifying includes predicate as a partial assignment.

  • Reported: QVT 1.3 — Sat, 7 Jan 2017 14:03 GMT
  • Updated: Sat, 7 Jan 2017 16:24 GMT

QVTo : Missing % specification

  • Key: QVT14-33
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.4.7 defines a "%" mult_op but no accompanying specification.

    The disambiguation comment in 8.4.4 suggests a dual semantic, format half-specified, modulo is presumably Integer/UnlimitedNatural::mod

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 09:05 GMT
  • Updated: Mon, 19 Dec 2016 09:57 GMT

QVTo - obscure % shorthand

  • Key: QVT14-45
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.4.4 4 defines

    The notation “blabla %s\n” % myvar involving the binary '%' operator is a shortand for invoking the pre-defined 'format' operation.

    The inconsistent punctuation and lack of the longhand '"blabla %s\n".format(myvar)' makes for a hard read; which % is the shorthand?

    This really does not seem very useful. The textual saving is small, it only works for single argument formats, it introduces precedence challenges once the missing precedence is specified.

    (Eclipse QVTo does not implement the shorthand.)

    Suggest delete the shorthand.

  • Reported: QVT 1.3 — Mon, 19 Dec 2016 09:50 GMT
  • Updated: Mon, 19 Dec 2016 09:50 GMT

QVTo - Confusing reference to modulo operator

  • Key: QVT14-44
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The "The potential ambiguity with the modulo operator is solved thanks to the type of the first argument, which is a string in our case." text implies that either QVTo or OCL provides a modulo operator. OCL <= 2.4 does not. QVTo's grammar defines '% as a mult_op, perhaps just as the format shorthand, there are certainly no defined semantics such as what data types are applicable, how zero is accommodated.

    (Eclipse QVTo does not provide any % operator.)

    Suggest, delete the confusing sentence.

  • Reported: QVT 1.3 — Mon, 19 Dec 2016 09:38 GMT
  • Updated: Mon, 19 Dec 2016 09:38 GMT

[QVTr] Add CollectionTemplate comprehension content

  • Key: QVT14-37
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    ODM 1.0 uses a CollectionTemplate extension in which a collection comprehension is used to match Sequence content:

    checkonly domain uml assn : Association{general = superassn : Association{
    memberEnd = supSeq : Sequence(Property){usuper | true}},
    memberEnd = subSeq : Sequence(Property){uprop | true}}

    {supSeq->indexOf(usuper) = subSeq->indexOf(uprop)}

    ; // steps through both sequences in tandem

    It is not clear how to achieve this without a CollectionTemnplate iterator.

    The proposal for a co-iterator could avoid the guard and so allow

    checkonly domain uml assn : Association{general = superassn : Association{
    memberEnd = supSeq : Sequence(Property){usuper,index | true}},
    memberEnd = subSeq : Sequence(Property){uprop,index | true}};

  • Reported: QVT 1.3 — Fri, 22 Apr 2016 15:58 GMT
  • Updated: Sun, 4 Sep 2016 08:51 GMT

QVTr - Ordered Collection Template semantics

  • Key: QVT14-43
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    If a CollectIonTemplate is for an OrderedCollection e.g. in

    elements = oSet:OrderedSet

    {m1, m2 ++ rest}

    the literal could be ordered requiring m1 first, m2 next etc. But this inhibits the useful use case of iteration over the Collection unless we extend to:

    elements = oSet:OrderedSet

    {mBefore ++ m1, m2 ++ mAfter}

    Alternatively if 'Ordered' is just ignored, we create a disordered OrderedSet.

  • Reported: QVT 1.3 — Fri, 2 Sep 2016 14:00 GMT
  • Updated: Fri, 2 Sep 2016 14:12 GMT

QVTo: re-raising an exception

  • Key: QVT14-42
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The exception raising syntax is a bit of a mess, cherry-picking special syntaxes and thereby inhibiting general functionality such as raising a computed exception. It is therefore not possible to re-raise an exception.

  • Reported: QVT 1.3 — Wed, 15 Jun 2016 12:19 GMT
  • Updated: Wed, 15 Jun 2016 13:53 GMT

Stereotype transformation

  • Key: QVT14-41
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVTo has stereotypedBy and stereotypedStrictlyBy helpers and a * shortform to assist in the use of stereotypes, but seemingly only for read purposes.

    QVTc and QVTr have no overt support for stereotypes.

    Document why it isn't necessary.

    QVTo's myClass.stereotypedBy(MyStereotype) invocation is actually just the myClass.extension_MyStereotype <> null predicate. QVTc and QVTr can therefore support stereotypes using normal navigation. And as declarative transformation languages a stereotype navigation in the target domain is a stereotype assignment.

    QVTo should support stereotype assignment by:

    myClass.extension_MyStereotype := ...

    Just need an OclElement.allExtensions() helper to support reasoning on the actual steotypes without knowing which ones to 'poll'.

  • Reported: QVT 1.3 — Fri, 10 Jun 2016 09:54 GMT
  • Updated: Fri, 10 Jun 2016 09:54 GMT

QVTo: Inconsistent != / <>

  • Key: QVT14-40
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.4.4. bullet 6 says both available.

    Following bullet 8 it says only one or the other available.

  • Reported: QVT 1.3 — Fri, 10 Jun 2016 09:41 GMT
  • Updated: Fri, 10 Jun 2016 09:41 GMT

QVTc/QVTr : (Guard)Variable is not an OCL Variable

  • Key: QVT14-39
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    An OCL Variable requires its initializer to be statically type conformant to its type.

    A QVTc/QVTd (Guard)Variable defers conformance checking till run-time at which point a non-conformance is a predicate failure.

    There is therefore a problem with the WFR inherited from OCL.

    Suggest:

    VariableDeclaration should be the basis for Variable references.
    RealizedVariable should be a VariableDeclaration, not a Variable.
    GuardVariable should be a new derivation of VariableDeclaration.

    NB VariableDeclaration is the common supertype of Variable and Parameter, although VariableDeclaration is seriously underspecified by OCL.

  • Reported: QVT 1.3 — Sat, 14 May 2016 18:40 GMT
  • Updated: Sat, 14 May 2016 18:40 GMT

QVTr - Missing UML2RDBMS application

  • Key: QVT14-38
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The introduction to 10 concludes

    "and finally, the application of this transformation to the familiar object to relational transformation is shown to demonstrate the results"

    But the Section ends without this application. The QVTc variant of UML2RDBMS is not this application in a different place since the QVTc exposition does not follow the multi-unidirectional conversion style of RelToCore.

  • Reported: QVT 1.3 — Sun, 1 May 2016 09:32 GMT
  • Updated: Sun, 1 May 2016 09:32 GMT

QVTr : Redundant opposite notation

  • Key: QVT14-36
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVT 1.1 introduced an opposite syntax to support inverse navigation. e.g.
    in 7.3 "opposite(Class.attribute)".

    This is not needed since the OCL implicit opposite role name supports "Class" when there is no ambiguity, and "Class[attribute]" when an ambiguity needs resolution.

    The OCL syntax is shorter and reads forwards, unlike the redundant opposite syntax. Suggest deprecation.

  • Reported: QVT 1.3 — Fri, 15 Apr 2016 10:30 GMT
  • Updated: Fri, 15 Apr 2016 10:30 GMT

QVTo : use-traditional-comparison-sysntax typo

  • Key: QVT14-34
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.4.4 at the end has

    use-traditional-comparison-sysntax

    where surely

    use-traditional-comparison-syntax

    was intended.

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 09:06 GMT
  • Updated: Wed, 13 Apr 2016 09:06 GMT

QVTo : Missing !-> specification

  • Key: QVT14-32
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.4.7 defines a "!->" access_op but there is no accompanying specifucation.

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 08:40 GMT
  • Updated: Wed, 13 Apr 2016 08:40 GMT

QVTo : Missing indexing disambiguation.

  • Key: QVT14-31
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL provides two under-specified semantics for the [] indexing operator

    qualifiedAssociationName[qualifierList]
    ambiguousAssociationName[oppositeAssociationName]

    QVTo introduces additional internally and externally ambiguous semantics without any disambiguation specification.

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 08:38 GMT
  • Updated: Wed, 13 Apr 2016 08:38 GMT

QVTo : Missing shorthands

  • Key: QVT14-30
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The following shorthands are missing from 8.4.5

    anExpression[aTypeExp]
    anExpression[anotherExpression]
    !
    !->

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 08:32 GMT
  • Updated: Wed, 13 Apr 2016 08:32 GMT

QVTo : Unclear isBlackbox attribute for libraries

  • Key: QVT14-27
  • Status: open  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    An entire Module may be declared as blackbox using the isBlackbox attribute. Whereas it is obvious that a blackbox transformation consists of its signature only (name + model parameters) as it doesn't include any operations, what is a blackbox library? If it doesn't include operations as well, it is useless because it has no effective signature.

    If the isBlackbox attribute is useful for transformations only, should it be moved from Module to OperationalTransformation?

  • Reported: QVT 1.3 — Thu, 31 Mar 2016 09:30 GMT
  • Updated: Wed, 13 Apr 2016 08:19 GMT

QVTr : Missing Collection support

  • Key: QVT14-28
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The RelToCore transformation that 'defines' QVTr semantics has no semantics for Collections, either explicit through use of CollectionTemplateExp or implicit through use of Collection/non-Collection assignment conversion.

  • Reported: QVT 1.3 — Fri, 1 Apr 2016 06:15 GMT
  • Updated: Wed, 13 Apr 2016 08:19 GMT

QVTo : Unclear collection test shorthand

  • Key: QVT14-29
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.4.5 2 states "if a collection value is passed there is an implicit comparison with the size of the collection."

    This is clearly not the intent: no Collection can ever equal its size.

    Presumably the intent is to treat if (aCollection) as a shorthand for if (aCollection->notEmpty()).

    Suggest that all shorthands are spelled out explicitly in longhand.

  • Reported: QVT 1.3 — Wed, 13 Apr 2016 08:18 GMT
  • Updated: Wed, 13 Apr 2016 08:19 GMT

QVTo: How is an inherited mapping traced

  • Key: QVT14-26
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVT 1.3 8.1.11.1 attempts to identify the hidden information that a trace record must contain. The text is not suitable for a multiple inheritance where there may be one invoked mapping and many executed mappings.

    Probably need to trace all executed mappings.

    Need to specify how the inherited mappings merge more clearly; probably as a section-wise merge.

    See https://bugs.eclipse.org/bugs/show_bug.cgi?id=489271.

  • Reported: QVT 1.3 — Wed, 9 Mar 2016 14:25 GMT
  • Updated: Wed, 9 Mar 2016 14:25 GMT

QVTo: How can an UnlinkExp.target be a Property

  • Key: QVT14-23
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The description of UnlinkExp.target specifies an OclExpression but describes a Property.

    Is this an error? Is it introducing a new PropertyLiteralExp?

  • Reported: QVT 1.2 — Wed, 21 Oct 2015 16:48 GMT
  • Updated: Tue, 22 Dec 2015 17:00 GMT

QVTo: Enhance Status to support access to nested transformation trace data

  • Key: QVT14-18
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Transformation::transform()/parallelTransform() support a nested invocation but the returned Status content is very limited.

    Suggest 1: Reify TraceData/TraceRecord so that arbitrary OCL queries can be executed.

    Suggest 2: Add a getTraceData() to Status and 'this'.

    Suggest 3: Add an optional Status first argument to all resolve() methods to enable use on an invoked Transformation.

    NB. Since a transformation invocation involves cloning, resolve() should hide the clones so that the caller sees only a single object space.

    Suggest 4: TraceData/TraceRecord/Status/Transformation/Model should be / share share an abstraction with QVTc/QVTr.

  • Reported: MOF 1.2 — Wed, 14 Oct 2015 08:46 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Eliminate deprecated Typedef class

  • Key: QVT14-19
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    QVT13-89 for QVT13-10 deprecates Typedef. Remove it.

  • Reported: MOF 1.2 — Sat, 10 Oct 2015 22:06 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL

  • Key: QVT14-22
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 13082 - http://solitaire.omg.org/browse/QVT13-8 identifies the unsound relationship between ImperativeOCL and EssentialOCL.

    It offered a simple textual fix which was exploited to resolve the original issue.

    It also suggests a harder rework to establish modeling integrity. This issue forks off the rework not resolved by the original issue.

    (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

    (Since this is a breaking structural change, it is unlikely to happen before QVT 2.0)

  • Reported: MOF 1.2 — Mon, 5 Oct 2015 17:40 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

CLONE - current abstract syntax of ImperativeOCL introduces a couple of unclear situations

  • Key: QVT14-24
  • Legacy Issue Number: 13082
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • 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

  • Reported: QVT 1.0 — Mon, 5 Oct 2015 17:32 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

Rationalize title

  • Key: QVT14-14
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Pete Rivett, private email, requests removal of "2.0" from the "MOF 2.0 QVT 1.3" title.

    Two versions numbers are certainly confusing.

    But Isn't the "MOF" redundant too?

  • Reported: MOF 1.2 — Tue, 10 Nov 2015 17:02 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

Trace Record not suitable for Incremental Execution

  • Key: QVT14-15
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The glossary definition of Incremental Update strongly suggests that the trace necessary to execute a transformation is also suitable for incremental execution. This is a total falacy.

    Incremental execution of a Rule R with an input s must occur if any relevant property of s changes, which includes any property navigable from s. e.g. s.a.b.c.name. Therefore the trace for incremental execution must identify the identity and value of all accessed property values so that any change can influence re-execution.

    Since accessed values may be produced by another mapping, the trace must also record the identity and value of all assigned property values too.

    This affects all of QVTc, QVTr, and QVTo.

    For QVTo, a re-execution must repeat the accidental ordering of Set elements. Does the specification define an order or just require implementation magic? Is this then a determinstic form of asOrderedSet()?

  • Reported: MOF 1.2 — Wed, 28 Oct 2015 19:10 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Late resolution is unuseable in multi-pass transformations

  • Key: QVT14-21
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    A late resolve() defers an assignment to such a late time that it cannot be used. Multi-pass transformations must therefore either maintain their own Dict of mappings, or use multiple transformations.

    Suggest: Allow a "late" keyword to prefix a block, so that late resolution occurs at the end of the block.

  • Reported: QVT 1.2 — Fri, 23 Oct 2015 09:47 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: What are the operation overloading semantics?

  • Key: QVT14-20
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Does QVTo support operation overloading in a similar way to Java?

    How are conflicting contextual operations resolved when access semantics are used for import?

    How are conflicting contextual operations resolved when extension semantics are used for import?

    Is the resolution at run-time different to that at compile-time?

  • Reported: MOF 1.2 — Fri, 23 Oct 2015 09:21 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: Missing TracePackage

  • Key: QVT14-17
  • Legacy Issue Number: 19659
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The example transformation creates numerous orphan trace classes.

    Surely these should be contained by a trace Package?

    This could be produced by a top level RelationalTransformationToTracePackage relation. RelationToTraceClass should then not be top level.

    Generation of trace is separate from core, so surely there should be a trace direction for the trace output? The core direction should use the trace direction.

  • Reported: QVT 1.2 — Fri, 21 Nov 2014 05:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Standard Library mode and namespace

  • Key: QVT14-13
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The QVTo Standard Library has no model and consequently no namespace.

    This encourages a major confusion:

    The QVToLib::Model and QVToLib::Transformation types used in the QVTo Standard Library are at a different meta-level to UML::Model and QVTbase::Transformation. We have the uncomfortable situation that a QVToLib::Model is an instance of a QVTbase::TypedModel and a QVToLib::Transformation is an instance of a QVTbase::Transformation.

    As a minimum the distinct namespaces should be identified and modeled.

    Possibly QVToLib::Model and QVToLib::Transformation should be renamed. Since they have no namespace they are currently unuseable in code; their sole purpose is for specification of implementation behavior.

  • Reported: QVT 1.2 — Thu, 30 Apr 2015 08:21 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTc/QVTr: Pattern.bindsTo composition

  • Key: QVT14-12
  • Legacy Issue Number: 19673
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • 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

  • Reported: QVT 1.2 — Tue, 9 Dec 2014 05:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

Inconsistent multiple inheritance

  • Key: QVT14-11
  • Legacy Issue Number: 18912
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • 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.

  • Reported: QVT 1.1 — Mon, 16 Sep 2013 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: working with stereotypes:

  • Key: QVT14-10
  • Legacy Issue Number: 13158
  • Status: open  
  • Source: Siegfried Nolte ( Siegfried Nolte)
  • 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?

  • Reported: QVT 1.0 — Mon, 15 Dec 2008 05:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Inadequate definition of "late" semantics

  • Key: QVT14-9
  • Legacy Issue Number: 19429
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • 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.

  • Reported: QVT 1.2 — Thu, 22 May 2014 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Enhance ObjectExp to allow constructors invocation

  • Key: QVT14-8
  • Legacy Issue Number: 19023
  • Status: open  
  • Source: Open Canarias, SL ( Adolfo Sanchez-Barbudo Herrera [X] (Inactive))
  • Summary:

    Problem:

    ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified.

    However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation:

    constructor Column::ColumnConstructor (n:String,t: String)

    { name:=n; type:=t; }

    object result1 : Column (“name”, “String”);
    object result2 : Column (“age”, “Integer”);

    Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint.

    context ObjectExp
    inv : argument->size() > 0 implies body.oclIsUndefined()

    Discussion:
    This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid.

    Proposed solution:

    In section 8.2.1.24 add the following subsection:

    Constraints

    If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa):

    context ObjectExp
    inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and
    not body.oclIsUndefined() implies argument->isEmpty()

    In section 8.2.1.24 add the following to the the end notation subsection:

    Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body:

    object result1 : Column (“name”, “String”);
    object result2 : Column (“age”, “Integer”);

    Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated).

    In section 8.4.7:

    Replace:

    <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
    <expression_block>

    By:

    <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
    (<expression_block> | '(' (<declarator_list>)? ')' )

  • Reported: QVT 1.1 — Wed, 23 Oct 2013 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: Deletion semantics

  • Key: QVT14-7
  • Legacy Issue Number: 15886
  • Status: open  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • 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.

  • Reported: QVT 1.1 — Tue, 12 Oct 2010 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTc/QVTr: View/Transformation discrepancy

  • Key: QVT14-5
  • Legacy Issue Number: 15411
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    "The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction

  • Reported: QVT 1.1 — Tue, 10 Aug 2010 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT
  • Attachments:

QVTo: Relationship between QVTo Mapping and QVTr Relation

  • Key: QVT14-4
  • Legacy Issue Number: 15390
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.1.4 states "a mapping operation is always a refinement of an implicit relation" but 8.2.15 defines "refinedRelation: Relation [0..1] The refined relation, if any." Clearly a contradiction.

    8.1.4. provides the REL_PackageToSchema example of how an implicit relation might be defined, but no other examples or synthesis rules are supplied.

    enforce and checkonly appear in the REL_PackageToSchema example indicating that these define execution mode of a QVTo trnasformation, but there does not appear to be any description of how a transformation might be executed to for instance update an output model. Perhaps the 'output' parameter is 'inout' for create/update but 'out' for create/overwrite.

  • Reported: QVT 1.1 — Fri, 30 Jul 2010 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: syntax mapping (correction to Issue 10646 resolution)

  • Key: QVT14-3
  • Legacy Issue Number: 14640
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html need to be addressed. Apologies too for the long email. This is a very difficult area where precision is important. Provision of
    this resolution demonstrates the need for the resolution, but unfortunately the resolution has an
    erroneous precision that will make QVTr 1.1 unimplementable whereas QVTr 1.0 is just mildly
    ambiguous and conflicting.
    Please do not include the resolution in QVT 1.1 without significantrework.
    I found the definition of the "checkonly"/"enforce" to isCheckable/isEnforceable helpful, although
    different to three of my own intuitive guesses based on attempts to avoid errors in ModelMorf and
    Rel2Core examples.
    The problems identified below are the result of a local review of the resolution. In the absence of a
    coherent Environment semantics it has not been possible to perform a global review. In particular, I
    was unable to review the specification for the arguably redundant bindsTo.
    [Incidentally, the same resolution approach is needed for QVTc and QVTo].
    Disambiguating rules
    --------------------
    The resolution uses a similar approach to the OCL 2.0 specification, but neglects to provide any
    disambiguating rules although many are needed.
    Environments
    ------------
    OCL and the resolution employ environments to carry definitions specific to particular CS constructs,
    so that a CS reference may be resolved with the aid of an environment or the AST.
    In EssentialOCL, all definitions are resolvable with in the immutable AST with the exception of let and
    iterator expressions for which a nestedEnvironment() is used to carry the extra variable declaration
    with the aid of addElement(). The nestedEnvironment supports name occlusion from outer scopes.
    In CompleteOCL, further definitions may be introduced by a definition constraint. The OCL
    specification provides no precise insight into how an environment changes to accommodate the
    definition. Should the name be added to the AST or to the environment? Is the name available for
    forward reference?
    Environment::addElement is defined as a query operation thereby inhibiting side effects. Consequently
    usage such as
    XX.env = YY.env.addElement(Z.name, Z.ast, false)
    leaves the environment of YY unchanged and creates an extended environment for XX.
    A series of such usages creates a series of progressively elaborated environments that support
    backward but not forward referencing. This was not a clear requirement of the QVT 1.0 specification
    and it prevents any variable declarations being introduced in an object template tree being resolved
    through environments in other object template trees or predicate expressions.
    QVT 1.2 RTF Report Page 173 of 190
    Object Management Group
    RTF/FTF Report
    Imposition of no forward referencing seems very undesirable, particularly since the order of domains is
    imposed by the model parameter order. Imagine a Java program in which all methods had to be
    defined in a no-forward reference order.
    As noted above, CompleteOCL neglected to define how AST definitions were added to the AST. QVTr
    must solve this problem since QVTr defines a hierarchically scoped AST rather than an annotation of
    a pre-existing AST.
    I recommend a two stage approach. The inherited attributes section should first compute an
    environment from the pushed-down parent environment augmented by pull-ups from child constructs
    so that a complete immutable and consequently unambiguous environment is associated with each
    construct and then pushed-down to the children. During the pull-up the environment acquires a
    mapping from name to future-AST. During the push-down residual future-AST attributes are populated
    to give a valid AST.
    Reference resolution
    --------------------
    OCL uses lookup functions to resolve variable references. It is necessary either to overload the lookup
    functions so that the the distinct QVTr variable definition sites can be located in the AST, or to use
    some form of Environment::addElement where each definition is defined so that resolution in the
    environment is possible.
    Details
    =======
    Throughout, many disambiguating rules are needed to define illegal semantics. For instance "any" is
    often used to select a syntactically valid value. Corresponding usage in the OCL specification has a
    disambiguating rule to clarify what the consequence of not "one" is.
    My current best attempt at Disambiguating Rules is attached.
    Environment::addElement takes three arguments, the third being a mayBeImplicit argument. This has
    been omitted throughout without explanation.
    identifierCS
    ------------
    OCL defines SimpleNameCS. A degenerate mapping from identifierCS to SimplenameCS is required.
    topLevelCS
    ----------
    The 'imported transformation' environment element is later referenced as 'imported transformations'.
    Typo: TransformationListCS for transformationListCS in Synthesized attributes.
    importListCS
    ------------
    Semantics of import conflicts must be defined.
    unitCS
    ------
    Typo: ast is not a Set.
    Surely the import is of packages (enumerations or operations)or at least transformations (QVTo
    implementations) rather than necessarily relational-transformations?
    transformationCS
    ----------------
    QVT 1.2 RTF Report Page 174 of 190
    Object Management Group
    RTF/FTF Report
    ownedTag is not synthesized.
    keyDeclListCS
    -------------
    Typo: wrong font in synthesized attributes
    modelDeclCS
    -----------
    The [B] grammar:
    modelDeclCS ::= modelIdCS ':' '

    {' metaModelIdListCS '}

    '
    is missing.
    keyDeclCS
    ---------
    Synthesized attributes appear to have experienced a copy and paste error while providing distinct part
    and oppositePart left hand sides.
    keyPropertyCS
    -------------
    The synthesized attributes poke the parent.
    Suggest: it would be clearer for the parent to gather and distribute children similar to the relation/query
    allocation by transformationCS.
    relationCS
    ----------
    Transformation.extends does not appear to be transitive.
    topQualifierCS
    --------------
    Suggest: a boolean or enumerated value rather than a string.
    domainListCS
    ------------
    Typo: missing indentation.
    primitiveTypeDomainCS
    ---------------------
    isCheckable, isEnforceable not synthesized.
    objectTemplateCS
    ----------------
    Variable needs to be added to relation to provide a container.
    Variable needs to be added to relation environment to provide visibility.
    collectionTemplateCS
    --------------------
    Variable needs to be added to relation to provide a container.
    Variable needs to be added to relation environment to provide visibility.
    Suggest: last two if guards are redundant.
    QVT 1.2 RTF Report Page 175 of 190
    Object Management Group
    RTF/FTF Report
    restCS
    ------
    Variable needs to be added to relation to provide a container.
    Non-_ named variable needs to be added to relation environment to provide visibility.
    memberCS
    --------
    Variable needs to be added to relation to provide a container.
    Non-_ named variable needs to be added to relation environment to provide visibility.
    whenCS
    ------
    predicateListCS should be optional.
    whereCS
    -------
    predicateListCS should be optional.
    ExtOclExpressionCS
    ------------------
    This is not present in the QVTr or OCL grammar.
    Presumably it represents the QVTr extension to OCL's OclExpressionCS.
    However it is an extension, since at least RelationCallExpCS can be used in an ordinary
    OclExpressionCS using "not" or "and".
    [A], [B], [C] should therefore follow on from OCL's
    [A], [B], [C]..., [I].
    RelationCallExpressionCS
    ------------------------
    How is a RelationCallExpressionCS distinguished from an OperationCallExpCS?

  • Reported: QVT 1.1 — Mon, 16 Nov 2009 05:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: BlackBox operation signature difficulties

  • Key: QVT14-2
  • Legacy Issue Number: 13054
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so:

    package QVTBase

    context TypedModel
    def: allUsedPackage() : Set(EMOF::Package)
    = self.dependsOn.allUsedPackage()>asSet()>union(self.usedPackage)

    endpackage

    package QVTRelation

    context RelationImplementation
    inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package)

    endpackage

    This is not satisfied by almost the last line of RelToCore in 10.3:

    enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me);

    which seems to have output second.

    -----------------------------------------------------

    More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation.

    This semantic clumsiness could be resolved, if, within a transformation,
    relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output.

    The RelToCore example can then be mended by declaring that:

    RelToCore(...) extends utils::CopyUtilities

    and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation.

  • Reported: QVT 1.0 — Fri, 31 Oct 2008 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTr: Undefined semantics

  • Key: QVT14-1
  • Legacy Issue Number: 10936
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • 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.

  • Reported: QVT 1.0 — Sun, 25 Mar 2007 04:00 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT