MOF Query/View/Transformation Avatar
  1. OMG Specification

MOF Query/View/Transformation — Open Issues

  • Acronym: QVT
  • Issues Count: 7
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

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

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: 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

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

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

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

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